LIB32 or LIB?

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

LIB32 or LIB?

alexmcwhirter
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.

Reply | Threaded
Open this post in threaded view
|

Re: LIB32 or LIB?

alexmcwhirter
On 01/26/2016 06:30 PM, 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.
>
I'm going to assume we want to use lib here, as it seems that's what
most other archs use in this case. If i'm wrong let me know.

Reply | Threaded
Open this post in threaded view
|

Re: LIB32 or LIB?

Mike Frysinger
In reply to this post by alexmcwhirter
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.
-mike

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: LIB32 or LIB?

alexmcwhirter
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.
> -mike
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.

Reply | Threaded
Open this post in threaded view
|

Re: LIB32 or LIB?

Mike Frysinger
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
-mike

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: LIB32 or LIB?

alexmcwhirter
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
> -mike

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?

Reply | Threaded
Open this post in threaded view
|

Re: LIB32 or LIB?

Mike Frysinger
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.
-mike

signature.asc (836 bytes) Download Attachment