libtool's .la files "implicitly" influence build results in some cases

[sogaiu]

I mentioned this in https://github.com/andrewchambers/hpkgs/issues/90#issuecomment-638004920 but I thought it would be worth having a separate issue.

While working on fontconfig I noticed that the build results were being influenced by the existence of .la files (libtool) in some of its dependencies.

One of fontconfig's direct dependencies is freetype2 and this in turn depends on libpng and zlib.

With the way I had packaged libpng, a .la file would be among its build artifact's files. Note that zlib doesn't have any corresponding .la files.

fontconfig uses libtool as part of its build and this leads to .la files from dependencies being consulted:

libtool works implicitly whenever it is used to build a library or a program. In the former case, it creates the .la file with used flags; it latter, it reads those files and uses the flags stored in them.

via: https://wiki.gentoo.org/wiki/Pkg-config#libtool_archives_.28.la_files.29

I haven't found any way to tell the build system (fontconfig's anyway) to ignore the .la files, so as a work-around I had the dependent packages remove .la files from their build artifacts.

My sense at the moment is that unless all of the pieces have .la files and are in some sense designed to work together (e.g. xorg), it is simpler to just use pkg-config if that can be used. I suppose I should see what happens for xorg if I remove them from its packages as well.

FWIW, here is a Debian "Release Goal" related to removal of .la files: https://wiki.debian.org/ReleaseGoals/LAFileRemoval -- it contains a link to a post with discussion: https://lists.debian.org/debian-devel/2009/08/msg00783.html

Various .hpkg file links for reference:

• fontconfig
• freetype2
• libpng
• zlib

[sogaiu]

I suppose I should see what happens for xorg if I remove them from its packages as well.

I gave it a try and found that just removing .la files causes problems. However, additonally setting LD_RUN_PATH in some packages appropriately (only referencing direct dependency-related info) seems to have made things work enough so that st could be built and run successfully.

Ah, I also used -Wl,--allow-shlib-undefined in at least one xorg package to get things to work out. I've now used this in a few packages with some success.

[sogaiu]

In this StackOverflow answer, there is a claim that RedHat doesn't include .la files (for the most part?) in their rpms:

With that said, removing the .la files is not necessarily unreasonable. Libtool has good reasons for creating them, but the residual benefit from installing them to the system along with the libraries themselves may not balance the drawbacks. RedHat, for one, has long held the view that it does not, so it in fact does not include the .la files in its RPM packages, and its packaging guidelines specify that third-party packagers should not do so either.

On a related note, in https://github.com/andrewchambers/hpkgs/issues/95#issuecomment-638520318 I noted that the curl.hpkg I'm fiddling with wasn't receptive to LD_RUN_PATH. It may be because there is a .la file which the curl build process creates and then uses during the build.

~I will experiment with removing that to see if LD_RUN_PATH can be made to function.~

I tried a different hack with success. Will report in other issue.