Mike Harrold <[EMAIL PROTECTED]> writes: >>What is "this unit" ? > A file contain a class.
A file can not "contain a class". You are not explaining yourself very well; you probably mean the file that contains implementations of non-inlined X::* functions. > I should have added that everything is compiled with the > -fno-default-inline switch to prevent functions being > inlined. Yes, you should have. However, even if that flag is used, my copy of gcc-4.1.1 emits code for X::foo() into the *using* module, provided X::foo()'s body is present (as it should be). Therefore, you likely are *still* not telling the whole story. > I want a switch that forces the emission of code for all static > functions in a class. (I've subsequently found that this isn't limited > to static functions. There *is* a switch that forces emission of code for all inline functions, and you already know about it. > The compiler isn't emitting member functions either.) That's right: there is no point in emitting code for unused inline (static or member) functions -- that code could and will be emitted when the function is used (in the other unit). Both gcc-3.3 and 4.1.1 exhibit the same behavior here, so I suspect you are just barking up the wrong tree. > What I really want is to know what changed with regard to > code emission. I have looked through the docs, and can't find anything. Something definitely changed, but not this (AFAICT). >>Finally, when I compile your test on Linux with gcc-3.3.3, >>I do not get a definition of X::foo(), and I bet your gcc-3.4 >>doesn't emit it either (for that test case). IOW, you are not telling >>the whole story, and omitting some very relevant parts. > > Not at all You already admitted earlier that you didn't tell the whole story. > my program compiles _and links_ fine on gcc-3.2 and > gcc-3.4. It will not link with gcc-4.1 with several thousand > "undefined reference" errors... Oh, I believe that. But the test case you provided compiles the same with gcc-3.3 and 4.1.1 (at least for me); and therefore does *not* demonstrate the problem you are having. Now the interesting question is: what happens with that case for your versions. If it compiles differently, then it is likely that *exact* versions of gcc matter. More likely, the test case compiles the same for you as well; in which case the test case is just not relevant -- something *else* (that you didn't tell us about) matters. Cheers, -- In order to understand recursion you must first understand recursion. Remove /-nsp/ for email. _______________________________________________ help-gplusplus mailing list help-gplusplus@gnu.org http://lists.gnu.org/mailman/listinfo/help-gplusplus
