[poky] New staging error

[Gary Thomas]

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

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------