Date: Tue, 4 Feb 1997 17:19:09 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: chuckr@glue.umd.edu (Chuck Robey) Cc: terry@lambert.org, jmacd@CS.Berkeley.EDU, hackers@freebsd.org Subject: Re: g++, STL and -frepo on FreeBSD-2.2-Beta Message-ID: <199702050019.RAA13562@phaeton.artisoft.com> In-Reply-To: <Pine.OSF.3.95q.970204182559.1349A-100000@baud.eng.umd.edu> from "Chuck Robey" at Feb 4, 97 06:30:21 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> 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. 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. The problem being discussed *seems* to me to be a case of where they want only a single code instance for all template member functions, regardless of the derived type. In theory you can do this using an RTTI implementation, but I'll be damned if anyone has built such a thing yet (they'ed need the RTTI first, for starters). Also, for certain, this would require some method of identifier definition agregation, which I'm not sure it's even possible to do without segment attribution. Maybe you could discard duplicate symbols, but I'm pretty sure the a.out linker is too stupid to be able to discard *pieces* of object modules, since the addresses are relative, and I don't believe the .o files build a proper internal symbol dependency graph. The short version is "you can't get there from here". 8-(. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199702050019.RAA13562>