[EMAIL PROTECTED] wrote: > It's hard to make the example to regenerate the error. > For the small test, it works well both Linux g++ and Mac OS X g++. > > But the real OpenAccess source code which is around 40M of source code > in total. > The Mac OS X g++ code doens't seem like to make the function inlined > whereas Linux g++ always does.
Hmmm, weird. If that really is the case, I'd call it a compiler bug. There are two things left that I'd check: 1. Do you really recompile everything that included said .inl file? No stray object files or convenience libs? 2. I could imagine a broken build system (had that with early autoconf) defining 'inline' to an empty string because it thinks it wasn't supported. Further things you could try: - Don't include the .inl file except in one translation unit. Of course that means that it can't inline the code, which might cost size and performance, but getting it to run is the first priority now. - Instead of separating the class definition from the inline function definitions, you could put the definitions into the class definition. This implicitly makes them inline and every compiler gets this right. - Making a function inline effectively either inlines it (no problem) but generates an out-of-line copy, too. This copy is flagged to the linker as a "weak" symbol, i.e. multiple definitions shouldn't generate an error and it's supposed to merge them (i.e. just take one). I could imagine that you could mess up the linker setting enough to break this system, watch for unusual/unknown linker options. > I hope to find a compiler flag which forces the Mac OS X g++ always > generates the inline. The weird thing is that it shouldn't be necessary... Uli -- http://gcc.gnu.org/faq.html http://parashift.com/c++-faq-lite/ _______________________________________________ help-gplusplus mailing list [email protected] http://lists.gnu.org/mailman/listinfo/help-gplusplus
