Re: [gentoo-science] .la files harmful to BLAS/LAPACK structure

[Aisha Tammy]

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