This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: -fno-default-inline and iostream.o
- To: colin at field dot medicine dot adelaide dot edu dot au
- Subject: Re: -fno-default-inline and iostream.o
- From: Jason Gunthorpe <jgg at gpu dot srv dot ualberta dot ca>
- Date: Sun, 2 Nov 1997 19:54:08 -0700 (MST)
- cc: egcs-bugs at cygnus dot com
On Mon, 3 Nov 1997 colin@field.medicine.adelaide.edu.au wrote:
> With -fno-default-inline, iostream.h's
>
> class _IO_ostream_withassign::_IO_ostream_withassign& operator=
> (_IO_ostream_withassign& rhs)
> { return operator= (static_cast<ostream&> (rhs)); }
>
>
> is instantiated twice, once in the caller, and once in libstdc++.a(iostream.o),
> leading to multiple definitions at link-time.
>
> The same occurs for several other methods.
Hm, this sounds slightly related to my post a bit back titled 'Base of a
Class' (http://www.cygnus.com/ml/egcs-bugs/1997-Oct/0179.html).
It seems to me, any C++ compiler should support a concept like 'Base of a
Class' to work properly and efficiantly. In your problem I would want the
compiler to emit the (now non-inline) member functions in the base of the
class compilation unit, not every unit the function is called from.
I did some more poking around and I found the linker does some annoying
things with inline (when inlining is disabled). I get a number of
duplicate symbols between the shared libraries and the client programs,
the thing still links and runs but it is undesireable to have inline
functions, vtables, rtti data, etc included in the client binary when they
are also present in the shared library.
Could someone who actually knows something about gcc comment on this
problem?
Thanks,
Jason