On Fri, Jan 6, 2017 at 10:17 AM, Oron Peled <oron@xxxxxxxxxxxx> wrote: > On Friday, 6 January 2017 03:51:42 IST Kevin Kofler wrote: > >> ... > >> * I do not see any practical advantage of Debian multiarch over FHS > >> multilib. > > > > Good question, multiarch is a huge win for *embedded* developers. > > > > Let me give real life example from my $day job: > > * We build stuff for arm and x86_64 (I ignore our legacy platforms > > like x86, ppc, whatnot...) > > > > * We cross compile most stuff (faster), but not everything is easily > > cross-compilable: > > - Notorious examples are libraries with their own code-generation tools. > > - Examples: thrift, dbus-c++ (you need to *run* built tools) > > - So we build some packages natively (either on real ARM or in chroot with > qemu-user-static). > > > > * With old, non-multiarch scheme: > > - Library packages compiled natively on ARM would be under /usr/lib. > > - But they cannot be installed on the build machine, so I can cross-compile > > applications against them. > > - The workaround was to unpack them, relocate the libraries, headers, etc > > to the prefix expected by cross compiler (e.g: /opt/toolchain/....) and > > repack the result into an "all" architecture package. > > > > * With multiarch distribution (Debian/jessie in my case): > > - Everything is symetric. ARM libraries goes to /usr/lib/arm-linux-gnu > > *regardless* if they were built natively or cross-compiled. > > - These packages may be co-installed on my development host and be used > > by the cross compiler. > > - So I have an ARM repository, everything built (natively + cross) is > uploaded > > there and I can pull library dependencies into my build environment. > > - And the *exact* same binary packages installed on the ARM target are > > installed and being used by the cross compilers. > > Much of what I would have said has been said by Oron (some of this I've said in earlier parts of this thread, as well). But the bigger thing is that it makes it much easier to bootstrap new architectures for Fedora, too, as we can start from libraries and build up to applications relatively easily. It doesn't completely solve the issue, as there would still be some conflicts, but it makes it a lot less challenging. Enabling things like being able to do test and development with arbitrary architectures would be a huge boon, as well. That being said, I would be in remiss to indicate that platform libdirs (what Debian calls multiarch libdirs) are able to be implemented in a backwards-compatible way. Debian was able to pull it off because they originally used /lib32 and /lib64, but migrated to /lib/i386-linux-gnu and /lib/x86_64-linux-gnu (while creating symlinks to point to them). We should be able to do the same. The main break will be that /usr/lib will no longer contain archful data, and that's going to be a difference no matter how you slice it. We could elect to do /usr/lib32 and that would still be an improvement of the situation over what we have now, but it's still a break (though not necessarily one that will break third party applications). If we don't want to do full platform libdirs, I would really like us to move 32-bit libraries to /usr/lib32. It would just be much cleaner on the filesystem that way. If we do full platform libdirs, I would like us to have the symlinks for /usr/lib32 and /usr/lib64 to point to the correct places, too. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
