On 3/30/2011 7:09 PM, Kamble, Nitin A wrote:


I have updated the ldconfig-native to match the version of eglibc
2.12.1, but that still does not solve the endienness problem of cross
ppc.

BTW ldconfig's endienness issue is also for mips&  armeb.

Another solution I was thinking of was:
   Use the target ldconfig in qemu shell. (like the glibc locales were 
generated earlier).
Does it make sense to do it that way, or is it better to just not generate the 
ld.so.cache?


hmm we got rid of qemu for locales for a reason :). Think of people who do not build for qemu machines but real hardware now they have to build
qemu just for this.



Thanks,
Nitin


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf
Of
Mark Hatle
Sent: Wednesday, March 30, 2011 8:44 AM
To: [email protected]
Subject: Re: [OE-core] lconfig-native is not endian safe

On 3/30/11 9:47 AM, Richard Purdie wrote:
Hi,

Poky has had a ldconfig-native recipe in for a while. Back in the
times
our RPATHS were totally broken adding in an ld.so.cache was
useful.
In
modern times I'm having trouble working out when this would be
useful
on
a standard system as libraries are pretty much always in one of
the
two
default search locations.

ldconfig-native is 32/64 bit safe. I've just been looking at PPC
and
it
is certainly not endian safe though. The endianess of the target
system
need to match that of the build system for it to work. It
wouldn't
be
much work to make it endian safe though although the codebase
will
diverge further from that in (e)glibc though.

Short term we need to disable it at least for ppc, longer term
what
should we do?

On ARM, are the structures packed in the same way as the target
system?

I know I prefer to NOT use ldconfig in the systems I design, but I
understand
why people want it.

I suggest we disable it on PPC for now, and work on updating endian
support,
(packing if necessary) and make sure that it supports the latest
ldconfig
features of being able to use referenced directories and such.

--Mark

Cheers,

Richard


_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
core


_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-
core

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core


_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core

Reply via email to