From: Wheeler, F. (CRD) <wh...@cr...> - 2002-01-12 16:06:51
|
I just solved a strange build problem for myself that is somehow related to VXL, CMake and my particular environment. I don't know if there is any particular change that should be made to VXL or CMake, but this took me so long to track down I thought I should briefly report it. Sometime over the past week or two CMake started producing makefiles that use the "-shared -nostdlib" options instead of "-Wl,-G" to link objects into a shared library (*.so). With this change all of VXL still builds for me, but just about all executables produced in the VXL tree stop with a Bus Error immediately after starting. Everything build fine, but nothing runs. Strange. I'm using Solaris 2.7. I saw this problem on both gcc-3.0.3 and gcc-3.0.2. I isolated the problem (to some extent) by first backing off the compiler version, which I changed recently, then backing off the VXL source tree about a month, and then backing off the CMake source tree about a month (a desperate guess that I really didn't think would have any effect, but it did). I added these lines to my CMakeCache... CMAKE_MODULE_BUILD_FLAGS:STRING=-Wl,-G CMAKE_SHLIB_BUILD_FLAGS:STRING=-Wl,-G Fred Wheeler -- Fred Wheeler, GE CRD, KWC-303 Phone: 518-387-7225 (GE Internal Dialcom: 8*833-7225) Fax: 518-387-4042 (GE Internal Dialcom: 8*833-4042) |
From: Brad K. <bra...@ki...> - 2002-01-13 01:50:40
|
Fred, > Sometime over the past week or two CMake started producing makefiles > that use the "-shared -nostdlib" options instead of "-Wl,-G" to link > objects into a shared library (*.so). With this change all of VXL > still builds for me, but just about all executables produced in the > VXL tree stop with a Bus Error immediately after starting. > Everything build fine, but nothing runs. Strange. We recently switched the flags from -Wl,-G to -shared -nostdlib to solve other problems. The -shared flag is the correct choice..."-Wl,-G" tells the C++ compiler to pass the "-G" option to the linker, which tells it to create a shared library. However, the C++ compiler then does not know that the code it is generating is going into a shared library, so it doesn't put in the correct static data initialization code (to call constructors of static data, etc). The -shared option tells the compiler to put in the proper init code, and automatically causes it to pass the -G option on to the linker. Have you done a complete re-build of VXL in a clean directory? Your problems may be caused by some .o files or libraries being built with the old flags, and some with the new. -Brad |
From: Peter V. <Pet...@es...> - 2002-01-13 09:47:18
|
> constructors of static data, etc). The -shared option tells the compiler > to put in the proper init code, and automatically causes it to pass the -G > option on to the linker. Try adding "-v" on the compile (link) line to see what gcc really does. I've had similar problems on solaris, but in my case it was because of a missing "-nostdlib". In that case, it's exactly in the call to the global destructors that the program crash occurs: gdb test_vcl_compiler (gdb) r 0 1 Program received signal SIGSEGV, Segmentation fault. 0xef293558 in __do_global_dtors_aux () from libvcl.so which seemed to suggest that the problem lies in the extra global ctors/dtors which "-shared" adds. But when I use "-Wl,-G" instead of "-shared", it's the same. The former does collect2 -V -Y P,/usr/ccs/lib:/usr/lib -Qy /gcc/.../crt1.o \ /gcc/.../crti.o /usr/ccs/lib/values-Xa.o /gcc/.../crtbegin.o \ -L... -G *.o -lgcc -lc -lgcc /gcc/.../crtend.o /gcc/.../crtn.o while the latter does: collect2 -V -G -dy -z text -Y P,/usr/ccs/lib:/usr/lib -Qy \ /gcc/.../crti.o /usr/ccs/lib/values-Xa.o /gcc/.../crtbegin.o \ -L... *.o -lgcc_s -lgcc -lgcc_s -lgcc /gcc/.../crtend.o /gcc/.../crtn.o Now the problem (at least here) is with the -lgcc, because when I remove all -l... from the collect2 line, the shared library is less than half as large, and the program runs OK! But strange enough, when I use -nostdlib (either with -shared or -Wl,-G) also all the crt*.o disappear from the link line. Is this correct behaviour? Anyhow, most programs runs OK in both cases, but I've seen problems with std::vector initialisation, in both cases. -- Peter. |