CMake: don't export turbojpeg symbols#730
Conversation
If an application links to both libvncserver and libjpeg-turbo (either directly or indirectly through another library), it can cause the application to unexpectedly call the libvncserver implementation instead of the libjpeg-turbo implementation. Avoid this by not exporting the turbojpeg symbols. Fixes LibVNC#729
| ) | ||
|
|
||
| if(UNIX) | ||
| set_source_files_properties(${COMMON_DIR}/turbojpeg.c PROPERTIES COMPILE_OPTIONS "-fvisibility=hidden") |
There was a problem hiding this comment.
this is relying on compiler flags, there must be a CMake way, like PRIVATE linkage ...
|
Hm. I'm a bit confused as to why this source even exists here. My best understanding, libvncserver requires TurboJPEG API, but doesn't want to hard-require libjpeg-turbo itself, so instead if also supports generic libjpeg and has an old copy of libjpeg turbo's sources to build it's own. Options as I see it
|
|
I also saw another open older PR for another set of conflicting symbols from the src/common stuff. Given that all those vendored source files are essentially copies from other projects, name collisions seem very likely. (haven't tested this out yet) |
If an application links to both libvncserver and libjpeg-turbo (either directly or indirectly through another library), it can cause the application to unexpectedly call the libvncserver implementation instead of the libjpeg-turbo implementation.
Avoid this by not exporting the turbojpeg symbols.
Fixes #729