Wrong JPEG library version: library is 80, caller expects 62

[romkri]

th -limage -e "image.lena()"

almost return Wrong JPEG library version: library is 80, caller expects 62

OS MAC, already done, but don't help:

• reinstall torch7
• brew remove libjpeg
• luarocks remove image
• brew install libjpeg
• luarocks install image

Only one libjpeg.so and only one version of libjpeg.dylib exist on disk

[vadimkantorov]

I did an investigation of similar issue on Linux. In my case there're actually two version of the library, one is 6.2 and is installed to a system path, and the other is 9.0 and is installed to a custom path, which is visible to LIBRARY_PATH and LD_LIBRARY_PATH.

The issue appears multi-layer:

1. Why the system cannot find correct libjpeg.so, even if LIBRARY_PATH and LD_LIBRARAY_PATH contain paths to it?

   If gcc is configured to use mutlilib ($ gcc -print-multi-os-directory) to be ../lib64, it will cause the linker to first search LIBRARY_PATH and system library paths with appended multilib suffix, and only then LIBRARY_PATH as it was specified. So in case the system's libjpeg.so is installed to /usr/local/lib64 or something like this, then gcc will find it, and not the library at your desired path. I consider it a gcc's bug (or a very nasty feature). A similar problem might be with multiarch ($ gcc -print-multiarch) - it is another suffix the linker appends. You can find the path to the library the linker would use by typing: $ gcc -print-file-name=libjpeg.so.

2. Why does CMake not pass the full path to found jpeg to the linker?

   My CMake finds correctly the full path to the desired library, but because its TARGET_LINK_LIBRARIES tries to be smart it doesn't specify the full library path to the linker. It may happen because the jpeg library uses soname flag. CMake docs read: There are some cases where CMake may ask the linker to search for the library (e.g. /usr/lib/libfoo.so becomes -lfoo), such as when a shared library is detected to have no SONAME field.). The fix exists in CMake 3.3, see CMP0060.

All in all, the issue can be fixed by changing CMakeLists.txt to somehow force CMake to pass the full ${JPEG_LIBRARIES} path down to the linker. Hope someone's more versatile with CMake to propose the change.

[bchretien]

@vadimkantorov: as a workaround, for recent CMake versions, we can use cmake_policy(SET CMP0060 NEW) (see here and the documentation on the policy).

CMP0060

Link libraries by full path even in implicit directories.

Policy CMP0003 was introduced with the intention of always linking library files by full path when a full path is given to the target_link_libraries() command. However, on some platforms (e.g. HP-UX) the compiler front-end adds alternative library search paths for the current architecture (e.g. /usr/lib/ has alternatives to libraries in /usr/lib for the current architecture). On such platforms the find_library() may find a library such as /usr/lib/libfoo.so that does not belong to the current architecture.

[davidaltman]

I had a similar issue I was able to solve by setting the desired JPEG version in a config file located in /usr/include/jconfig.h in my Ubuntu 18.04 install. I simply set the value of JPEG_VERSION it was 62, and I set it to 80. I then had no trouble building my project and linking the correct version. Note that this file is auto generated by another CMake configuration file, so it is kind of a hack, and not the permanent solution.

[fwilliamconceicao]

6 years and this issue still persist, what's the definitive solution!?

[vadimkantorov]

lua-torch is not in development / deprecated since 2017... so besides the workarounds in this issue, 99% of chance that there will be no fix