| 1 |
> On 22/10/2020, at 1:23 PM, Aisha Tammy <gentoo.science@×××××.cc> wrote: |
| 2 |
> |
| 3 |
> On 10/21/20 6:21 PM, François Bissey wrote: |
| 4 |
>> Hi all, |
| 5 |
>> So on and off removal of la files generated by libtool is discussed. |
| 6 |
>> science packages have now a strong incentive to remove them everywhere |
| 7 |
>> they can. |
| 8 |
>> It all started when I was examining the output of ldd -r on libgiac.so |
| 9 |
>> in the sage-on-gentoo overlay and I noticed that my selected openblas |
| 10 |
>> wasn’t the one being picked up. Netlib’s blas and lapack was picked up |
| 11 |
>> instead. There was still an instance of openblas via gsl. |
| 12 |
>> I had to ask myself why that was. The ldso selection works by putting |
| 13 |
>> a path to implementation library before /usr/lib{,64} in /etc/ld.so.conf. |
| 14 |
>> That way when library are resolved at runtime your blas/lapack implementation |
| 15 |
>> is chosen first. |
| 16 |
>> This mechanism can be thrown off if the library/executable has any RUNPATH |
| 17 |
>> set as those are resolved first. And there it was, in libgiac.so I had |
| 18 |
>> RUNPATH=//usr/lib64/ [yes with a double / not a mistake]. |
| 19 |
>> I inspected giac’s code for a couple of days trying to see where it was coming from. |
| 20 |
>> In the end it wasn’t from anything in the code. The final clue was that |
| 21 |
>> when linking, not only did I have -Wl,-rpath //usr/lib64 coming out of |
| 22 |
>> nowhere libnauty was linked as /usr/lib64/libnauty.so instead of -lnauty. |
| 23 |
> Indeed, you are correct, this is not something we want. |
| 24 |
> We are actively working to remove these wherever we find them. |
| 25 |
> Unfortunately we are very short on volunteers and helpers. |
| 26 |
> |
| 27 |
|
| 28 |
Yes, I should shoulder my bit in time. I have a whole backlog of stuff |
| 29 |
for suitesparse. It is particularly annoying. |
| 30 |
|
| 31 |
|
| 32 |
>> And indeed our new nauty ebuild, following debian’s lead, ship a library |
| 33 |
>> and installs .la files. Removing those .la files resulted in libgiac.so |
| 34 |
>> linking properly, the RUNPATH being removed and my choice of blas/lapack |
| 35 |
>> being respected. |
| 36 |
>> So what packages still ship .la files that would be of concern to us as they |
| 37 |
>> interfere with blas/lapack? |
| 38 |
>> * All the suitesparse ebuilds - that are not explicitly multibuild (messes up glpk). |
| 39 |
>> * All the coinor ebuilds - probably with the same exceptions for mutlibuild. |
| 40 |
>> * dev-libs/igraph (0.7.1-r2 at least, concerning as it links to blas/lapack) |
| 41 |
> |
| 42 |
> I am maintaining igraph, the new versions don't install .la files, they use |
| 43 |
> proper pkg-config .pc files. |
| 44 |
> |
| 45 |
>> * libsemigroup [sage-on-gentoo] |
| 46 |
>> * gap [sage-on-gentoo] |
| 47 |
> This package is messed up. |
| 48 |
> I am currently trying to upgrade this one for the ::science overlay |
| 49 |
> but the outlook is bleak. I might just tell people to use the package |
| 50 |
> in ::sage-on-gentoo, though currently my ebuild does manually remove |
| 51 |
> the .la files. |
| 52 |
> Theres just too many subpackages... |
| 53 |
> |
| 54 |
|
| 55 |
Possible good news, latest gap has a package manager, we may be able to |
| 56 |
do something similar to R with it. Although there are causing me grief |
| 57 |
because they don’t follow the now standard flow of gap package having |
| 58 |
a GitHub repo. And when they do they sometime lack proper release. |
| 59 |
|
| 60 |
>> * sci-libs/iml (concerning since it links to cblas) |
| 61 |
>> * sys-cluster/mpich |
| 62 |
> I am doubtful this package has any problems, the cluster team ebuilds are good |
| 63 |
> and there are active people in the project. |
| 64 |
> |
| 65 |
|
| 66 |
Combining MPI and blas/lapack or say scalapeck is common. mopish install |
| 67 |
a .la file and I am concerned. I haven’t checked openmpi which is libtool |
| 68 |
heavy. |
| 69 |
|
| 70 |
>> * dev-libs/libltdl |
| 71 |
>> There are more installed here that look less dangerous but we never know, |
| 72 |
>> we should pursue elimination across the tree. |
| 73 |
>> Anything using libtool to build and depending on any of these, will inherit |
| 74 |
>> //usr/lib{,64}/ as a RUNPATH. |
| 75 |
>> François |
| 76 |
> |
| 77 |
> Thanks a lot for the information, unfortunately this is cumbersome work and |
| 78 |
> ultimately we are very short on people. |
| 79 |
> If you could open bugs on bugs.gentoo.org that would be helpful to keep |
| 80 |
> track of these. Emails tend to be forgotten. |
| 81 |
|
| 82 |
My time is unfortunately in rather short supply too. But I’ll do my best. |
| 83 |
|
| 84 |
> |
| 85 |
> If you are interested, sending patches to fix this in a PR would be the best |
| 86 |
> solution and we would really appreciate the help :) |
| 87 |
> |
| 88 |
> In any case, there is little we can do in a short amount of time, this is in |
| 89 |
> for the long haul. |
| 90 |
|
| 91 |
I updated the sage-on-gentoo repo where it made sense but yes this is time consuming. |
| 92 |
I wanted to raise awareness to that particular issue. |
| 93 |
|
| 94 |
François |
Archives