Date: Tue, 4 Feb 1997 21:28:48 -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.970204211959.1889B-100000@baud.eng.umd.edu> In-Reply-To: <199702050134.SAA13752@phaeton.artisoft.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 4 Feb 1997, Terry Lambert wrote: > > 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? > > Well... you are, or I am. 8-). > > Riddle me this: if the compiler makes a 't' reference to a real 'T' > somewhere... how can it generate the real 'T'? It can't just pick > one of the files at random an put it there. I might be compiling > incrementally. [large code example elided] > > ...do you expect the code to implement the Insert method for a FifoQueue > of int to go into foo.o or fee.o? In the interests of keeping this to some reasonable legnth, I took a lot out, but the comments are valid. One point, tho -- this seems to work correctly under Linux/ELF. This is the first time I really wish I had access to a Linux machine to check the visibility of the virtual tables. The code pieces do seem to be made global under FreeBSD, it's just the virtual tables that are local, and so invisible to other modules. You said you don't think ELF DTRT, altho it could. Maybe it is? My workaround is to have the virtual tables instantiated everywhere, and it works, but I wish it worked the way it's supposed to, with just one copy of the code (and virtual tables, which are the real bogie here, I think). The object modules corresponding to your fee.C example are there, but the virtual tables in fee.o are local. > > Here's what I expect: > > a.out: > --------- [a.out explanation elided] > > ELF: > --------- [ELF explanation elided] > > If I'm wrong (the declaration didn't need to be in scope), then > it's probably that they are incorrectly applying the "don't generate > template" flag when they shouldn't be, not creating a template > instance object seperate from the rest of their objects, like they > should be, or relying on linker tricks which require multiple > instantiations to be coalesced to a single instance, which the a.out > linker is too stupid to do, and the ELF linker is probably currently > too stupid to do, even though ELF could support it. > > Feel free to correct me, though... I'd rather know the right answer > than just think I knew the right answer. If there's another way for > me to be wrong, let me know. > > > Regards, > Terry Lambert > terry@lambert.org > --- > Any opinions in this posting are my own and not those of my present > or previous employers. > ----------------------------+----------------------------------------------- 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.970204211959.1889B-100000>