Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 4 Feb 1997 19:40:51 -0500 (EST)
From:      Chuck Robey <chuckr@glue.umd.edu>
To:        Terry Lambert <terry@lambert.org>
Cc:        jmacd@CS.Berkeley.EDU, hackers@freebsd.org
Subject:   Re: g++, STL and -frepo on FreeBSD-2.2-Beta
Message-ID:  <Pine.OSF.3.95q.970204193602.1349B-100000@baud.eng.umd.edu>
In-Reply-To: <199702050019.RAA13562@phaeton.artisoft.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Feb 1997, Terry Lambert wrote:

> > I'm not sure this is apropos, but maybe... while I was porting
> > octave-2.0.1, I had a lot of trouble with template functions that were
> > compiled -fno-external-templates.  Seems like the virtual tables were
> > being created as local symbols only, so no other functions compiled in
> > other files could see the tables.  I ended up having to remove the
> > -fno-external-templates from every file that used the tables, so they'd
> > instantiate their own virtual tables.  Made the code size larger, but I
> > couldn't find a way to fix it.  Neither could JW Eaton, Octave's author,
> > who worked with me for a while.
> > 
> > The problem has been papered over, but not fixed.  Is this possibly
> > something like you're discussing above?
> 
> I thought so; however, Bakul's recent post has me doubting my own
> sanity.  I have replied to him, siting references, in case the g++
> implementation does things differently.  If it does, I'll be happy
> to admit my error.  If it doesn't, I'll still believe it's "Pilot
> Error" causing the problem.

Terry, I'm not sure you're right.  The virtual tables show up (using nm on
the obj files) as "t" objects, not "T", meaning local text objects.  The
way I understand from JW Eaton, under Linux (where he wrote it natively)
the symbols in the obj files for these virtual tables instatiated for
templates are global, not local.  There is one of these tables made for
each template type, correctly, but they're coming up local.  This seems to
be to point to an error source in the compiler, not the linking process.

FWIW, the symbols make it into the library, but as local symbols, not
global.  Am I confused about this?

> I'm pretty sure that external templates *can't* work as anything
> other than code/class reinstantiations (to avoid static redeclaration,
> like you describe).  I'm also pretty sure the a.out linker can't handle
> agregating multiple instnatiations into a single interface.  ELF
> could, though, because it could establish an identity tag for the
> ELF segment based on the class derivation, and link only the first
> segment with the tag into the resulting executable, throwing all
> the others away.  Whether ELF actually *does* this is another matter,
> since it would mean you effecitevly compile one source file into
> several object files which you place in a single ELF file... then
> link it.

----------------------------+-----------------------------------------------
Chuck Robey                 | Interests include any kind of voice or data 
chuckr@eng.umd.edu          | communications topic, C programming, and Unix.
9120 Edmonston Ct #302      |
Greenbelt, MD 20770         | I run Journey2 and picnic, both FreeBSD
(301) 220-2114              | version 3.0 current -- and great FUN!
----------------------------+-----------------------------------------------




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.OSF.3.95q.970204193602.1349B-100000>