------- Comment #3 from pinskia at gmail dot com 2009-03-14 06:14 ------- Subject: Re: The Driver hides "undefined reference" messages from shared libs (but not object files) in linker phase
Sent from my iPhone On Mar 13, 2009, at 8:54 PM, "rob1weld at aol dot com" <gcc-bugzi...@gcc.gnu.org > wrote: > > > ------- 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 The linker is suppressing the undefined reference in the first place when creating the .so. I think this is a bug in ppl's make file and not gcc. > > > > 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 > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39439
