Page MenuHomeSolus

Rebuilding Freeimage 3.18 to fix undefined reference errors
Closed, ResolvedPublic


Hello Solus Maintainers,

I have been attempting to compile EmulationStation (in order to create a proposal for to be included in Solus repositories). However, linking would fail when the project invoked Freeimage tasks.

This is an example of the types of errors I would see:

/usr/bin/ld: /usr/lib64/gcc/x86_64-solus-linux/8.2.0/../../../../lib64/ undefined reference to `jpeg_std_error'
/usr/bin/ld: /usr/lib64/gcc/x86_64-solus-linux/8.2.0/../../../../lib64/ undefined reference to `WebPPictureInitInternal'
/usr/bin/ld: /usr/lib64/gcc/x86_64-solus-linux/8.2.0/../../../../lib64/ undefined reference to `PKFormatConverter_EnumConversions'
/usr/bin/ld: /usr/lib64/gcc/x86_64-solus-linux/8.2.0/../../../../lib64/ undefined reference to `TIFFSetSubDirectory'

As an experiment, I compiled Freeimage 3.18 myself in accordance with Freeimage's Readme directions. With my build of Freeimage installed, I was able to successfully build EmulationStation. I then made my own changes to Freeimage's package.yml, and my installed version worked as expected.

I believe the issue has to do with the unbind step in the package's setup. The comment on it mentions that it was borrowed from Fedora's repositories, but the official readme does not require this step, and I believe it breaks dynamic links under certain situations. My hypothesis is that once Freeimage is unbound, its bundled libraries are not added as dependencies within the package, and therefore will not be able to be referenced.

Also, the readme states that it does not require additional build dependencies outside what is already in system.devel.

You *do not* need to have any other third party library (libjpeg, libpng, libtiff, libmng and zlib)
installed on your /usr/lib directory in order to compile and use the library.
FreeImage uses its own versions of these libraries. This way, you can be sure that FreeImage will
always use the latest version of each third party library.

I was wondering how you suggest I submit my changes for review. I'm sure the unbinding patch was added for good reason, so I also wanted to get your opinion on the movement to remove it.

With this fixed, I would also like to volunteer to maintain

Event Timeline

css459 created this task.Jan 18 2019, 8:17 PM

Sounds like you need to link to some system libraries when you build your software. For example, jpeg_std_error is provided by so you'll need -ljpeg flag during link process. TIFFSetSubDirectory is provided by thus you need to add -ltiff.

The freeimage package by default uses the static libraries by default and in that way there is no need to refer to these system libraries when using it to build other projects. The "unbound" patch used in the FreeImage package makes the compiled freeimage libraries use the shared object. Thus you need to provide the flags to link to system libraries as needed. Using shared library is the preferred way to go in most linux distributions.

css459 added a comment.EditedJan 19 2019, 2:21 AM

Yes you're right. Unfortunately in this scenario I left out many, many more undefined reference errors, so I would need to link just about every library Freeimage uses. Things might break even still if the Freeimage authors used a different version of these libraries.

From what I can tell of the authors' Readme, this is the behavior they would like to avoid. I think in this situation, static linking might be the preferred route, especially since these errors are internal to Freeimage -- When using a given library, I would expect that I would not have to link other libraries to facilitate the internal workings of the library I used.

I think at the very least, the libraries listed should be run time dependencies, but it would be much cleaner to have these dependencies baked into the Freeimage library as intended.

And Thanks for your help! I'll try this with EmulationStation and see if it works.

I'd check if there are any path changes or removal of them, check as well as functionality changes of freeimage or @kyrios123 could give some advise as he added that patch :)

Thanks again! I have also opened to fix this issue (and it also introduces some other CVE patches in addition to the unbinding patch already present).

If there's anything I can investigate here to alleviate the workload of other maintainers, just point me in the right direction and I'll check it out :)

Girtablulu triaged this task as Normal priority.Mar 11 2019, 10:13 AM
Girtablulu moved this task from Backlog to Package Fixes on the Software board.

What's the status of this? I hit this myself trying to package imv

Do the maintainers think this is an issue with the packaging program, or the way Freeimage is implemented? Knowing how the packager handles external references and dynamic linkages might help to diagnose the reason why they aren't being picked up. I believe ldd picked up the references when I tried it awhile ago.

lbrpdx added a subscriber: lbrpdx.Mar 14 2020, 5:17 PM

It looks like this issue is still on, after a year without updates. Any reason why this hasn't been officially fixed?
@css459 any pointer on how I can install your version in the meantime?
Thank you!

Hi @lbrpdx ,

I too haven't approached this issue for well over a year now, since I never got an answer from the maintainers if this was related to how the packaging software handles dynamic links, or something related to Freeimage. If you need to use the package, I had success building it separately the way the original Freeimage maintainers describe it at their homepage:

Thanks @css459 - I could compile and install it locally. Too bad you did not get any answer from the maintainers, as it's clearly broken for over a year now.