* LD_ASSUME_KERNEL problem
@ 2003-06-17 13:38 Andreas Jaeger
2003-06-25 6:11 ` Roland McGrath
0 siblings, 1 reply; 3+ messages in thread
From: Andreas Jaeger @ 2003-06-17 13:38 UTC (permalink / raw)
To: GNU libc hackers
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: LD_ASSUME_KERNEL problem
2003-06-17 13:38 LD_ASSUME_KERNEL problem Andreas Jaeger
@ 2003-06-25 6:11 ` Roland McGrath
2003-06-25 7:09 ` Andreas Jaeger
0 siblings, 1 reply; 3+ messages in thread
From: Roland McGrath @ 2003-06-25 6:11 UTC (permalink / raw)
To: Andreas Jaeger; +Cc: GNU libc hackers
> 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).
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: LD_ASSUME_KERNEL problem
2003-06-25 6:11 ` Roland McGrath
@ 2003-06-25 7:09 ` Andreas Jaeger
0 siblings, 0 replies; 3+ messages in thread
From: Andreas Jaeger @ 2003-06-25 7:09 UTC (permalink / raw)
To: Roland McGrath; +Cc: GNU libc hackers
[-- 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 --]
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2003-06-25 7:09 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-06-17 13:38 LD_ASSUME_KERNEL problem Andreas Jaeger
2003-06-25 6:11 ` Roland McGrath
2003-06-25 7:09 ` Andreas Jaeger
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).