Install libraries as per GNU Coding Standards

[dwrobel]

Includes GNUInstallDirs and uses LIBDIR (instead of hardcoded lib)
to install libraries.

Fixes packaging on aarch64 systems where LIBDIR=lib64 (not lib).

Signed-off-by: Damian Wrobel [email protected]

[XECDesign]

Attaching my version that I use to build the userland packages for Raspberry Pi OS, in case there's something worth adding from there (like pkgconfig path fixes).

gnu_install_paths.txt

[HinTak]

Does this change also have the side effect of moving the installed libraries from /opt/vc/lib to /opt/vc/lib64 for the default (no extra args) installation? If that's the case, it makes life more complicated. 32-bit raspbian have them under /opt/vc/lib, and also add a non-standard libpath for it at /etc/ld.so.conf.d/00-vmcs.conf.

[HinTak]

64-bit ubuntu seems not to bother with "lib64" at all:

$ ls -l /usr/lib/pkgconfig /usr/lib/aarch64-linux-gnu/pkgconfig /usr/share/pkgconfig
/usr/lib/aarch64-linux-gnu/pkgconfig:
total 12
-rw-r--r-- 1 root root 348 Feb 28  2020 geoclue-2.0.pc
lrwxrwxrwx 1 root root  12 Mar 10  2020 libcrypt.pc -> libxcrypt.pc
-rw-r--r-- 1 root root 390 Mar 10  2020 libxcrypt.pc
-rw-r--r-- 1 root root 119 Mar 11  2020 xorg-wacom.pc

/usr/lib/pkgconfig:
total 4
-rw-r--r-- 1 root root 182 Apr  6 08:17 libdmmp.pc

/usr/share/pkgconfig:
total 44
-rw-r--r-- 1 root root  133 May 20 13:58 adwaita-icon-theme.pc
-rw-r--r-- 1 root root  328 Feb  2  2020 bash-completion.pc
-rw-r--r-- 1 root root  260 Mar 18  2018 fontutil.pc
-rw-r--r-- 1 root root  211 Oct  3  2019 iso-codes.pc
-rw-r--r-- 1 root root  300 Feb 17  2020 mobile-broadband-provider-info.pc
-rw-r--r-- 1 root root  120 Mar 24 15:58 shared-mime-info.pc
-rw-r--r-- 1 root root 2159 Jul  6 21:38 systemd.pc
-rw-r--r-- 1 root root   61 Jul  6 21:38 udev.pc
-rw-r--r-- 1 root root  206 Feb 28  2020 xkbcomp.pc
-rw-r--r-- 1 root root  171 Feb 29  2020 xkeyboard-config.pc
-rw-r--r-- 1 root root  480 Mar 10  2020 yelp-xsl.pc

[XECDesign]

I'd vote for getting rid of /opt and sticking to standard GNU paths for everything by default. If a user wants to install to opt, then that's easy enough to do through the usual configure parameters.

[HinTak]

I'd have been okay with it if that happened at the beginning - but after files having been under /opt for some years, it is a bit of a pain to switch, even if that's the correct direction.

Besides, I think a few bits and pieces in userland are still closed-source, so the appropriate place of installation is indeed /opt .

[XECDesign]

Better late than never. The current setup causes headaches for multiarch support.

The closed bits don't ship in this repo, so that shouldn't things.

[HinTak]

Do people actually want multi-arch on a pi? Seems easier just swapping an SD card! (that's what I am doing at the moment...).

[XECDesign]

Well, it's easier because you can't just apt install some things right now. If you could easily install armhf kodi (or whatever else you might need) on the 64bit image, then why bother switching cards?

[HinTak]

Also multi-arch made sense on x86_64, because there are enough older (and closed source) software, or for which re-compiling-from-source is not convenient or even an option. That's not the eco-system on pi - there is little incentive to run 32-bit binaries on 64-bit os, or vice versa. The few and must-have closed-source software on pi are basically those which are closed-source here - the broadcom firmware tools, etc.

[XECDesign]

minecraft-pi comes to mind, but I'm sure a lot of people have software they can't easily rebuild. I'm told widevine also doesn't have an arm64 build.

If it multiarch, worked from the start, we would've been able to support mathematica, accelerated chromium and vlc right away.

But you're right, it's not THAT important, which is why I haven't gone out of my way to work it yet. Proper native arm64 packages are preferred wherever possible.

[HinTak]

Raspbian is available officially as a 64-bit release only 3 months ago? I assume mathematica etc will follow at some point. Anyway, I think some system (perhaps ubuntu?) have the policy of putting "main" libs in /usr/lib whichever arch it is, and if on 64-bit needing 32-bit support, adds a lib32 instead.

Anyway, my point is that /opt/vc is more worrying, and there are perhaps enough scripts etc depending on / assuming that location. Having another variant /opt/vc/lib64 vs /opt/vc/lib is more pain...

[dwrobel]

The assumption was that this patch shouldn't cause any harm on Ubuntu/Debian derivatives (although I don't have any possibilities to test it).

It also has no impact whether libraries will be installed on the /opt/vc/lib or any other location as this can be changed using standard CMAKE variables - it only tries to respect the value of LIBDIR - which on some systems is set to lib64 (even cmake is mentioning it here).

[dwrobel]

I found that on Ubuntu there is a patch to achieve the same goal, see: https://launchpad.net/ubuntu/+source/raspberrypi-userland/0~20200520+git2fe4ca3-0ubuntu2 debian/patches/fix-multiarch-dir.patch file.

[HinTak]

It is not available yet - I just did a apt update ; apt search rasp on my pi, currently running Ubuntu 20.04/64-bit. (I have another sd card with 32-bit raspbian on...)

[dwrobel]

It is not available yet

I just wanted to point out that they need to patch it as well.

[crabbedhaloablution]

I was just working on something similar for eventual inclusion into Gentoo. Please merge.

[dwrobel]

I was just working on something similar for eventual inclusion into Gentoo. Please merge.

I originally prepared that for Fedora where it's being used for both armv7hl and aarch64 architectures: https://github.com/rpmfusion/raspberrypi-vc/blob/9fe0bc4696734b1acf42a59a734d758c479fc034/raspberrypi-vc.spec#L20. Having it merged would be appreciated as it will simplify packaging.

[stefwalter]

Thanks @dwrobel this patch helped me with my own build of raspberrypy-vc. What are the remaining obstacles to merging it? May I help?