| Summary: | sci-libs/lapack shouldn't install lib*.so.3 files in /usr/lib{,64} | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | François Bissey <frp.bissey> |
| Component: | Current packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED INVALID | ||
| Severity: | normal | CC: | frp.bissey |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
No that I have got back in touch with how the current framework operates, I realise that this is not possible. The only thing of note is that the framework is vulnerable in case RUNPATH is set to something pointing to a regular system path. This can happen if you have .la files hanging around. See https://bugs.gentoo.org/show_bug.cgi?id=750482 for example. |
Currently BLAS/LAPACK packages install appropriate sonamed library in an implementation subfolder of /usr/lib{,64}. But in the case of sci-libs/lapack the default library names are also the generic ones. This can interfere with proper blas/lapack runtime selection if a library/executable happens to have /usr/lib{,64} as a RUNPATH. Or as in the case of giac in the sage-on-gentoo overlay, //usr/lib{,64} [the extra leading "/" is probably why it is not discarded by autotools - I cannot figure how it ends up there but that is a separate issue]. Reproducible: Always