This is the mail archive of the gcc-bugs@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: -fno-default-inline and iostream.o



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



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