Filippo/Carmelo/all: > The patches fixes the infinite loop and extend the backtrace support in > statically linked app, > has been committed in master branch and cherry piched in 0.9.33 branch. > Moreover to properly build the libubacktrace you should manually apply > the patch posted in > http://lists.uclibc.org/pipermail/uclibc/2013-May/047772.html > It will be committed shortly if no objections are raised.
Gathered all this together and did a build. First off, using the tip of uClibc resulted in other strange error I didn't expect: Apparently, down deep in our code, there is a reference to __close(). In the 0.9.33.2 code (currently being "shipped" with CrossTool-NG), this is a valid library call. In the tip, however, I get an "undefined reference to `__close'". A bit more digging into this one made me think that there was a fundamental issue with the build of libc. Back-porting ONLY the changes since Thursday night (the following list): ldso/ldso/ldso.c ldso/libdl/libdl.c libc/misc/elf/dl-support.c libc/misc/internals/__uClibc_main.c libubacktrace/Makefile.in libubacktrace/arm/Makefile.arch libubacktrace/arm/backtrace.c libubacktrace/backtrace.c resulted in a toolchain that would execute both our proprietary app and the backtrace example from the man 3 backtrace page. Neither of these two applications listed a backtrace. Only one line is printed with an address (presumably of the backtrace function call). It appears that, since the reference to dlopen was removed from libubacktrace/backtrace.c, that the libgcc_s.so.1 is removed from the equation entirely. Believing this, I'm attempting to revert the changes made to that file so that we still attempt to dlopen the libgcc_s.so.1 library prior to performing the backtrace. I'll let the list know whether this works. I think we are almost there (I hope). Andy _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
