------- Comment #2 from rob1weld at aol dot com 2009-03-14 03:54 ------- (In reply to comment #1) > Subject: Re: New: The Driver hides "undefined reference" messages from > shared libs (but not object files) in linker phase > Sent from my iPhone Hurray for Phones with large screens.
> On Mar 11, 2009, at 9:27 PM, "rob1weld at aol dot com" > <gcc-bugzi...@gcc.gnu.org> wrote: > > The Driver hides "undefined reference" messages from shared libs but > > not from object files. This seems inconsistent and is not helpful. > Why do you think the driver is doing instead of the linker? The linker, upon 'discovering' the problem, simply prints: ../../interfaces/C/.libs/libppl_c.so: undefined reference to `typeinfo for int' collect2: ld returned 1 exit status By using the Objects, instead of the Shared Library, I force it to make the discovery early and report ALL the details instead of trying to unmangle the C++, resulting in this more verbose message: ../../interfaces/C/.libs/ppl_c__BD_Shape_mpq_class.o: In function `sgn<Parma_Polyhedra_Library::Checked_Number<__gmp_expr<__mpz_struct [1], __mpz_struct [1]>, Parma_Polyhedra_Library::Extended_Number_Policy> >': /usr/share/src/ppl-build/interfaces/C/../../src/ppl.hh:11187: undefined reference to `typeinfo for int' My ld is: # ld --version GNU ld (GNU Binutils) 2.19.1 I'm building with "-g" and the Shared Library is not stripped: # file /usr/share/src/ppl-build/interfaces/C/.libs/libppl_c.so /usr/share/src/ppl-build/interfaces/C/.libs/libppl_c.so: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped I say it is "the Driver" and not "xgcc / gcc", or "ld" since if "the Driver" took the _ridiculous_ step of noticing the Linker error and re-running the compile (using the objects used to create the Shared Library) the "the Driver" could produce the more verbose output that I RFE'd in favour of. Notice I mentioned that actually implementing that behavior by re-running the compiler is not efficient. Using "-g" needs to pass _more_ info to the Linker, to be included in the Shared Libraries produced, so that if there is a Linker error then 'ld' can reference the source code where the error was caused and display it. The way we are producing Shared Libraries gives us very terse error messages that seem as though the Shared Library were stripped (when they are not). Is there a problem with the manner in which the PPL source is written ? I'm not very fluent in C++. Rob -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39439
