LD_ASSUME_KERNEL problem

LD_ASSUME_KERNEL problem

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 645 bytes --]


The usual "hack" to switch between i686 and non-i686 libpthreads on a
x86 system is to use LD_ASSUME_KERNEL and setting it to some old
version, e.g. 2.2.5.

But if you put such libraries on a 64-bit system with i686 support
that has also a 64-bit glibc e.g AMD64 or ia64, the environment
variable will have effect on both 32-bit and 64-bit libraries and you
cannot execute anymore 64-bit code :-(

So, what can we do?  We need a better way IMO to switch libraries to
not affect all installed glibcs.  Any good ideas?

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]

Re: LD_ASSUME_KERNEL problem

[Roland McGrath]

> So, what can we do?  We need a better way IMO to switch libraries to
> not affect all installed glibcs.  Any good ideas?

Do you have a suggestion?  For the path elements that come from the hwcap
list, you can exercise some control with LD_HWCAP_MASK.  "i686" comes from
dl_platform, i.e. AT_PLATFORM.  An override for that in glibc would have
the same issue, though you could override it in the kernel somehow specific
to 32-bit processes.  We could add something like LD_EXCLUDE_PLATFORM to
give platform/hwcap strings that should not be put into the search list
when they normally would (then you could use that for "tls" as well).

Re: LD_ASSUME_KERNEL problem

[Andreas Jaeger]

[-- Attachment #1: Type: text/plain, Size: 1261 bytes --]

Roland McGrath <roland@redhat.com> writes:

>> So, what can we do?  We need a better way IMO to switch libraries to
>> not affect all installed glibcs.  Any good ideas?
>
> Do you have a suggestion?  For the path elements that come from the hwcap

As a quick hack I disabled LD_ASSUME_KERNEL but that's not a
solution.  We could introduce a new variable for the 64-bit ports but
that's not elegant either.

> list, you can exercise some control with LD_HWCAP_MASK.  "i686" comes from
> dl_platform, i.e. AT_PLATFORM.  An override for that in glibc would have
> the same issue, though you could override it in the kernel somehow specific
> to 32-bit processes.  We could add something like LD_EXCLUDE_PLATFORM to
> give platform/hwcap strings that should not be put into the search list
> when they normally would (then you could use that for "tls" as well).

do you think of e.g:
LD_EXCLUDE_PLATFORM:i686/sse,x86_64/tls

to exclude sse on i686 and tls on x86_64?

Yeah, something like this sounds plausible.

Yes, tls is important to consider, we might want to have this
different on one platform for different glibcs.

Andreas
-- 
 Andreas Jaeger
  SuSE Labs aj@suse.de
   private aj@arthur.inka.de
    http://www.suse.de/~aj

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]