On Mittwoch, 11. Dezember 2019, 08:23:19 CET Guillaume Gardet wrote: > > > -----Original Message----- > > From: Adrian Schröter <[email protected]> > > Sent: 11 December 2019 08:09 > > To: Andreas Färber <[email protected]> > > Cc: Guillaume Gardet <[email protected]>; openSUSE ARM ML > > <[email protected]>; Andrew Wafaa <[email protected]>; > > Andreas Schwab <[email protected]>; Dirk Müller <[email protected]> > > Subject: Re: [opensuse-arm] arm 32bit vs arm 32bit > > > > On Dienstag, 10. Dezember 2019, 18:06:04 CET Andreas Färber wrote: > > > Hi, > > > > > > Am 10.12.19 um 16:21 schrieb Guillaume Gardet: > > > >> -----Original Message----- > > > >> From: Adrian Schröter <[email protected]> > > > >> Sent: 07 December 2019 12:46 > > > >> To: openSUSE ARM ML ([email protected]) <opensuse- > > > >> [email protected]> > > > >> Subject: [opensuse-arm] arm 32bit vs arm 32bit > > > >> > > > >> Hi, > > > >> > > > >> I was going to add 32bit package configs to repackage armv7hl libs > > > >> for aarch64 installations (for personal need, samsung binary only > > > >> printer driver) > > > >> > > > >> However, I noticed that armv7hl 32bit userland would conflict with > > > >> aarch64_ilp32 definitions. > > > >> > > > >> Was there already any discussion how a mixed arch installation should > > > >> look > > alike? > > > >> > > > >> My proposal would be (for a aarch64 installation): > > > >> > > > >> armv[567]* libs should be installed in /lib (and /usr/lib) via > > > >> *-32bit*.aarch64.rpm /lib to stay compatible with armv[567] > > > >> installations. > > > >> > > > >> aarch64_ilp32 libs should be installed in /lib-ilp32 via > > > >> *-ilp32*.aarch64.rpm current config seems to put these in -32bit > > > >> packages, what seems to be wrong to me. > > > >> > > > >> Do we also need to take care about aarch32? > > > >> > > > >> any opinion about this? > > > > > > > > AFAIK, you cannot use armv7 libs/bins as is on arm64 systems. > > > > > > It depends on the CPU. ThunderX and Kunpeng 920 don't support AArch32 > > > mode, but most Cortex cores still do. > > > > > > I concur that the outlined ilp32-as-32bit setup sounds wrong, in > > > particular since that is not even mainline-supported still. > > > > okay, so I can drop that part of the code again moving ilp32 into /lib for > > compat > > packages .... > > > > > There were discussions or even recommendations on cross-distro or so > > > some years back on naming/placement - Andy might remember. > > > > > > As for AArch32, I assume you mean armv8l? I don't think we currently > > > build any packages for it, at least we have no separate scheduler. > > > > yes, question is if it may appear at some point of time and where to put > > libraries > > then. > > > > but this is maybe to far ahead, if it is /lib as well we would anyway have > > the > > conflict with armv7l. So I think, I just go forward and adapt baselibs > > config to > > generate armv7l (and armv6l?) libs into /lib. > > I think zypper does not allow armv7 rpms to be installed on aarch64. Which is > right for aarch64 SoC which do not support AArch32.
that won't be a problem for the repackaged compat lib packages, since the would appear as aarch64. Similar to what we do on x86_64, eg: libstdc++-devel-32bit-9-1.6.x86_64.rpm so it is a x86_64.rpm which provides the 32bit libs. But you are right, we may want to support also to install armv7hl rpms afterwards for applications. > Not sure how we could handle this difference between SoC properly. me neither, the bins would just not run. But that is a hardware limitation and an OS limitation from my POV. -- Adrian Schroeter <[email protected]> Build Infrastructure Project Manager SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany (HRB 247165, AG München), Geschäftsführer: Felix Imendörffer -- To unsubscribe, e-mail: [email protected] To contact the owner, e-mail: [email protected]
