CODEWITHSUNDEEP
linuxlinkercmakeshared-librariesstatic-libraries
plettix
plettix

Reputation: 143

Linking against two similar libraries with cmake

I have a problem with cmake and linking my application: I' working on an existing project. This project uses a modified libjpeg (a static lib) and my executable is linked against it.

target_link_libraries( myprog jpeglib )

Now I want to add a new feature that uses the turbojpeg lib.

add_library( newfeature SHARED ${LIBVNCSERVER_SOURCES})
set_target_properties( newfeature PROPERTIES DEFINE_SYMBOL DLLDEFINE)
target_link_libraries( newfeature turbojpeg-static)
target_link_libraries( newfeature LINK_INTERFACE_LIBRARIES)

My program will be linked against this shared library:

target_link_libraries ( myprog jpeglib newfeature )

Under Windows everything works fine. But if I use this feature under Linux, I get an error:

JPEG Error: JPEG parameter struct mismatch: library thinks size is 488, caller expects 504

This error is generated from libjpeg.

Everything I found on Google doesn't work. I guess that the shared library newfeature uses the jpeglib from myprog although newfeature is statically linked against the turbojpeg lib. newfeature should be a standalone .so or .dll file If I changed the linking order I got the same error, but it is generated from turbojpeg.

Linking myprog against turbojpeg-static is not possible because it is not compatible with the modified libjpeg.

Can anyone help? Is my assumption right?

Upvotes: 0

Views: 3028

Answers (2)

plettix
plettix

Reputation: 143

I found the solution:

I added --exclude-libs,ALL to the linker command of newfeature with this cmake command:

set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -Wl,--exclude-libs,ALL")

The problem was that the symbols from my turbojpeg-static were exported by my newfeature.so and therefore visible from "outside". The linker firstly finds the symbols from the libjpeg. While linking myprog against newfeature.so, the linker finds the references from my newfeature methods to turbojpeg-static and overwrites them.

I hope I can help others with same problem. Please let me know if something is unclear or incorrect.

Upvotes: 3

John Zwinck
John Zwinck

Reputation: 249404

The problem is that you are statically linking libjpeg into your executable, but now you're trying to add an indirect dependency on (libjpeg-turbo), which is another implementation of the same API.

This is a problem because there are now two possible resolutions for every public API symbol (function name, etc.) in the libjpeg API. Most libraries don't support two versions of themselves in one executable, and certainly two different libraries implementing the same interface are unlikely to do so.

If anything you got lucky in that libjpeg is checking a version from its header files (at build time) against its library (at runtime). This sort of problem often goes undetected when libraries don't build in these sorts of checks.

You should try to make newfeature depend not on libjpeg-turbo and instead satisfy it with your own libjpeg which seems to be a fixed requirement from your description.

Upvotes: 2

Related Questions