Re: New staging error

[Richard Purdie <rpurdie@linux.intel.com>]

On Tue, 2010-11-09 at 12:08 -0700, Gary Thomas wrote:
> On 11/09/2010 09:14 AM, Mark Hatle wrote:
> > On 11/9/10 10:12 AM, Gary Thomas wrote:
> >> On 11/09/2010 08:28 AM, Mark Hatle wrote:
> >>> On 11/9/10 6:58 AM, Gary Thomas wrote:
> >>>> With the new staging (master of 2010-11-08), I'm seeing lots of these
> >>>> messages
> >>>> when I build from scratch:
> >>>>
> >>>> NOTE: Running setscene task 81 of 364
> >>>> (/local/poky-amltd/meta/recipes-core/sysvinit/sysvinit_2.88dsf.bb:do_populate_sysroot_setscene)
> >>>>
> >>>>
> >>>> NOTE: package netbase-4.41-r1: task do_populate_sysroot_setscene:
> >>>> Started
> >>>> NOTE: Staging package
> >>>> /home/local/poky-new2/sstate-cache/sstate-netbase-ppc603e-poky-linux-4.41-r1-ppc603e-1-83766f23e3f9013cb26b768478638f1d_populate-sysroot.tgz
> >>>>
> >>>> does not exist
> >>>> ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be
> >>>> preloaded: ignored.
> >>>> ERROR: ld.so: object 'libpseudo.so' from LD_PRELOAD cannot be
> >>>> preloaded: ignored.
> >>>>
> >>>> Questions:
> >>>> * What does this mean? Can I fix it somehow?
> >>>> * If it's ignored, it should be a WARNING, not an ERROR
> >>>>
> >>>
> >>> It is an error, but unfortunately not one that can caught. (The error
> >>> comes from ld.so, which will happily ignore a failed preload. If someone
> >>> knows how to make it fatal, we should do so!)
> >>>
> >>> I've normally seen the libpseudo.so failed to preload when either you
> >>> are running as root (as a safety precaution against tampering), you've
> >>> upgraded your host's libc since pseudo was built, or suddenly you are
> >>> running 64-bit (or 32-bit) binaries when pseudo is built for the other
> >>> architecture type.
> >>
> >> None of these are the case. I was simply trying to test/verify the
> >> staging
> >> mechanism. I think the error happens because LD_PRELOAD=libpseudo.so
> >> seems
> >> to be set, even before the sysroots tree where it lives has been
> >> populated.
> >
> > Odd -- we definitely want to fix this. Sounds like a bug in the staging
> > code.. (Note, we're working on changing some of the way pseudo loads
> > into memory as well as operates through the run sequence -- so it might
> > have the side effect of fixing this issue.... but it's worth filing this
> > as a bug, and if you have a way to reproduce it file that as well.)
> 
> Verified against the latest master.  Bug #526 filed, including a template
> to reproduce the error.

I can at least explain the bug. What is happening is that the sysroot
directories are totally empty and you're building them from scratch from
the sstate binaries. Some sstate binaries require pseudo to install as
there is permission information that needs to be tracked. The system
therefore tries to load pseudo but since it isn't in the empty sysroot
directory, you see the error.

To confirm the problem, try first running:

bitbake pseudo-native

then whatever the thing you want is.

I'm guessing you will not see the error if you do this in these two
stages. I agree we need to find a way to fix this, if this is the case
but this should at least give you a workaround.

Cheers,

Richard