This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
| Other format: | [Raw text] | |
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:
pgp00000.pgp
Description: PGP signature
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |