ERROR 203: Unrecognized error.

[nosilver4u]

I have several Debian 8 & 9 servers that were running version 0.10.2 (timestamps say Nov 21 is when I downloaded and installed it). After updating to the latest code (version 0.11.0), I get the error 203. I've tried several different images, with this command: /opt/caesium/caesiumclt -q 80 -o /tmp/caesium /home/me/jpeg-9c/testorig.jpg That particular test image is part of this package: http://www.ijg.org/files/jpegsrc.v9c.tar.gz Altering the output folder does not seem to help, omitting it says "cannot create output folder", which is probably expected. Dropping the quality to 0 (lossless) or removing that parameter results in this, which might be the first clue: Wrong JPEG library version: library is 90, caller expects 62

I did recently update libjpeg on these machines from 9b to 9c, but so far as I can tell, Caesium is configured to use it's own mozjpeg compiled in the libcaesium folder, and I do also have mozjpeg installed in /opt/mozjpeg/ (but that was not updated recently).

[nosilver4u]

On my production boxes, I simply reverted by script to use 0.10.2 and it reverted things. Not sure that it actually even recompiled anything, but it at least reverted to the original version of caesium-clt that I installed. I have one machine where I was able to clean out all the caesium source files, and download from the commits that should have been used originally, and even though it is now 0.10.2, it throws the latter error every time: Wrong JPEG library version: library is 90, caller expects 62

I noted during the compilation that it mentioned my mozjpeg install, so I ran ldd to see what libs it was using and found this: libjpeg.so.9 => /usr/local/lib/libjpeg.so.9 libturbojpeg.so.0 => /opt/mozjpeg/lib64/libturbojpeg.so.0 I then checked the version of 0.10.2 that is working properly (the one that I reverted to), and it says this: libjpeg.so.62 => /opt/mozjpeg/lib64/libjpeg.so.62 libturbojpeg.so.0 => /opt/mozjpeg/lib64/libturbojpeg.so.0

That would simply seem to indicate that my newer builds somehow are auto-detecting the libjpeg.so.* file from the recently updated libjpeg-9c, but how in the world do I tell it otherwise? I tried using ldconfig on the mozjpeg folder, but that doesn't seem to have done anything...

[nosilver4u]

appears to actually be caused by the changes here (my install date must be a little bit off, as that was commited Nov15): https://github.com/Lymphatus/libcaesium/commit/b815f2bd4106ea4165a3075ae04c3614b5d22fa5#diff-af3b638bc2a3e6c650974192a53c7291

Reverting to the previous commit works perfectly on my test system again: 4e4aae1a9f8bbe3f185b5339d9047e2b81c5585a

[Lymphatus]

Yes, this is indeed a problem related to paths: include_directories(/usr/local/include) is meant for zopflipng, but it may conflict with standard libjpeg installations. I'm gonna address this issue in the library.

[nosilver4u]

Ah, I wondered what had sparked the change, makes sense. Looking forward to seeing the fix in libcaesium so I can get these machines back to the latest version. Thanks for all your hard work!

[Sergi0O]

I have the same problem. I can only use the root directory as output folder, every other folders set by -o option are ignored. How could I solve it?

[nosilver4u]

@Sergi0O , It's unlikely to be the same problem, as this error prevents ANY output, regardless of the output directory. @Lymphatus might be able to say otherwise, but there IS another issue that mentions the problem you appear to be having: #26

[Lymphatus]

@nosilver4u is right. The @Sergi0O is indeed an issue, but it's unrelated to this one and addressed in #26

[nosilver4u]

I downloaded the latest code for caesium-clt and libcaesium and there seems to be some glitch still. It "works" (it seems to compress my test file properly), but reports this error: Wrong JPEG library version: library is 90, caller expects 62

I made sure to completely remove the previous copy of caesiumclt, along with all build directories, to ensure a clean start, and still got the same results.

Similar to my debugging earlier, ldd reports that it is linked against the stock libjpeg installed in /usr/local/lib/ instead of the mozjpeg version installed in /opt/mozjpeg/lib64/

[nosilver4u]

It seems I was able to get the linkage correct by moving this line:

link_directories(/usr/local/lib)

below the mozjpeg section, so that the file looks like so:

cmake_minimum_required(VERSION 2.8.12)

project(libcaesium)

set(CMAKE_MACOSX_RPATH 1)
set(CMAKE_INSTALL_RPATH_USE_LINK_PATH TRUE)

# The version number.
set(VERSION_MAJOR 0)
set(VERSION_MINOR 4)
set(VERSION_PATCH 1)

configure_file(
        "caesium/config.h.in"
        "${PROJECT_BINARY_DIR}/config.h"
)

include_directories("${PROJECT_BINARY_DIR}")
if (NOT WIN32)
    include_directories(/opt/mozjpeg/include)
    include_directories(/usr/local/include)

    if(EXISTS /opt/mozjpeg/lib64)
        link_directories(/opt/mozjpeg/lib64)
    else()
        link_directories(/opt/mozjpeg/lib)
    endif()
else ()
    include_directories(C:\\mozjpeg\\include)
    include_directories(C:\\zopfli\\src)
endif()

link_directories(/usr/local/lib)

add_subdirectory(caesium)
add_subdirectory(demo)

I don't know for sure if that will avoid the previous issue you were trying to solve, as I don't use Caesium for PNG images at all, but it works for JPG.

I'm having what appears to be a separate issue now where caesium won't write to a sub-folder within /tmp/ but I can create a new issue for that if you like. Trying to work out a temporary solution on that and figure out exactly why it is happening.

[nosilver4u]

I think the /tmp/ issue is permissions-related because these are API servers, and if I wipe out /tmp/caesium/ and run my test, it works, or if I use sudo, it works. But if the API creates the folder, then it is owned by www-data and breaks my test, because I don't have permission. That's something I need to work out though, nothing wrong with caesium on that portion.

[nosilver4u]

I'm going to move this over to libcaesium for you so (in hopes that it gets fixed soon).