On 10/21/20 6:21 PM, François Bissey wrote:
Hi all,
So on and off removal of la files generated by libtool is discussed.
science packages have now a strong incentive to remove them everywhere
they can.
It all started when I was examining the output of ldd -r on libgiac.so
in the sage-on-gentoo overlay and I noticed that my selected openblas
wasn’t the one being picked up. Netlib’s blas and lapack was picked up
instead. There was still an instance of openblas via gsl.
I had to ask myself why that was. The ldso selection works by putting
a path to implementation library before /usr/lib{,64} in /etc/ld.so.conf.
That way when library are resolved at runtime your blas/lapack implementation
is chosen first.
This mechanism can be thrown off if the library/executable has any RUNPATH
set as those are resolved first. And there it was, in libgiac.so I had
RUNPATH=//usr/lib64/ [yes with a double / not a mistake].
I inspected giac’s code for a couple of days trying to see where it was coming
from.
In the end it wasn’t from anything in the code. The final clue was that
when linking, not only did I have -Wl,-rpath //usr/lib64 coming out of
nowhere libnauty was linked as /usr/lib64/libnauty.so instead of -lnauty.
Indeed, you are correct, this is not something we want.
We are actively working to remove these wherever we find them.
Unfortunately we are very short on volunteers and helpers.
And indeed our new nauty ebuild, following debian’s lead, ship a library
and installs .la files. Removing those .la files resulted in libgiac.so
linking properly, the RUNPATH being removed and my choice of blas/lapack
being respected.
So what packages still ship .la files that would be of concern to us as they
interfere with blas/lapack?
* All the suitesparse ebuilds - that are not explicitly multibuild (messes up
glpk).
* All the coinor ebuilds - probably with the same exceptions for mutlibuild.
* dev-libs/igraph (0.7.1-r2 at least, concerning as it links to blas/lapack)
I am maintaining igraph, the new versions don't install .la files, they use
proper pkg-config .pc files.
* libsemigroup [sage-on-gentoo]
* gap [sage-on-gentoo]
This package is messed up.
I am currently trying to upgrade this one for the ::science overlay
but the outlook is bleak. I might just tell people to use the package
in ::sage-on-gentoo, though currently my ebuild does manually remove
the .la files.
Theres just too many subpackages...
* sci-libs/iml (concerning since it links to cblas)
* sys-cluster/mpich
I am doubtful this package has any problems, the cluster team ebuilds are good
and there are active people in the project.
* dev-libs/libltdl
There are more installed here that look less dangerous but we never know,
we should pursue elimination across the tree.
Anything using libtool to build and depending on any of these, will inherit
//usr/lib{,64}/ as a RUNPATH.
François
Thanks a lot for the information, unfortunately this is cumbersome work and
ultimately we are very short on people.
If you could open bugs on bugs.gentoo.org that would be helpful to keep
track of these. Emails tend to be forgotten.
If you are interested, sending patches to fix this in a PR would be the best
solution and we would really appreciate the help :)
In any case, there is little we can do in a short amount of time, this is in
for the long haul.
Best,
Aisha
