[i386] Why g++ _always_ link an executable with libm.so?

[i386] Why g++ _always_ link an executable with libm.so?

[Denis Zaitsev]

I've found some strange behaviour of g++: if it's used to produce an
executable, i.e.:

        g++ xxx.C -o XXX

then that XXX is linked with libm.so, regardless of the fact that math
is not used in the program.  Also, libstdc++.so and libgcc_s.so are
linked too, even though they aren't needed as well.

But if g++ is used to compilation only, and the link stage is done by
gcc or ld, i.e:

        g++ -c xxx.C -o xxx.o
        gcc xxx.o -o XXX

then neither of that 3 libs are linked (of course, if they aren't
needed).

Why g++ does so?  Is it intentional?  Or how this can be solved?

GCC's in question are the current stable, 20041231 snapshot and all
the 3.x.x versions, as far as I remember.

Thanks in advance.

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Daniel Jacobowitz]

On Wed, Jan 05, 2005 at 03:01:02AM +0500, Denis Zaitsev wrote:
> I've found some strange behaviour of g++: if it's used to produce an
> executable, i.e.:
> 
>         g++ xxx.C -o XXX
> 
> then that XXX is linked with libm.so, regardless of the fact that math
> is not used in the program.  Also, libstdc++.so and libgcc_s.so are
> linked too, even though they aren't needed as well.
> 
> But if g++ is used to compilation only, and the link stage is done by
> gcc or ld, i.e:
> 
>         g++ -c xxx.C -o xxx.o
>         gcc xxx.o -o XXX
> 
> then neither of that 3 libs are linked (of course, if they aren't
> needed).
> 
> Why g++ does so?  Is it intentional?  Or how this can be solved?

drow@nevyn:~% readelf -d /usr/lib/libstdc++.so.6 | grep NEEDED
 0x00000001 (NEEDED)                     Shared library: [libm.so.6]
 0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
 0x00000001 (NEEDED)                     Shared library: [libc.so.6]

Libstdc++ needs libm.

-- 
Daniel Jacobowitz

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Denis Zaitsev]

On Tue, Jan 04, 2005 at 05:05:23PM -0500, Daniel Jacobowitz wrote:
> On Wed, Jan 05, 2005 at 03:01:02AM +0500, Denis Zaitsev wrote:
> > I've found some strange behaviour of g++: if it's used to produce an
> > executable, i.e.:
> > 
> >         g++ xxx.C -o XXX
> > 
> > then that XXX is linked with libm.so, regardless of the fact that math
> > is not used in the program.  Also, libstdc++.so and libgcc_s.so are
> > linked too, even though they aren't needed as well.
> > 
> > But if g++ is used to compilation only, and the link stage is done by
> > gcc or ld, i.e:
> > 
> >         g++ -c xxx.C -o xxx.o
> >         gcc xxx.o -o XXX
> > 
> > then neither of that 3 libs are linked (of course, if they aren't
> > needed).
> > 
> > Why g++ does so?  Is it intentional?  Or how this can be solved?
> 
> drow@nevyn:~% readelf -d /usr/lib/libstdc++.so.6 | grep NEEDED
>  0x00000001 (NEEDED)                     Shared library: [libm.so.6]
>  0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
>  0x00000001 (NEEDED)                     Shared library: [libc.so.6]

Thanks.

> Libstdc++ needs libm.

Then the other questions:

  a) why g++ assumes that libstdc++ is always needed?

  b) why is libm _always_ needed by libstdc++?  It's rather strange.

BTW, the same happens with Ada and libgnat - if I compile GCC from
scratch, then libgnat.so NEED libm.  But libgnat from, say, Debian
doesnt do so - it NEED libgcc_s.so only.  Where are some things
messed?

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Gabriel Dos Reis]

Denis Zaitsev <zzz@anda.ru> writes:

| On Tue, Jan 04, 2005 at 05:05:23PM -0500, Daniel Jacobowitz wrote:
| > On Wed, Jan 05, 2005 at 03:01:02AM +0500, Denis Zaitsev wrote:
| > > I've found some strange behaviour of g++: if it's used to produce an
| > > executable, i.e.:
| > > 
| > >         g++ xxx.C -o XXX
| > > 
| > > then that XXX is linked with libm.so, regardless of the fact that math
| > > is not used in the program.  Also, libstdc++.so and libgcc_s.so are
| > > linked too, even though they aren't needed as well.
| > > 
| > > But if g++ is used to compilation only, and the link stage is done by
| > > gcc or ld, i.e:
| > > 
| > >         g++ -c xxx.C -o xxx.o
| > >         gcc xxx.o -o XXX
| > > 
| > > then neither of that 3 libs are linked (of course, if they aren't
| > > needed).
| > > 
| > > Why g++ does so?  Is it intentional?  Or how this can be solved?
| > 
| > drow@nevyn:~% readelf -d /usr/lib/libstdc++.so.6 | grep NEEDED
| >  0x00000001 (NEEDED)                     Shared library: [libm.so.6]
| >  0x00000001 (NEEDED)                     Shared library: [libgcc_s.so.1]
| >  0x00000001 (NEEDED)                     Shared library: [libc.so.6]
| 
| Thanks.
| 
| > Libstdc++ needs libm.
| 
| Then the other questions:
| 
|   a) why g++ assumes that libstdc++ is always needed?

Because that is the way it is designed.  If you don't want libstdc++,
say -nostdlib as explained in our documentation.

|   b) why is libm _always_ needed by libstdc++?

Because libstdc++ needs the mathematical functions.

|  It's rather strange.

I guess it is a matter of perspective.  From my part, requiring users
to explicitly supply -lm is a bug.  Simply because the mathematical
functions are part of the standard library; we do not require users to
say -lstr when they use strcpy() and friend; we do not require users
to say -lstdio when they use fprintf() and friends.  YMMV.

-- Gaby

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Denis Zaitsev]

On Tue, Jan 04, 2005 at 11:30:05PM +0100, Gabriel Dos Reis wrote:
> Denis Zaitsev <zzz@anda.ru> writes:
> | 
> |   a) why g++ assumes that libstdc++ is always needed?
> 
> Because that is the way it is designed.  If you don't want libstdc++,
> say -nostdlib as explained in our documentation.

This doesn't work out of the box...  But yes, it can be a solution,
thanks.

> |   b) why is libm _always_ needed by libstdc++?
> 
> Because libstdc++ needs the mathematical functions.
> 
> |  It's rather strange.
> 
> I guess it is a matter of perspective.  From my part, requiring users
> to explicitly supply -lm is a bug.  Simply because the mathematical
> functions are part of the standard library; we do not require users to
> say -lstr when they use strcpy() and friend; we do not require users
> to say -lstdio when they use fprintf() and friends.  YMMV.

Ok, but do we force users to use libm every time libc is used?  No, we
don't.  Of course, we don't.  And I emphasised the word 'always':
not _every_ routine from libstdc++ need libm, but it always
required...

Anyway, could anybody say, where in sources these NEEDED libraries
come from?  If I was going to patch this just for my installations...

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Andrew Pinski]

On Jan 4, 2005, at 5:59 PM, Denis Zaitsev wrote:

> Ok, but do we force users to use libm every time libc is used?  No, we
> don't.  Of course, we don't.  And I emphasised the word 'always':
> not _every_ routine from libstdc++ need libm, but it always
> required...

Then write a better collect2 which only links in the libraries which
are needed and have it find the needed libraries without supplying
the option to link the library (yes this is on the TODO page of gcc).

Also note on some targets like darwin, libm is included in libsystem 
(aka
libc) by default.


-- Pinski

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Denis Zaitsev]

On Tue, Jan 04, 2005 at 06:06:51PM -0500, Andrew Pinski wrote:
> 
> On Jan 4, 2005, at 5:59 PM, Denis Zaitsev wrote:
> 
> > Ok, but do we force users to use libm every time libc is used?  No, we
> > don't.  Of course, we don't.  And I emphasised the word 'always':
> > not _every_ routine from libstdc++ need libm, but it always
> > required...
> 
> Then write a better collect2 which only links in the libraries which
> are needed and have it find the needed libraries without supplying
> the option to link the library (yes this is on the TODO page of gcc).
> 
> Also note on some targets like darwin, libm is included in libsystem 
> (aka
> libc) by default.

Ok, I'm not trying to criticize the way it implemented for now.  I'm
trying to understand what happens now.

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Gabriel Dos Reis]

Denis Zaitsev <zzz@anda.ru> writes:

| On Tue, Jan 04, 2005 at 11:30:05PM +0100, Gabriel Dos Reis wrote:
| > Denis Zaitsev <zzz@anda.ru> writes:
| > | 
| > |   a) why g++ assumes that libstdc++ is always needed?
| > 
| > Because that is the way it is designed.  If you don't want libstdc++,
| > say -nostdlib as explained in our documentation.
| 
| This doesn't work out of the box...

If -nostdlib does not work as explained in the documentation, then you
might have found a bug.  If you don't explain why it does not work as
explained in the documentation or do not a fill a proper bug report,
the probability that it gets fixed is near to zero.

| But yes, it can be a solution,  thanks.
| 
| > |   b) why is libm _always_ needed by libstdc++?
| > 
| > Because libstdc++ needs the mathematical functions.
| > 
| > |  It's rather strange.
| > 
| > I guess it is a matter of perspective.  From my part, requiring users
| > to explicitly supply -lm is a bug.  Simply because the mathematical
| > functions are part of the standard library; we do not require users to
| > say -lstr when they use strcpy() and friend; we do not require users
| > to say -lstdio when they use fprintf() and friends.  YMMV.
| 
| Ok, but do we force users to use libm every time libc is used?

What is libc?  How do you define it?

|  No, we
| don't.  Of course, we don't.  And I emphasised the word 'always':
| not _every_ routine from libstdc++ need libm, but it always
| required...

The C++ standard library is a whole entity (minus the "freestanding"
part) that is hard to split in meaningfully independent parts.
Personnaly, I have zilk interest in splitting it into zillions
arbitrary parts (or maintain such splits) and require users to supply
zillions -lxxx switches. 

As a C++ user, when I say

   copy(istream_iterator<int>(cin), istream_iterator<int>(),
        back_insert(v));

I have no idea of which of those zillions parts are involved
underneath, I do not want to know, and a fortiori I do not want to
be required to supply a cabalistic combination of switches to get it
work. The compiler is better at that than I.

-- Gaby

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Gabriel Dos Reis]

Andrew Pinski <pinskia@physics.uc.edu> writes:

| Also note on some targets like darwin, libm is included in libsystem
| (aka
| libc) by default.

Indeed.  I've always found it an extraordinary definition of libc that
leaves out the mathematical functions, as if cos() or sin() or atan()
were not part of the C standard library.

-- Gaby

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Mike Hearn]

On Tue, 04 Jan 2005 18:06:51 -0500, Andrew Pinski wrote:
> Then write a better collect2 which only links in the libraries which
> are needed and have it find the needed libraries without supplying
> the option to link the library (yes this is on the TODO page of gcc).

I thought there was already an option for this in ld, --as-needed or
something.

I also find it strange (broken) that a c++ app that doesn't use any libm
symbols is linked to it anyway. Why does it matter? If stdc++ needs it
then fine, but the link tree should look like:

a.out
  - libc.so.6
  - libstdc++.so.6
       - libm.so.6
       - libc.so.6

and so on. Why does the link tree not look how you'd intuitively expect it
to?

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Andrew Pinski]

On Jan 5, 2005, at 12:14 PM, Mike Hearn wrote:

> On Tue, 04 Jan 2005 18:06:51 -0500, Andrew Pinski wrote:
>> Then write a better collect2 which only links in the libraries which
>> are needed and have it find the needed libraries without supplying
>> the option to link the library (yes this is on the TODO page of gcc).
>
> I thought there was already an option for this in ld, --as-needed or
> something.

Well then make binutils change over --as-needed to be default.


> I also find it strange (broken) that a c++ app that doesn't use any 
> libm
> symbols is linked to it anyway. Why does it matter?

because libstdc++ might pull in libm symbols without the person knowing
he did.

-- Pinski

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Andrew Pinski]

On Jan 5, 2005, at 1:51 PM, Mike Hearn wrote:

> On Wed, 2005-01-05 at 13:21 -0500, Andrew Pinski wrote:
>> Well then make binutils change over --as-needed to be default.
>
> Tried, it doesn't work, there are too many broken libraries in the 
> world
> that don't correctly enumerate their dependencies in the NEEDED 
> section.
> Instead they rely on the user of the library to complete the set when
> they use it :(

Again why are you complaining when a good dynamic loader will not load
the needed libraries unless they are really needed?

-- Pinski

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Mike Hearn]

On Wed, 2005-01-05 at 13:21 -0500, Andrew Pinski wrote:
> Well then make binutils change over --as-needed to be default.

Tried, it doesn't work, there are too many broken libraries in the world
that don't correctly enumerate their dependencies in the NEEDED section.
Instead they rely on the user of the library to complete the set when
they use it :(

thanks -mike

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Mike Hearn]

On Wed, 2005-01-05 at 13:48 -0500, Andrew Pinski wrote:
> Again why are you complaining when a good dynamic loader will not load
> the needed libraries unless they are really needed?

You can't do that for ELF, you have no idea what libraries symbols are
meant to come from. The NEEDED entries in a binary are how the loader
knows what's needed and what's not, as the name implies. There's no way
to strip these entries once the binary has been built (except taking
them away one at a time and seeing if anything breaks ...) so it's
better if the compiler/linker does it.

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Denis Zaitsev]

On Wed, Jan 05, 2005 at 01:21:23PM -0500, Andrew Pinski wrote:
> 
> On Jan 5, 2005, at 12:14 PM, Mike Hearn wrote:
> 
> > I also find it strange (broken) that a c++ app that doesn't use any 
> > libm
> > symbols is linked to it anyway. Why does it matter?
> 
> because libstdc++ might pull in libm symbols without the person knowing
> he did.

Ok.  But the question in general is not about that.  It is not a
problem that libm is NEEDED by libstdc++, but why this NEEDED leads to
the same NEEDED for the app?  Isn't the first depndency enough?

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Andrew Pinski]

On Jan 5, 2005, at 5:09 PM, Denis Zaitsev wrote:

> On Wed, Jan 05, 2005 at 01:21:23PM -0500, Andrew Pinski wrote:
>>
>> On Jan 5, 2005, at 12:14 PM, Mike Hearn wrote:
>>
>>> I also find it strange (broken) that a c++ app that doesn't use any
>>> libm
>>> symbols is linked to it anyway. Why does it matter?
>>
>> because libstdc++ might pull in libm symbols without the person 
>> knowing
>> he did.
>
> Ok.  But the question in general is not about that.  It is not a
> problem that libm is NEEDED by libstdc++, but why this NEEDED leads to
> the same NEEDED for the app?  Isn't the first depndency enough?

No, because some of libstdc++ code is in the headers, on some targets
have two level namespaces which causes this to be rejected.

-- Pinski

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Denis Zaitsev]

On Wed, Jan 05, 2005 at 01:38:34AM +0100, Gabriel Dos Reis wrote:
> Denis Zaitsev <zzz@anda.ru> writes:
> 
> | On Tue, Jan 04, 2005 at 11:30:05PM +0100, Gabriel Dos Reis wrote:
> | > Denis Zaitsev <zzz@anda.ru> writes:
> | > | 
> | > |   a) why g++ assumes that libstdc++ is always needed?
> | > 
> | > Because that is the way it is designed.  If you don't want libstdc++,
> | > say -nostdlib as explained in our documentation.
> | 
> | This doesn't work out of the box...
> 
> If -nostdlib does not work as explained in the documentation, then you
> might have found a bug.  If you don't explain why it does not work as
> explained in the documentation or do not a fill a proper bug report,
> the probability that it gets fixed is near to zero.

It is not explained in the doc. in a much details.  So I don't know
either it is error or what.  In short, -nostdlib leads to the 'no std
objects' as well, and, as I understand, I must link them explicitly.
Or what does this mean:

/usr/bin/ld: warning: cannot find entry symbol _start; defaulting to 08048094

?

> | Ok, but do we force users to use libm every time libc is used?
> 
> What is libc?  How do you define it?

I assume GLIBC, of course.  For x86, but I don't know either this
matters.

> |  No, we
> | don't.  Of course, we don't.  And I emphasised the word 'always':
> | not _every_ routine from libstdc++ need libm, but it always
> | required...
> 
> The C++ standard library is a whole entity (minus the "freestanding"
> part) that is hard to split in meaningfully independent parts.
> Personnaly, I have zilk interest in splitting it into zillions
> arbitrary parts (or maintain such splits) and require users to supply
> zillions -lxxx switches. 
> 
> As a C++ user, when I say
> 
>    copy(istream_iterator<int>(cin), istream_iterator<int>(),
>         back_insert(v));
> 
> I have no idea of which of those zillions parts are involved
> underneath, I do not want to know, and a fortiori I do not want to
> be required to supply a cabalistic combination of switches to get it
> work. The compiler is better at that than I.

No, no, no...  The initial question has been asked having this in
mind: why the dependencies are used per-shared-object vs. per-module-inside-it?
As I understand now, it's impossible to have that per-module deps for
elf shared objects.  Ok, it's no a question more.

But then another question: if libstdc++ itself has libm in its NEEDED
list, why the whole app having libstdc++ in its NEEDED list is forced
(by the linker?) to have libm there too?  While the app itself never
really needs that libm?

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Denis Zaitsev]

On Wed, Jan 05, 2005 at 05:16:20PM -0500, Andrew Pinski wrote:
> 
> On Jan 5, 2005, at 5:09 PM, Denis Zaitsev wrote:
> 
> > Ok.  But the question in general is not about that.  It is not a
> > problem that libm is NEEDED by libstdc++, but why this NEEDED leads to
> > the same NEEDED for the app?  Isn't the first depndency enough?
> 
> No, because some of libstdc++ code is in the headers, on some targets
> have two level namespaces which causes this to be rejected.

Sorry, what to be rejected?

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Andrew Pinski]

On Jan 5, 2005, at 5:25 PM, Denis Zaitsev wrote:
> But then another question: if libstdc++ itself has libm in its NEEDED
> list, why the whole app having libstdc++ in its NEEDED list is forced
> (by the linker?) to have libm there too?  While the app itself never
> really needs that libm?

Because that is not the way it should work.  If it works that way it is
just plainly wrong really.  All libraries which are needed by a shared
library should be listed, otherwise you get undefined behavior on
when libraries get initialized.  This has been discussed before,
go look it up.

-- Pinski

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Andrew Pinski]

On Jan 5, 2005, at 5:30 PM, Denis Zaitsev wrote:

> On Wed, Jan 05, 2005 at 05:16:20PM -0500, Andrew Pinski wrote:
>>
>> On Jan 5, 2005, at 5:09 PM, Denis Zaitsev wrote:
>>
>>> Ok.  But the question in general is not about that.  It is not a
>>> problem that libm is NEEDED by libstdc++, but why this NEEDED leads 
>>> to
>>> the same NEEDED for the app?  Isn't the first depndency enough?
>>
>> No, because some of libstdc++ code is in the headers, on some targets
>> have two level namespaces which causes this to be rejected.
>
> Sorry, what to be rejected?

Aka you get link errors.

-- Pinski

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Gabriel Dos Reis]

Denis Zaitsev <zzz@anda.ru> writes:

| On Wed, Jan 05, 2005 at 01:21:23PM -0500, Andrew Pinski wrote:
| > 
| > On Jan 5, 2005, at 12:14 PM, Mike Hearn wrote:
| > 
| > > I also find it strange (broken) that a c++ app that doesn't use any 
| > > libm
| > > symbols is linked to it anyway. Why does it matter?
| > 
| > because libstdc++ might pull in libm symbols without the person knowing
| > he did.
| 
| Ok.  But the question in general is not about that.  It is not a
| problem that libm is NEEDED by libstdc++, but why this NEEDED leads to
| the same NEEDED for the app?  Isn't the first depndency enough?

At this point I completely lose track of what your problem is and what
you're complaining about.

-- Gaby

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Gabriel Dos Reis]

Denis Zaitsev <zzz@anda.ru> writes:

| > | Ok, but do we force users to use libm every time libc is used?
| > 
| > What is libc?  How do you define it?
| 
| I assume GLIBC, of course.  For x86, but I don't know either this
| matters.

That is a very narrow definition; however, are you claiming that the
mathematical functions are not part of GLIBC?

-- Gaby

Re: [i386] Why g++ _always_ link an executable with libm.so?

[Denis Zaitsev]

On Wed, Jan 05, 2005 at 11:44:33PM +0100, Gabriel Dos Reis wrote:
> Denis Zaitsev <zzz@anda.ru> writes:
> 
> | > | Ok, but do we force users to use libm every time libc is used?
> | > 
> | > What is libc?  How do you define it?
> | 
> | I assume GLIBC, of course.  For x86, but I don't know either this
> | matters.
> 
> That is a very narrow definition; however, are you claiming that the
> mathematical functions are not part of GLIBC?

Of course no, I'm not.