Date: Wed, 5 Feb 1997 15:29:25 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: bakul@torrentnet.com (Bakul Shah) Cc: terry@lambert.org, chat@freebsd.org Subject: Re: g++, STL and -frepo on FreeBSD-2.2-Beta Message-ID: <199702052229.PAA15792@phaeton.artisoft.com> In-Reply-To: <199702051922.OAA12987@chai.plexuscom.com> from "Bakul Shah" at Feb 5, 97 02:22:40 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > Urg. As always, if it can be proven to my satisfaction that I have > > actually made a mistake, I will post a retraction; now you have me > > wondering, since you are generally reliable as a sanity-check... 8-(. > > > > Are you saying that there is a condition in which the linker > > will not be able to find a symbol that is really there? I was > > under the impression that if the template declaration was in > > scope, the function implementation would be instanced in scope: > > The `scope' of a named object is the *program text* where the object > name is visible. This is strictly a compile time property for block > structured languages like C++. If there was a scoping error the > compiler would have complained, not the linker. If the linker can > not find a symbol, either the compiler did not give it the right > information or the linker is buggy. But either way, error is in > `linking' not in `scoping'. OK. I was wrong. But assuming the patches work, then it's still got to be pilot error. Either they work, and the linker isn't involved, so they are being invoked improperly, OR they work, and the linker is involved, and assumptions which are not true are being made of the linker, OR they don't work, they are being used, and using non-working code is also pilot error. Since they work on ELF and not on a.out, it make sense that the problem is probably in the linker, but I guess it's possible to contrive a case where it isn't. > The rest of your message indicates that you are using `scope' in a > way I am unfamiliar with (and your use is not standard. See for > example the `dragon' book on compilers). Symbol scope vs. lexical scope. Sorry. > In a statically typed language there is no *need* to construct types > at runtime. Hence there is no need to invoke a type function at > runtime. Also note that you can do the same for certain normal > functions provided the compiler can deduce the value of the function > will be the same at runtime. I guess this is where the confusion is. Is g++ without frepo statically typed, but with frepo, not statically typed? > Just to use template instantiations you don't need the linker's > cooperation. If a source file uses functions defined on a bunch of > instantiated templates, the compiler can generate the necessary code > for these functions along with the code for the source file. No > external references are generated for any of the template instance > functions. Yes. This is the only way that works for a.out, so far as I know. > But this can cause code bloat. If N files reference the same > function of the same template instance, there will be N copies of > this function. To deal with that problem the compiler has to > a) not generate code but generate an external reference for > any use of a template instance function and > b) somehow separately compile these functions for each template > instance. > > Then the linker can link everyone together and there is exactly one > copy of every function that was used (and may be the ones that were > not used). But you *still* don't need any linker help. > > Without the -frepo patch step b) requires the user to manually > generate separate files with define the template instances and > compile them with a different flag to the compiler (since in this > case you do want to generate code). Or (c), it requires the linker to agregate segments with identical tags into a single segment instance. Borland does this; it requires that your object file format support multiple segments. You seem to be saying that the frepo patches don't work, or because they are known to work with ELF, that the frepo patches don't work with the a.out code back end and/or linker. So, again, I was wrong about the location of the pilot error, but not about its existance. I guess this is a case where I heard hoof-beats and thought "horses!" and I should have thought "zebras!". 8-) 8-). > Thanks for your offer but I suspect the bug is in the simulator. > That is where I am going to look first when I have enough free time > to track this down. Hmmm... have you tried running the make under gnumake? It may be that there is a step not being invoked... > If you or anyone else is interested, this is vbs-1.3.tgz -- I think > ftp://sunsite.unc.edu/pub/Linux/apps/circuits/ is where it is at. I will grab this when I have a chance; thanks for the pointer. Thanks for the correction, too; it's always better to know what is going on than to think you know what is going on. ;-). 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?199702052229.PAA15792>