750479 – sci-libs/lapack shouldn't install lib*.so.3 files in /usr/lib{,64}

Bug 750479 - sci-libs/lapack shouldn't install lib*.so.3 files in /usr/lib{,64}

Summary: sci-libs/lapack shouldn't install lib*.so.3 files in /usr/lib{,64}

Status:	RESOLVED INVALID

Alias:	None

Product:	Gentoo Linux
Classification:	Unclassified
Component:	Current packages (show other bugs)
Hardware:	All Linux

Importance:	Normal normal (vote)
Assignee:	Gentoo Linux bug wranglers

URL:
Whiteboard:
Keywords:

Depends on:
Blocks:

Reported:	2020-10-20 21:23 UTC by François Bissey
Modified:	2020-10-20 23:13 UTC (History)
CC List:	1 user (show)

See Also:
Package list:
Runtime testing required:	---

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description François Bissey 2020-10-20 21:23:03 UTC

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

Comment 1 François Bissey 2020-10-20 23:13:02 UTC

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.