Unintellegible ld error messages

Unintellegible ld error messages

[Paul Koning]

I got these messages from ld (version 2.16):

/usr/local/EQLGCC_v7/mipsel/lib/gcc/mipsel-netbsdelf/4.0.0/../../../../mipsel-netbsdelf/bin/ld: Cli: hidden symbol `_Unwind_GetIP' in /usr/local/EQLGCC_v7/mipsel/lib/gcc/mipsel-netbsdelf/4.0.0/libgcc.a(unwind-dw2.o) is referenced by DSO
/usr/local/EQLGCC_v7/mipsel/lib/gcc/mipsel-netbsdelf/4.0.0/../../../../mipsel-netbsdelf/bin/ld: final link failed: Nonrepresentable section on output

I haven't a clue what these mean.  What'a DSO?  What's a
"nonrepresentable section"?  More importantly, what should I do to
find out what is wrong here?

The map output was aborted, so it doesn't contain any information that
helps me.  The messages are meaningless, and they don't even say which
object file or script entry or library offended the linker.

I even tried looking at the source code.  That tells me that "DSO"
apparently has something to do with shared libraries, but other than
that it doesn't get me any closer to a solution.

       paul

Re: Unintellegible ld error messages

[Daniel Jacobowitz]

On Wed, May 11, 2005 at 03:04:42PM -0400, Paul Koning wrote:
> I got these messages from ld (version 2.16):
> 
> /usr/local/EQLGCC_v7/mipsel/lib/gcc/mipsel-netbsdelf/4.0.0/../../../../mipsel-netbsdelf/bin/ld: Cli: hidden symbol `_Unwind_GetIP' in /usr/local/EQLGCC_v7/mipsel/lib/gcc/mipsel-netbsdelf/4.0.0/libgcc.a(unwind-dw2.o) is referenced by DSO
> /usr/local/EQLGCC_v7/mipsel/lib/gcc/mipsel-netbsdelf/4.0.0/../../../../mipsel-netbsdelf/bin/ld: final link failed: Nonrepresentable section on output
> 
> I haven't a clue what these mean.  What'a DSO?  What's a
> "nonrepresentable section"?  More importantly, what should I do to
> find out what is wrong here?

Dynamic Shared Object.  This is a standard term.  It's not mentioned in
the ld manual; feel free to contribute a patch.

The hidden symbol `_Unwind_GetIP' is being referenced by a shared
library.  Figure out which one it is (I don't remember the reason why
we don't print that here; I believe it's pretty hard to recover from
our data structures at that point).  Then rebuild that library using
'gcc' to link and the symbol should no longer be undefined.

> I even tried looking at the source code.  That tells me that "DSO"
> apparently has something to do with shared libraries, but other than
> that it doesn't get me any closer to a solution.

Google would have been happy to tell you that "DSO" and "shared
library" are basically synonyms.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Unintellegible ld error messages

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> On Wed, May 11, 2005 at 03:04:42PM -0400, Paul Koning wrote:
 >> I got these messages from ld (version 2.16):
 >> 
 >> /usr/local/EQLGCC_v7/mipsel/lib/gcc/mipsel-netbsdelf/4.0.0/../../../../mipsel-netbsdelf/bin/ld:
 >> Cli: hidden symbol `_Unwind_GetIP' in
 >> /usr/local/EQLGCC_v7/mipsel/lib/gcc/mipsel-netbsdelf/4.0.0/libgcc.a(unwind-dw2.o)
 >> is referenced by DSO
 >> /usr/local/EQLGCC_v7/mipsel/lib/gcc/mipsel-netbsdelf/4.0.0/../../../../mipsel-netbsdelf/bin/ld:
 >> final link failed: Nonrepresentable section on output
 >> 
 >> I haven't a clue what these mean.  What'a DSO?  What's a
 >> "nonrepresentable section"?  More importantly, what should I do to
 >> find out what is wrong here?

 Daniel> Dynamic Shared Object.  This is a standard term.  It's not
 Daniel> mentioned in the ld manual; feel free to contribute a patch.

 Daniel> The hidden symbol `_Unwind_GetIP' is being referenced by a
 Daniel> shared library.  Figure out which one it is (I don't remember
 Daniel> the reason why we don't print that here; I believe it's
 Daniel> pretty hard to recover from our data structures at that
 Daniel> point).  Then rebuild that library using 'gcc' to link and
 Daniel> the symbol should no longer be undefined.

The offending library is libstdc++, as compiled by GCC 4.0.0.  This
seems very strange.

      paul

Re: Unintellegible ld error messages

[Daniel Jacobowitz]

On Fri, May 13, 2005 at 03:44:46PM -0400, Paul Koning wrote:
> The offending library is libstdc++, as compiled by GCC 4.0.0.  This
> seems very strange.

Then something's probably wrong with your GCC build environment; no one
else seems to encounter this warning with libstdc++.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Unintellegible ld error messages

[Paul Koning]

>>>>> "Daniel" == Daniel Jacobowitz <drow@false.org> writes:

 Daniel> On Fri, May 13, 2005 at 03:44:46PM -0400, Paul Koning wrote:
 >> The offending library is libstdc++, as compiled by GCC 4.0.0.
 >> This seems very strange.

 Daniel> Then something's probably wrong with your GCC build
 Daniel> environment; no one else seems to encounter this warning with
 Daniel> libstdc++.

It turns out that libgcc.so has _Unwind_GetIP as a regular symbol, but
libgcc.a has it as a hidden symbol.  One of my builds only has the .a
version of libgcc, so that's why that link fails (while others for
another target work fine).

	paul

Re: Unintellegible ld error messages

[Alan Modra]

On Fri, May 13, 2005 at 04:07:56PM -0400, Paul Koning wrote:
> It turns out that libgcc.so has _Unwind_GetIP as a regular symbol, but
> libgcc.a has it as a hidden symbol.  One of my builds only has the .a
> version of libgcc, so that's why that link fails (while others for
> another target work fine).

_Unwind_GetIP as a hidden symbol in libgcc.a is not the problem.  If you
built libstdc++.so linked against libgcc_s.so, then when linking using
libstdc++.so you need to have libgcc_s.so available, and, importantly,
libgcc_s.so must be linked before libgcc.a if both are specified.

If you built libstdc++.so only linked against libgcc.a, then you can use
libstdc++.so like that too.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Unintellegible ld error messages

[Paul Koning]

>>>>> "Alan" == Alan Modra <amodra@bigpond.net.au> writes:

 Alan> On Fri, May 13, 2005 at 04:07:56PM -0400, Paul Koning wrote:
 >> It turns out that libgcc.so has _Unwind_GetIP as a regular symbol,
 >> but libgcc.a has it as a hidden symbol.  One of my builds only has
 >> the .a version of libgcc, so that's why that link fails (while
 >> others for another target work fine).

 Alan> _Unwind_GetIP as a hidden symbol in libgcc.a is not the
 Alan> problem.  If you built libstdc++.so linked against libgcc_s.so,
 Alan> then when linking using libstdc++.so you need to have
 Alan> libgcc_s.so available, and, importantly, libgcc_s.so must be
 Alan> linked before libgcc.a if both are specified.

 Alan> If you built libstdc++.so only linked against libgcc.a, then
 Alan> you can use libstdc++.so like that too.

Interesting.  objdump says that libstdc++ requires libm, but not
libgcc_s.  And libm doesn't require anything.

	   paul

Re: Unintellegible ld error messages

[Alan Modra]

On Sun, May 15, 2005 at 02:43:32PM -0400, Paul Koning wrote:
> >>>>> "Alan" == Alan Modra <amodra@bigpond.net.au> writes:
>  Alan> _Unwind_GetIP as a hidden symbol in libgcc.a is not the
>  Alan> problem.  If you built libstdc++.so linked against libgcc_s.so,
>  Alan> then when linking using libstdc++.so you need to have
>  Alan> libgcc_s.so available, and, importantly, libgcc_s.so must be
>  Alan> linked before libgcc.a if both are specified.
> 
>  Alan> If you built libstdc++.so only linked against libgcc.a, then
>  Alan> you can use libstdc++.so like that too.
> 
> Interesting.  objdump says that libstdc++ requires libm, but not
> libgcc_s.  And libm doesn't require anything.

Hmm.  Perhaps you have hit a ld bug, but it seems to me that you have
given confliction information.  If "The offending library is libstdc++"
then libstdc++.so contains an unsatisfied reference to _Unwind_GetIP,
which means libstdc++.so ought to refer to libgcc_s.so in a DT_NEEDED
tag.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

Re: Unintellegible ld error messages

[H. J. Lu]

On Fri, May 13, 2005 at 03:44:46PM -0400, Paul Koning wrote:
> The offending library is libstdc++, as compiled by GCC 4.0.0.  This
> seems very strange.
> 

That is your problem. On Linux, there are

[hjl@gnu-10 gcc-next]$ readelf -s /usr/gcc-4.0/lib/libgcc_s.so| grep _Unwind_GetIP
    19: 00004ff0    11 FUNC    GLOBAL DEFAULT   11 _Unwind_GetIP@@GCC_3.0
   214: 00004ff0    11 FUNC    GLOBAL DEFAULT   11 _Unwind_GetIP


H.J.