From owner-freebsd-hackers Tue Feb 4 16:41:32 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id QAA29381 for hackers-outgoing; Tue, 4 Feb 1997 16:41:32 -0800 (PST) Received: from po2.glue.umd.edu (root@po2.glue.umd.edu [129.2.128.45]) by freefall.freebsd.org (8.8.5/8.8.5) with ESMTP id QAA29370 for ; Tue, 4 Feb 1997 16:41:27 -0800 (PST) Received: from baud.eng.umd.edu (baud.eng.umd.edu [129.2.98.183]) by po2.glue.umd.edu (8.8.5/8.7.3) with ESMTP id TAA07225; Tue, 4 Feb 1997 19:40:52 -0500 (EST) Received: from localhost (chuckr@localhost) by baud.eng.umd.edu (8.8.5/8.7.3) with SMTP id TAA00927; Tue, 4 Feb 1997 19:40:51 -0500 (EST) X-Authentication-Warning: baud.eng.umd.edu: chuckr owned process doing -bs Date: Tue, 4 Feb 1997 19:40:51 -0500 (EST) From: Chuck Robey X-Sender: chuckr@baud.eng.umd.edu To: Terry Lambert cc: jmacd@CS.Berkeley.EDU, hackers@freebsd.org Subject: Re: g++, STL and -frepo on FreeBSD-2.2-Beta In-Reply-To: <199702050019.RAA13562@phaeton.artisoft.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk 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! ----------------------------+-----------------------------------------------