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 _______________________________________________ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc