On 26 Jan 2016 21:48, Alex McWhirter wrote: > On 01/26/2016 09:08 PM, Mike Frysinger wrote:
> > On 26 Jan 2016 19:23, Alex McWhirter wrote:
> >> On 01/26/2016 07:20 PM, Mike Frysinger wrote:
> >>> On 26 Jan 2016 18:30, Alex McWhirter wrote:
> >>>> If using symlink_lib=no, shoud 32bit libraries be placed in lib32 or
> >>>> lib? If we use lib32 we need to modify the base layout to compensate for
> >>>> this.
> >>> there should be no lib32 under sparc. /usr/lib/ holds 32-bit libs
> >>> just like a 32-bit install, and /usr/lib64/ holds 64-bit libs.
> >> The sparc multilib profile overrides this and uses lib32 with a symlink.
> >> But using lib is probably a better option as it seems like the way
> >> everything else works.
> > right ... this is part of the "we don't want SYMLINK_LIB=yes" logic.
> > this is probably all you need to start with:
> > --- a/profiles/default/linux/sparc/experimental/multilib/parent
> > +++ b/profiles/default/linux/sparc/experimental/multilib/parent
> > @@ -1,3 +1,3 @@
> > ..
> > ../../../../../releases/13.0
> > -../../../../../features/multilib/lib32
> > +../../../../../features/multilib
> If the goal is to abandon the symlink, why did we decide to use it in
> the first place? It seems like only amd64 does this, however it is the
> default behavior from the multilib feature. Has this just been carried
> over from the old rudimentary multilib support before the current
> multilib functionality was finalized?
yes, it's legacy cruft that we haven't been able to migrate away from
yet. we were able to drop it on other arches because their multilib
users were largely non-existent, but amd64 has always had an extensive
user base. if we can figure out how to migrate them, we will at some
point. see: https://bugs.gentoo.org/506276
since sparc's multilib userbase does not exist, we have time to fix
that mistake. so if that diff above works for you, i'll just push it.