Regression caused by commit 7682323a3a798d6f15708f228f859a64cb869aa3

[Carmelo AMOROSO]

On 11/01/2012 8.44, Khem Raj wrote:
>>> khem ? any news ?
>>
>> no unfortunately, had no time to delve further. once I have turned a
>> merge into patch which was causing the regression, let me go down that
>> path.
>> let
> 
> hi Carmelo
> 

Hi khem

> Attached patch is causing the trouble. and I have
> 

ok

> # LDSO_STANDALONE_SUPPORT is not set
> # LDSO_PRELINK_SUPPORT is not set
> 

ok

> and since I see the same issue on all architectures probably its not
> elfinterp changes
> too. Mostly it seems likely that it could be in the way the scopes are
> being handled
> 

we have reviewed several times this change before committing. Anyway we
will review it again. We have not ever seen any failure in the lookup
with all of our tests. The only change in the way the symbol scope is
created is in where the ld.so is added.
In the original code it was the last entry of the global scope, while
with the new structure in place it was added as soon as found (as glibc
actually does).... and I don't really think this could have some impact.

We are trying to startup a X system on our platform. Is there any simple
X app we can run to show the failure ?

Is some .so failing to be dl-opened due to unresolved symbol ?

> I can reproduce it by exchanging ld.so and libdl.so
> 

it is reasonable considering the code impacted by the offending patch

> while I keep looking more can you see anything visually in this patch would help
> 

I'll re-re-look again

> i tried with latest master and problem happens there too.
> 

yes, not changes have been applied to the symbol scope logic further.

> Thanks
> -Khem

to you.
Carmelo