Bug 2299

More information:

This is because the /lib64/libc.so.6 loaded before /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 when the pseudo runs,
export LD_PRELOAD=/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 would fix the problem, a solution maybe use a wrapper for pseudo, for example:

mv pseudo pseudo.real
echo LD_PREPLOAD=/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 pseudo $@ > pseudo

(In reply to comment #1)
> More information:
> 
> This is because the /lib64/libc.so.6 loaded before
> /opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6 when the
> pseudo runs,
> export
> LD_PRELOAD=/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6
> would fix the problem, a solution maybe use a wrapper for pseudo, for example:
> 
> mv pseudo pseudo.real
> echo
> LD_PREPLOAD=/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6
> pseudo $@ > pseudo

Put the following two lines in the wrapper doesn't work:
export LD_PRELOAD=/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6
pseudo.real $@

But manually:
export LD_PRELOAD=/opt/poky/1.1+snapshot/sysroots/x86_64-pokysdk-linux/lib/libc.so.6
works.

I guess that this is because the shell has loaded the host's libc.so.6, so
put the LD_PRELOAD in the wrapper doesn't work. Need help, anyone who is interested on
it please feel free to take it.

Created attachment 474 [details]
can not find GLIBC_2.14

This patch is still in testing.

Update information:

It is caused by the --libdir=${prefix}/lib/pseudo/lib${SITEINFO_BITS}, this makes pseudo search every library that it needs in ${prefix}/lib/pseudo/lib{SITEINFO_BITS} firstly, and if not found, it would seasch in the system libdir, our libc.so.6 is in ${prefix}/lib/, not in ${prefix}/lib/pseudo/lib${SITEINFO_BITS}, so it can't found our libc.so.6, and will use the one on the host, so the error comes, there is a draft patch, I'm still testing it before send the patch review, any suggestions is appreciated:

I don't know why we installed the libpseudo.so to ${prefix}/lib/pseudo/lib, so I fixed
the pseudo-native, pseudo-nativesdk and the target pseudo, this seems dangerous at the current stage, I'd like to only fix pseudo-nativesdk, in fact.

The patch is in the attachment(still in testing):

https://bugzilla.yoctoproject.org/attachment.cgi?id=474

I had a look into this problem. Even if we change pseudo so the correct rpath is in both the pseduo binary and in libpseudo itself, the problem still occurs since tar loads the libc from the system path.

I think your change happens to work since pseudo persists the LD_LIBRARY_PATH which happens to make things work.

I'm wondering if we set LD_LIBRARY_PATH in a wrapper for pseudo, whether that will fix things...

I've posted a patch for review on the oe-core mailing list.

(In reply to comment #6)
> I've posted a patch for review on the oe-core mailing list.
Thank you very much, I've tried to edit: 
/opt/poky/1.2/sysroots/x86_64-pokysdk-linux/usr/bin/oe-find-native-sysroot
with your suggestion:

Change:
PSEUDO="$OECORE_NATIVE_SYSROOT/usr/bin/pseudo"
to:
PSEUDO="env LD_LIBRARY_PATH=$OECORE_NATIVE_SYSROOT/lib $OECORE_NATIVE_SYSROOT/usr/bin/pseudo"

Then it works.

I will build a new sdk with your patch which seems better tonight, and will reply the
testing result tomorrow.

Fix merged into master: http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=f562e2a393d69312281ceda1d2b2b0af03a8c8b5

FYI the proposed patch in comment #4 is incorrect.

pseudo wrapper belongs in a sub directory location.  This is because we do not know if the host sysroot "/lib" is 32-bit or 64-bit.  We have to have a way to distinguish between the two.  Also we do not want to impact the system's LD_LIBRARY_PATH, unless the users really want that (by specifying as the patch from Richard does.)

In short, the pseudo wrapper library must be somewhere that is not normally searched by the system library routines.

I'm really confused by this, simply because I thought pseudo was nearly-always using host libc.  Are we building a local native libc that's newer than host libc?  If so, that's outside my original plan, and yes, we'd need to do something fancy.  We don't want libpseudo.so to be in the directory providing the new libc, I don't think.

(In reply to comment #10)
> I'm really confused by this, simply because I thought pseudo was nearly-always
> using host libc.  Are we building a local native libc that's newer than host
> libc?  If so, that's outside my original plan, and yes, we'd need to do
> something fancy.

Yes, we build a libc that is equal or newer than the host libc.

>  We don't want libpseudo.so to be in the directory providing
> the new libc, I don't think.

We install it into a separate subdir as in the native and target cases.

On FC16 32bit, the fixing in comment #8 will result a segmentation fault in tar.

Not sure, but is the segfault there maybe fixed by the since-proposed change to create_wrapper which removes the attempt to "test" the variable assignments?

No, the change to create_wrapper will have zero effect on this issue :(

Taking a step back here a second, the issue is that we need to be able to use libpseudo on systems with an older host libc even if the native libc is newer. The problem, is that when compiled against a newer libc, there are "GLIBC_2.14" symbols which cause it to fail on an older libc.

We've demonstrated in the other open pseudo bug that we can't mix one dynamic loader with another libc, this is bad and hence we need to remove the workaround added in the pseudo wrapper. Looking at the libc code, its clear they're incestuous and can't be independent. 

Would one solution be to force libpseudo to use older symbol versions? We could do this by adding:

__asm__(".symver memcpy,memcpy@GLIBC_2.2.5");

into the pseudo code. I mention memcpy specifically as its the only 2.14 symbol used, the next oldest is GLIBC_2.7 for which there are two references, then we're back to 2.3.4 (output from objdump -T libpseudo.so).

So the proposal is to:
a) Drop the LD_LIBRBARY_PATH
b) Have libpseudo.so use older symbol versioning for memcpy

Fixed in master with http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=604fc2adce743294cbad631993ce17e7bfcf17ab and also applied to the denzil branch

Got fixed and verify on poky/denzil:35196ff703726addf7f4051ee09d70bf9ee0c5d0