Default libprefix on Debian like distribution seems not good.

[mgautierfr]

By default, on 64 bits Debian like distribution, meson will install library in /usr/local/lib/x86_64-linux-gnu.
However, this directory is not in the library searched path by default (/usr/local/lib is), and so, the library cannot be linked.

Here a small reproducer using this small test project test_meson.tar.gz :

$ cd test_meson
$ meson src build
$ cd build
$ sudo ninja install
$ mytestprogram
mytestprogram: error while loading shared libraries: libmytestlib.so: cannot open shared object file: No such file or directory

To be honest, I'm not sure it is a meson bug. On Fedora, /usr/local/lib is even not in the default search paths. Searching a bit about this issue, it seems that it is not a easy case, different distributions will set different multiarch libprefix and default library search paths. (and lib/x86_64-linux-gnu is the good libprefix if installing in /usr)

However, it seems really surprising, that using the default options, meson is installing something "not working".

[jonassmedegaard]

Would be quite helpful if someone could confirm if this issue affects Debian and report their findings here.

...and based on such findings, the subject was renamed from current vague "Debian like distribution" to either "Debian and derived distributions" or "Ubuntu.

[gadLinux]

I can confirm this also happens on ubuntu latest release:

DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=17.10
DISTRIB_CODENAME=artful
DISTRIB_DESCRIPTION="Ubuntu Artful Aardvark (development branch)"

[gadLinux]

There's a file in /etc/ld.so.conf.d/x86_64-linux-gnu.conf where it should be added the default route.
/usr/local/lib/x86_64-linux-gnu/
I think is more a problem on Ubuntu over that file than meson.

[kelson42]

@jonassmedegaard Same "business" with Debian unstable.

[kelson42]

I think the root cause might be in Debian. See that bug & patch (unfortunately still in review after 2 years) https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=685519

[mokafolio]

so what is the workaround for now? Even if you install in a non default directory, the resulting libraries are still wrapped in an extra folder describing the architecture :(

[jonassmedegaard]

According to Debian bug https://bugs.debian.org/685519 referenced above, this issue was fixed since glibc 2.25-4 release December 2017 and included in stable Debian 10 (a.k.a. Buster) released in the spring.

@mokafolio which system do you use where this is still an issue?

[mokafolio]

I am on ubuntu 19.04 using meson version 0.51.2. When I leave libdir and prefix as default, it still encapsulates the resulting libraries into an extra folder describing the architecture, i.e. instead of installing to /usr/local/lib, it will install to /usr/local/lib/x86_64-linux-gnu the only way to avoid this is to to explicitly set libdir to lib.

[jonassmedegaard]

The issue tracked here is that default lib path is broken, not that default /usr/local path includes multiarch.

The fix done in December 2017 was to have glibc properly resolve multiarch paths below /usr/local.

@mokafolio Could you please tell: Do the code work and its paths just look weird to you, or do glibc fail to resolve the "weirdly" placed libraries? Answering that can help clarify it this issue is in fact solved by now, and can be closed.

I recommend that, regardless of whether it works or not, if you feel that meson is wrong in using multiarch paths by default you file that as a separate issue to avoid confusing+bloating this one.

[mokafolio]

@jonassmedegaard the weird looking paths are not resolved. Sorry for hijacking this thread, that was not my intention. I'll setup a simple test program, create a new issue and link it from here for future reference. Thanks!

[jonassmedegaard]

Uhm, I am confused now - or maybe my choice of words was ambiguous: When talking about "paths being resolved" I specifically mean glibc internally making sense of the paths generated by meson instead of failing to make sense of it (I did not mean if all issues related to this topic was fixed).

@mokafolio: When you say "the weird looking paths are not resolved" do you then talk about the same as me? What error message do you get when it fails?

[mokafolio]

@jonassmedegaard Please check the separate issue. It explains things in more detail including error messages and a demo project to reproduce the issue. Thank you!

[dabrain34]

running sudo ldconfig seems to fix the issue on debian/ubuntu

[ubitux]

AFAIU lib/x86_64-linux-gnu/ is valid if and only if the prefix is not changed. Because if you decide to install in a custom environment location (let's say with --prefix /tmp/foo), you most certainly do not want /tmp/foo/lib/x86_64-linux-gnu but /tmp/foo/lib.

[dabrain34]

#4737