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: http://freeimage.sourceforge.net/

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.

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

Updating D5097: [RFC] Rebuild 3.18.0 to bind freeimage to use internal libraries

It looks like Debian also uses a similar patch. I think separating the libraries is more important for non-rolling distros, but since the package is maintained by the Debian Scientific Team, I think you're right in that we should probably keep the unbinding patch for that reason.

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.

I understand this is still pre-release software, so I reached out to the developer to see if an official release is coming soon. The software appears to gave good traction in the music community and about 1k stars on GitHub. Of course, it is ultimately your decision if that traction is indeed significant, so I submitted the changes requested. Thanks again for your patience as this is my first Solus package I have worked to release.

Change Summary

Totally understandable! Thanks for clarifying :)

Not meaning to argue, but what is wrong with it being a single file? Surely it could still benefit from package management via system updates instead of installing by hand?

Fixed sort order of deps and alphabetical sort of pkg-config deps

I have a working package.yml (with pspec_x86_64.xml) that creates an eopkg successfully. How exactly would I submit this with arc since the following link looks like it walks through modifying an existing package? I might be misunderstanding, however.