Re: dlsym(RTLD_NEXT) failures on ARM and MIPS with LD_PRELOAD w/ 0.9.33.2
On Thursday 20 September 2012 22:09:52 Carmelo AMOROSO wrote: On 20/09/2012 8.36, Florian Fainelli wrote: Hi all, Hi Florian, Hi Carmelo, I just updated two systems to uClibc 0.9.33.2/NPTL (ARMv5 and MIPS32r1), and I now see dlsym() returning NULL for a symbol where it should not. Does it mean that with an older version is worked ? if so, which one ? it could help to identify the problem, if any. The version we updated from was 0.9.30.2 which is quite old, I will start a bisection to pin point the exact commit introducing the issue. The situation is the following: 1) application foo links against shared library mylib and in particular the symbol bar 2) mylib2 is a shared library providing a modified bar symbol and performing a dlsym(RTLD_NEXT, bar) to get the bar symbol address in mylib and finally call this symbol. 3) foo is started that way: LD_PRELOAD=libmylib2.so foo I am yet to be able to write down a reduced test-case exposing the issue, because so far, the problem is appearing only in a much larger mylib and foo though they both do not do much more than what is described above. I have not tried uClibc's master yet. Any hints would be appreciated Thanks! cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
dlsym(RTLD_NEXT) failures on ARM and MIPS with LD_PRELOAD w/ 0.9.33.2
Hi all, I just updated two systems to uClibc 0.9.33.2/NPTL (ARMv5 and MIPS32r1), and I now see dlsym() returning NULL for a symbol where it should not. The situation is the following: 1) application foo links against shared library mylib and in particular the symbol bar 2) mylib2 is a shared library providing a modified bar symbol and performing a dlsym(RTLD_NEXT, bar) to get the bar symbol address in mylib and finally call this symbol. 3) foo is started that way: LD_PRELOAD=libmylib2.so foo I am yet to be able to write down a reduced test-case exposing the issue, because so far, the problem is appearing only in a much larger mylib and foo though they both do not do much more than what is described above. I have not tried uClibc's master yet. Any hints would be appreciated Thanks! -- Florian ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
Re: dlsym(RTLD_NEXT) failures on ARM and MIPS with LD_PRELOAD w/ 0.9.33.2
On 20/09/2012 8.36, Florian Fainelli wrote: Hi all, Hi Florian, I just updated two systems to uClibc 0.9.33.2/NPTL (ARMv5 and MIPS32r1), and I now see dlsym() returning NULL for a symbol where it should not. Does it mean that with an older version is worked ? if so, which one ? it could help to identify the problem, if any. The situation is the following: 1) application foo links against shared library mylib and in particular the symbol bar 2) mylib2 is a shared library providing a modified bar symbol and performing a dlsym(RTLD_NEXT, bar) to get the bar symbol address in mylib and finally call this symbol. 3) foo is started that way: LD_PRELOAD=libmylib2.so foo I am yet to be able to write down a reduced test-case exposing the issue, because so far, the problem is appearing only in a much larger mylib and foo though they both do not do much more than what is described above. I have not tried uClibc's master yet. Any hints would be appreciated Thanks! cheers, Carmelo ___ uClibc mailing list uClibc@uclibc.org http://lists.busybox.net/mailman/listinfo/uclibc
