This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: C++ - Why always libm?


> Let me ask this again: Can anyone explain why libm is linked with even the
> simplest C++ program?

It is an accident of history that libm is (sometimes) separate from libc.
ANSI/ISO C and C+ do not mention either, or divide them into separate
libraries.

So if we link libc by default, we need to link libm, to get the standard
math functions.  Anything else provides an inconsistent and non-portable
programmer interface.

Furthermore, if you use share libraries, it makes no practical difference
whether the standard C libray is one shared library or two - they
both need to get linked in.

I guess you could have a linker feature where if you ask to link with
a shared library, but nothing is referenced, then the entire library
is left out.  But that would fail if the user then loaded some new
library that needed the mth functions.  In any case, it would be a
fragile ad hoc solution - conveptually shared libraries are all of
nothing.  And conceptually, libm is part of libc.

> The real
> question stems from the fact that space is at a premium in my environment,

In that case, perhaps you should invoke the linker by hand.  Or at
least use the -nostdlib flag to explicitly select libraries.

Shared libraries were not designed for "embedded applications".

I suggest linking all your programs together as one large statically-linked
appliction.  Use threads if you want multiple "applications".  That is
what embedded systems people normally do.

	--Per Bothner
Cygnus Solutions     bothner@cygnus.com     http://www.cygnus.com/~bothner


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]