lrtaylor@xxxxxxxxxx wrote:
Is there a particular reason you're using -nostdlib when building your library:
g++ -shared -nostdlib /usr/lib/crti.o /mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/crtbeginS.o .libs/lib_func.o .libs/validation_exception.o .libs/exception.o -Wl,--rpath -Wl,/mu/dev/gcc/3.3.1/lib/. -Wl,--rpath -Wl,/mu/dev/gcc/3.3.1/lib/. -L/mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1 -L/mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/../../.. /mu/dev/gcc/3.3.1/lib/./libstdc++.so -lm -lc -lgcc_s /mu/dev/gcc/3.3.1/lib/gcc-lib/i686-pc-linux-gnu/3.3.1/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,liblixo-0.1.0.so -o .libs/liblixo-0.1.0.so
In order for exceptions to be thrown across a library boundary, your library needs to be linked properly. I suspect it's not. Why not just let g++ determine what standard libraries to link to, etc.? You might also try adding the argument --eh-frame-hdr which is needed for setting up stack unwinding. I don't know if it will work the way you're doing things, though...
Thanks,
Lyle
Hi Lyle,
The -nostdlib flag was set by a (more or less vanilla) autoconf-automake-with-libtool run. I didn't set it manualy. Anyway, libstdc++ and libgcc (shared version libgcc_s) are manualy linked later on, as you can see also in your run. Is there some startup action being lost in this built process by using the flag?
As for the linker flag, quoting the g++ man page:
"However, if a library or main executable is supposed to throw or catch exceptions, you must link it using the G++ or GCJ driver, as appropriate for the languages used in the program, or using the option -shared-libgcc, such that it is linked with the shared libgcc."
But it looks like libgcc_s is being linked in.
Any idea on what might be going on?
Thank you,
João Luis
