Hi, Since upgrading to 11.08 I now get a missing symbol for 'stderr' ; needed by libstdc++.a
/usr/local/genode-gcc-x86_32/bin/../lib/gcc/i686-pc-linux-gnu/4.4.5/../../../libstdc++.a(vterminate.o): In function `__gnu_cxx::__verbose_terminate_handler()': /home/dwaddington/svn/genode/tool/gcc_build_x86/i686-pc-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc-4.4.5/libstdc++-v3/libsupc++/vterminate.cc:47: undefined reference to `stderr' /home/dwaddington/svn/genode/tool/gcc_build_x86/i686-pc-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc-4.4.5/libstdc++-v3/libsupc++/vterminate.cc:65: undefined reference to `stderr' /home/dwaddington/svn/genode/tool/gcc_build_x86/i686-pc-linux-gnu/libstdc++-v3/libsupc++/../../../../gcc-4.4.5/libstdc++-v3/libsupc++/vterminate.cc:91: undefined reference to `stderr'
I can hack around it by declaring stderr in my main.cc.
Thanks Daniel
Hallo Daniel,
unfortunately I could not reproduce your issue. Could you please send a simple test case/program? What I did was just editing the target.mk of a simple libc program:
-LIBS = cxx env libm libc libc_log +LIBS = cxx env libm libc libc_log stdcxx
I also discovered that both - libstdc++.a and libsupc++.a - contain the vterminate.o object. This leads to your linking problem if libstdc++.a(vterminate.o) is used instead of the variant from libsupc++ - maybe due to command-line argument order. Our cxx library includes libsupc++ with some private symbols including stderr.
So, a "make VERBOSE= VERBOSE_MK=" build log may also help.
Regards
Hi Christian, The following very simple program will break it for me. Note without the string decl everything is ok.
#include <base/printf.h> #include <base/sleep.h> #include <string>
int main() {
std::string foobar;
Genode::sleep_forever(); return 0; }
TARGET = genode-test SRC_CC = main.cc LIBS = env thread libc libc_log stdcxx
Attached is the build log.
Daniel
On 08/25/2011 01:38 AM, Christian Helmuth wrote:
Hallo Daniel,
unfortunately I could not reproduce your issue. Could you please send a simple test case/program? What I did was just editing the target.mk of a simple libc program:
-LIBS = cxx env libm libc libc_log +LIBS = cxx env libm libc libc_log stdcxx
I also discovered that both - libstdc++.a and libsupc++.a - contain the vterminate.o object. This leads to your linking problem if libstdc++.a(vterminate.o) is used instead of the variant from libsupc++ - maybe due to command-line argument order. Our cxx library includes libsupc++ with some private symbols including stderr.
So, a "make VERBOSE= VERBOSE_MK=" build log may also help.
Regards
Hi Daniel,
thanks to your (admittedly) simple test case I could reproduce and research into the issue (summary follows), which has nothing to do with linking order as I guessed:
First, the 'stderr' symbol is private to the cxx library. This is by intention, as we do not provide a POSIX environment with the Genode base system, but have to make the G++ support library - libsupc++ - happy.
Since 11.08, the dynamic linker does not export all symbols of any library it is linked to to prevent some issues we had during development. It rather uses a whitelist of global symbols that will be exported in os/src/lib/ldso/symbol.map. Any other symbol will become local.
Also, as I stated in the last email libstdc++ seems to include all objects from libsupc++, effectively providing the same symbols but not localized. Therefore, the linker does not nag about undefined (localized) symbols from libsupc++(vterminate.o), but about the consequential error of a missing 'stderr' needed by libstdc++(vterminate.o).
The attached patch fixes the problem but is not approved by our dynamic-linking specialist. As soon as he gives his nod, we'll commit a solution into the public SVN and notify this list.
Regards
Hi Daniel,
The attached patch fixes the problem but is not approved by our dynamic-linking specialist. As soon as he gives his nod, we'll commit a solution into the public SVN and notify this list.
...
just a small follow-up to Christian's email, please remove the binary of the dynamic linker after applying the patch. In the build directory, issue:
rm var/libcache/ld/ld.lib.so
This way, the linker is rebuilt with the changed 'symbol.map' (unfortunately the dependency of 'ld.lib.so' from 'symbol.map' is missing).
Norman
Yes, I see the fix works.
Thanks for your help. Daniel
On 08/26/2011 03:54 AM, Norman Feske wrote:
Hi Daniel,
The attached patch fixes the problem but is not approved by our dynamic-linking specialist. As soon as he gives his nod, we'll commit a solution into the public SVN and notify this list.
...
just a small follow-up to Christian's email, please remove the binary of the dynamic linker after applying the patch. In the build directory, issue:
rm var/libcache/ld/ld.lib.so
This way, the linker is rebuilt with the changed 'symbol.map' (unfortunately the dependency of 'ld.lib.so' from 'symbol.map' is missing).
Norman
EMC VNX: the world's simplest storage, starting under $10K The only unified storage solution that offers unified management Up to 160% more powerful than alternatives and 25% more efficient. Guaranteed. http://p.sf.net/sfu/emc-vnx-dev2dev _______________________________________________ Genode-main mailing list Genode-main@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/genode-main
Hi,
I just committed the fix into the SVN repo on sourceforge as revision r165.
Regards
-
Christian Helmuth -
Daniel Waddington -
Norman Feske