Open dwrobel opened 4 years ago
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).
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
.
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
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.
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
.
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.
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...).
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?
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.
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.
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...
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).
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.
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...)
It is not available yet
I just wanted to point out that they need to patch it as well.
I was just working on something similar for eventual inclusion into Gentoo. Please merge.
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.
Thanks @dwrobel this patch helped me with my own build of raspberrypy-vc. What are the remaining obstacles to merging it? May I help?
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 dwrobel@ertelnet.rybnik.pl