lconfig-native is not endian safe
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?
Cheers,
Richard
Quoted 8 lines · Richard Purdie
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.
Quoted 8 lines
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
Quoted 9 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
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.
Thanks,
Nitin
Quoted 61 lines
-----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 safeQuoted 3 lines · Richard Purdie
Hi,
Poky has had a ldconfig-native recipe in for a while. Back in the
times
Quoted 1 line
our RPATHS were totally broken adding in an ld.so.cache was useful.
In
Quoted 1 line
modern times I'm having trouble working out when this would be useful
on
Quoted 1 line
a standard system as libraries are pretty much always in one of the
two
Quoted 3 lines
default search locations.
ldconfig-native is 32/64 bit safe. I've just been looking at PPC and
it
Quoted 1 line
is certainly not endian safe though. The endianess of the target
system
Quoted 6 lines
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
Quoted 9 lines
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
Quoted 10 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Kamble, Nitin A
Sent: Wednesday, March 30, 2011 7:00 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] lconfig-native is not endian safe
Quoted 3 lines
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.
Quoted 77 lines
Thanks,
NitinQuoted 3 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 5 lines
Mark Hatle
Sent: Wednesday, March 30, 2011 8:44 AM
To: [email protected]
Subject: Re: [OE-core] lconfig-native is not endian safeQuoted 8 lines
Quoted 3 lines · Richard Purdie
Hi,
Poky has had a ldconfig-native recipe in for a while. Back in the
times
Quoted 1 line
our RPATHS were totally broken adding in an ld.so.cache was useful.
In
Quoted 1 line
modern times I'm having trouble working out when this would be
useful
Quoted 6 lines
on
Quoted 1 line
a standard system as libraries are pretty much always in one of the
two
Quoted 3 lines
default search locations.
ldconfig-native is 32/64 bit safe. I've just been looking at PPC
and
Quoted 4 lines
it
Quoted 1 line
is certainly not endian safe though. The endianess of the target
system
Quoted 1 line
need to match that of the build system for it to work. It wouldn't
be
Quoted 7 lines
Quoted 5 lines
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?
Quoted 5 lines
I know I prefer to NOT use ldconfig in the systems I design, but I understand
why people want it.Quoted 17 lines
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
Quoted 9 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 6 lines
_______________________________________________
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
Quoted 7 lines
Quoted 5 lines
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?
Quoted 89 lines
Quoted 21 lines
Thanks,
NitinQuoted 3 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 11 lines
Mark Hatle
Sent: Wednesday, March 30, 2011 8:44 AM
To: [email protected]
Subject: Re: [OE-core] lconfig-native is not endian safeQuoted 3 lines · Richard Purdie
Hi,
Poky has had a ldconfig-native recipe in for a while. Back in the
times
Quoted 1 line
our RPATHS were totally broken adding in an ld.so.cache was
useful.
Quoted 5 lines
Quoted 2 lines
In
Quoted 1 line
modern times I'm having trouble working out when this would be
useful
Quoted 2 lines
on
Quoted 1 line
a standard system as libraries are pretty much always in one of
the
Quoted 9 lines
Quoted 4 lines
two
Quoted 3 lines
default search locations.
ldconfig-native is 32/64 bit safe. I've just been looking at PPC
and
Quoted 4 lines
it
Quoted 1 line
is certainly not endian safe though. The endianess of the target
system
Quoted 1 line
need to match that of the build system for it to work. It
wouldn't
Quoted 2 lines
be
Quoted 1 line
Quoted 1 line
much work to make it endian safe though although the codebase
will
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
diverge further from that in (e)glibc though.
Short term we need to disable it at least for ppc, longer term
what
Quoted 19 lines
Quoted 3 lines
Quoted 1 line
should we do?
On ARM, are the structures packed in the same way as the target
system?
Quoted 15 lines
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
Quoted 2 lines
Cheers,
Quoted 14 lines
Quoted 7 lines
Quoted 7 lines
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 6 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 5 lines
_______________________________________________
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
My opinion is to avoid it vs run in a qemu shell. I really don't like being forced to have qemu to run a build of any type.
Quoted 107 lines · Nitin A
Quoted 7 lines
Quoted 5 lines
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?Quoted 85 lines
Quoted 21 lines
Thanks,
NitinQuoted 3 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 11 lines
Mark Hatle
Sent: Wednesday, March 30, 2011 8:44 AM
To: [email protected]
Subject: Re: [OE-core] lconfig-native is not endian safeQuoted 3 lines · Richard Purdie
Hi,
Poky has had a ldconfig-native recipe in for a while. Back in the
times
Quoted 1 line
our RPATHS were totally broken adding in an ld.so.cache was
useful.
Quoted 5 lines
Quoted 2 lines
In
Quoted 1 line
modern times I'm having trouble working out when this would be
useful
Quoted 2 lines
on
Quoted 1 line
a standard system as libraries are pretty much always in one of
the
Quoted 9 lines
Quoted 4 lines
two
Quoted 3 lines
default search locations.
ldconfig-native is 32/64 bit safe. I've just been looking at PPC
and
Quoted 4 lines
it
Quoted 1 line
is certainly not endian safe though. The endianess of the target
system
Quoted 1 line
need to match that of the build system for it to work. It
wouldn't
Quoted 2 lines
be
Quoted 1 line
Quoted 1 line
much work to make it endian safe though although the codebase
will
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
diverge further from that in (e)glibc though.
Short term we need to disable it at least for ppc, longer term
what
Quoted 19 lines
Quoted 3 lines
Quoted 1 line
should we do?
On ARM, are the structures packed in the same way as the target
system?
Quoted 15 lines
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
Quoted 2 lines
Cheers,
Quoted 14 lines
Quoted 7 lines
Quoted 7 lines
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 6 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreQuoted 4 lines
_______________________________________________
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
Quoted 2 lines · Mark
My opinion is to avoid it vs run in a qemu shell. I really don't like being forced to have qemu to run a build of any type.
Agreed, I think we can avoid this.
For reference, I have half he endian problem resolved with:
which handles reading in the data from the elf files in an endian safe way. Someone needs to go through and change the dl cache file handling code to be endian safe though, then compare the result with a file generated on a target device.
Cheers,
Richard
Re: ldconfig-native is not endian safe
Quoted 23 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Richard Purdie
Sent: Thursday, March 31, 2011 3:41 AM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] lconfig-native is not endian safeQuoted 1 line · Mark
My opinion is to avoid it vs run in a qemu shell. I really don't
like
Quoted 1 line
being forced to have qemu to run a build of any type.
Agreed, I think we can avoid this.
For reference, I have half he endian problem resolved with:
http://git.yoctoproject.org/cgit.cgi/poky-
contrib/commit/?h=rpurdie/gcc- sharedwork&id=0711c7c065c6e1caa04f452069d08a056c3caabe
Quoted 9 lines
which handles reading in the data from the elf files in an endian safe way. Someone needs to go through and change the dl cache file handling code to be endian safe though, then compare the result with a file generated on a target device.
Cheers,
Richard
Richard,
I upgraded ldconfig-native to 2.12.1 ( our eglibc version), I rebased your patch to it, and will implement rest of the endianness handling code.
Thanks,
Nitin
Quoted 6 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 6 lines · Nitin A
Quoted 6 lines
Quoted 5 lines
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.
Quoted 6 lines
Quoted 1 line
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.
Quoted 95 lines
Quoted 86 lines
Quoted 22 lines
Thanks,
NitinQuoted 3 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On BehalfOf
Quoted 11 lines
Mark Hatle
Sent: Wednesday, March 30, 2011 8:44 AM
To: [email protected]
Subject: Re: [OE-core] lconfig-native is not endian safeQuoted 3 lines · Richard Purdie
Hi,
Poky has had a ldconfig-native recipe in for a while. Back in the
times
Quoted 1 line
our RPATHS were totally broken adding in an ld.so.cache was
useful.
Quoted 5 lines
Quoted 2 lines
In
Quoted 1 line
modern times I'm having trouble working out when this would be
useful
Quoted 2 lines
on
Quoted 1 line
a standard system as libraries are pretty much always in one of
the
Quoted 9 lines
Quoted 4 lines
two
Quoted 3 lines
default search locations.
ldconfig-native is 32/64 bit safe. I've just been looking at PPC
and
Quoted 4 lines
it
Quoted 1 line
is certainly not endian safe though. The endianess of the target
system
Quoted 1 line
need to match that of the build system for it to work. It
wouldn't
Quoted 2 lines
be
Quoted 1 line
Quoted 1 line
much work to make it endian safe though although the codebase
will
Quoted 3 lines
Quoted 3 lines
Quoted 3 lines
diverge further from that in (e)glibc though.
Short term we need to disable it at least for ppc, longer term
what
Quoted 19 lines
Quoted 3 lines
Quoted 1 line
should we do?
On ARM, are the structures packed in the same way as the target
system?
Quoted 15 lines
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
Quoted 2 lines
Cheers,
Quoted 14 lines
Quoted 7 lines
Quoted 7 lines
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 6 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Quoted 5 lines
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-coreQuoted 4 lines
_______________________________________________
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
Quoted 8 lines · Richard Purdie
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.
Quoted 6 lines
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.
FWIW it does not work with uclibc as well. So it should be disabled for uclibc for all arches
Quoted 11 lines
Short term we need to disable it at least for ppc, longer term what should we do?
Cheers,
Richard
_______________________________________________
poky mailing list
[email protected]
https://lists.yoctoproject.org/listinfo/poky
Richard Purdie
AppliedQuoted 14 lines · Khem Raj
Quoted 6 lines · Richard Purdie
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.
Quoted 6 lines
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.
Quoted 2 lines
FWIW it does not work with uclibc as well. So it should be disabled for uclibc for all arches
I've queued a patch to do this.
Cheers,
Richard