[poky] New staging error

[Mark Hatle]

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.)

--Mark

>> I'd suggest checking to see if you can figure out what caused the
>> message so we can get it fixed. But if you are unable to figure it out,
>> you'll need to clean and rebuild pseudo-native. (I don't remember the
>> clean target to ignore the sstate cache... or maybe we're planning on
>> adding one and haven't yet.) You may need to 'rm' pseudo from the sstate
>> cache. To force it to build fresh.
>
>