> -----Original Message-----
> From: Adrian Schröter <[email protected]>
> Sent: 11 December 2019 08:26
> To: Guillaume Gardet <[email protected]>
> Cc: Andreas Färber <[email protected]>; openSUSE ARM ML <opensuse-
> [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 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.
People are not always aware of hardware limitation, so they will be able to
install some packages which would maybe not run on their system.
Maybe a runtime test could do a check and enable/disable the 32-bit support?
Cheers,
Guillaume
>
> --
>
> 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]
IMPORTANT NOTICE: The contents of this email and any attachments are
confidential and may also be privileged. If you are not the intended recipient,
please notify the sender immediately and do not disclose the contents to any
other person, use it for any purpose, or store or copy the information in any
medium. Thank you.
--
To unsubscribe, e-mail: [email protected]
To contact the owner, e-mail: [email protected]
