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