Build fails with libjpeg-turbo 3.0.3: Undefined symbols for architecture x86_64: "_jpeg_std_message_table" #7074
Comments
|
Builds fine against 3.0.2, confirmed. So definitely |
|
libjpeg-turbo says it is a RawTherapee issue; see libjpeg-turbo/libjpeg-turbo#763 |
|
libjpeg-turbo did not change its API. tl;dr: Your software relies on accidental, undocumented, unofficial behavior that only occurred on certain platforms, so you can't complain about that behavior changing. There is almost certainly a better way to accomplish what you're trying to accomplish than to needlessly duplicate a lot of the internals of libjpeg-turbo. |
|
Note that, when you call |
|
@dcommander Just to be clear, this is not my software, we did not add this part in MacPorts, we just got a sudden breakage upon |
Yes, you've already mentioned that. But this issue is under the RawTherapee project, so "your" refers to the RawTherapee authors. |
|
Currently RT builds on Mac ARM but only with libjpeg-turbo downgraded to 3.0.2 |
|
Note that MSYS2 libjpeg-turbo just got bumped to 3.0.3. |
|
I found a patch written for this bug: termux-user-repository/tur#1027 |
|
Thank you @Benitoite! I will have a look at your pull request. |
|
Will there be a minor release (5.10.1) that includes a fix for this bug, or will it wait until 5.11? I ask because RawTherapee is currently broken on Arch Linux, and depending on the expected time for a fixed release I would consider opening an issue with them to include this patch temporarily. Thank you for your support! |
|
Nevermind, Arch Linux just released a new version with the jpeg-turbo patch: |
jpeg_std_message_table[] was never a documented part of the libjpeg API, nor was it exposed in jpegint.h or the Windows libjpeg API DLL. Thus, it was never a good idea (nor was it even remotely necessary) for applications to use it. However, referring to #763 and #767, one application (RawTherapee) did use it. 34c0558 hid the symbol, which broke the Un*x builds of RawTherapee. (RawTherapee already did the right thing on Windows, because jpeg_std_message_table[] was not exposed in the Windows libjpeg API DLL. Referring to Beep6581/RawTherapee#7074, RawTherapee now does the right thing on Un*x platforms as well.) The comment in jerror.c indicated that Tom Lane intended the symbol to be external "just in case any applications want to refer to it directly." However, with respect to libjpeg-turbo, the comment was effectively already a lie on Windows. My choices at this point are: 1. Revert 34c0558 and start exposing the symbol on Windows, thus making the comment true again. 2. Remove the comment. Option 1 would have created whiplash, since 3.0.3 has already been released with the symbol hidden, and that option would have further encouraged ill-advised behavior on the part of applications. Since the issue has already been fixed in RawTherapee, and since it is known to affect only that application, I chose Option 2. In my professional opinion, a code comment does not rise to the level of a contract between a library and a calling application. In other words, the comment did not make the symbol part of the API, even though the symbol was exposed on some platforms. Applications that use internal symbols (even the symbols defined in jpegint.h) do so at their own risk. There is no guarantee that those symbols will remain unchanged from release to release, as it is sometimes necessary to modify the internal (opaque) structures and methods in order to implement new features or even fix bugs. Some implementations of the libjpeg API (such as the one in Jpegli, for instance), do not provide those internal symbols at all. Best practices are for applications that use the internal libjpeg-turbo symbols to provide their own copy of libjpeg-turbo (for instance, via static linking), so they can manage any unexpected changes in those symbols. (In fact, that is how libjpeg was originally used. Application developers built it from source with compile-time options to exclude unneeded functionality. Thus, no two builds of libjpeg were guaranteed to be API/ABI-compatible. The idea of a libjpeg shared library that exposes a pseudo-standard ABI came later, and that has always been an awkward fit for an API that was intended to be modified at compile time to suit specific application needs. libjpeg-turbo's colorspace extensions are but one example, among many, of our attempts to reconcile that awkwardness while preserving backward compatibility with the aforementioned pseudo-standard ABI.)
jpeg_std_message_table[] was never a documented part of the libjpeg API, nor was it exposed in jpegint.h or the Windows libjpeg API DLL. Thus, it was never a good idea (nor was it even remotely necessary) for applications to use it. However, referring to #763 and #767, one application (RawTherapee) did use it. 34c0558 hid the symbol, which broke the Un*x builds of RawTherapee. (RawTherapee already did the right thing on Windows, because jpeg_std_message_table[] was not exposed in the Windows libjpeg API DLL. Referring to Beep6581/RawTherapee#7074, RawTherapee now does the right thing on Un*x platforms as well.) The comment in jerror.c indicated that Tom Lane intended the symbol to be external "just in case any applications want to refer to it directly." However, with respect to libjpeg-turbo, the comment was effectively already a lie on Windows. My choices at this point are: 1. Revert 34c0558 and start exposing the symbol on Windows, thus making the comment true again. 2. Remove the comment. Option 1 would have created whiplash, since 3.0.3 has already been released with the symbol hidden, and that option would have further encouraged ill-advised behavior on the part of applications. Since the issue has already been fixed in RawTherapee, and since it is known to affect only that application, I chose Option 2. In my professional opinion, a code comment does not rise to the level of a contract between a library and a calling application. In other words, the comment did not make the symbol part of the API, even though the symbol was exposed on some platforms. Applications that use internal symbols (even the symbols defined in jpegint.h) do so at their own risk. There is no guarantee that those symbols will remain unchanged from release to release, as it is sometimes necessary to modify the internal (opaque) structures and methods in order to implement new features or even fix bugs. Some implementations of the libjpeg API (such as the one in Jpegli, for instance), do not provide those internal symbols at all. Best practices are for applications that use the internal libjpeg-turbo symbols to provide their own copy of libjpeg-turbo (for instance, via static linking), so they can manage any unexpected changes in those symbols. (In fact, that is how libjpeg was originally used. Application developers built it from source with compile-time options to exclude unneeded functionality. Thus, no two builds of libjpeg were guaranteed to be API/ABI-compatible. The idea of a libjpeg shared library that exposes a pseudo-standard ABI came later, and that has always been an awkward fit for an API that was intended to be modified at compile time to suit specific application needs. libjpeg-turbo's colorspace extensions are but one example, among many, of our attempts to reconcile that awkwardness while preserving backward compatibility with the aforementioned pseudo-standard ABI.)
Looks that
libjpeg-turgochanged API in 3.0.3, and this code now does not work:RawTherapee/rtengine/jdatasrc.cc
Lines 251 to 262 in 5a25619
Windows build has this issue years ago: #4713
Now identical linking failure on macOS: https://build.macports.org/builders/ports-14_x86_64-builder/builds/39199/steps/install-port/logs/stdio
This compiles though:
(Functionality not tested.)
The text was updated successfully, but these errors were encountered: