Port of C from Win to OSX

[ch...@truememories.com]

I'm porting a large application from Windows to OSX. I'm trying to
minimize changes to my clients codebase. One area that is giving me
problems is inline functions. All over the place the client has
functions in header files marked as inline (this is a
performance-critical app). These header files get included by multiple
.C files. When building with gcc on OSX - what ends up happening is
that the compiler puts a copy of each inlined function in each .o file,
then when I goto link I get linker errors because of multiple
definitions of the same symbol.

Anybody have any thoughts on how to resolve this?

Thanks,
-Chris

--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]

[Greg Herlihy]

On 10/6/06 3:02 PM, in article
1160167459.2...@i42g2000cwa.googlegroups.com,
"ch...@truememories.com" <ch...@truememories.com> wrote:

> I'm porting a large application from Windows to OSX. I'm trying to
> minimize changes to my clients codebase. One area that is giving me
> problems is inline functions. All over the place the client has
> functions in header files marked as inline (this is a
> performance-critical app). These header files get included by multiple
> .C files. When building with gcc on OSX - what ends up happening is
> that the compiler puts a copy of each inlined function in each .o file,
> then when I goto link I get linker errors because of multiple
> definitions of the same symbol.
>
> Anybody have any thoughts on how to resolve this?

The most likely explanation for your problem is that the "inline" functions
are not actually being declared inline. What do these function declarations
look like? Are they using an INLINE macro, or possibly an implementation
defined __inline__ directive? (Note that it almost always a good idea to
include an excerpt of a source or header file that is causing the problem
when posting to a C++ newsgroup).

Another possibility is that some of the header files are being included more
than once. Does the program use header guards, #pragma once, or some other
mechanism to prevent the same header file being included multiple times for
one translation unit? Lastly, what are the compiler options in force when
the code is compiled on OS X? Do any affect the compiler's function inlining
behavior?

Even though the above suggestions are pure guesswork on my part (once again,
please inlcude source) one point is still quite clear: it's perfectly fine
for a C++ program to include an inline function in multiple source files, so
there must be another explanation for the linker errors.

Greg

[Victor Bazarov]

ch...@truememories.com wrote:
> I'm porting a large application from Windows to OSX. I'm trying to
> minimize changes to my clients codebase. One area that is giving me
> problems is inline functions. All over the place the client has
> functions in header files marked as inline (this is a
> performance-critical app). These header files get included by multiple
> .C files. When building with gcc on OSX - what ends up happening is
> that the compiler puts a copy of each inlined function in each .o
> file, then when I goto link I get linker errors because of multiple
> definitions of the same symbol.
>
> Anybody have any thoughts on how to resolve this?

I can only say, get a better compiler. If the function is declared
'inline' the fact that there are several definitions of it in more
than one translation unit shouldn't violate the ODR. Apparently
your linker is incapable of following the requirements of 7.1.2 and
3.2.

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask

[Terry G]

> Regarding "inlines" in headers causing C linker errors.

You could replace "inline" with "static inline".
You'll still get a copy in each module, but it should link.

terry

[ch...@truememories.com]

FYI ... found a short-term solution ... and some interesting things
regarding GCC 4 on MacOSX ...

1) No inlining at all happens unless optimization is enabled -
regardless of the always_inline attribute.
2) By default - an inlined function will also have a regular
non-inlined copy in the object file.

So - the short-term answer is to redefine __INLINE as "extern inline
__attribute((always_inline))" and to build with optimizations enabled.
Ultimately, however, I will likely need to change the prorotypes and
function definitions to be static - so they work whether or not they
are inlined.

[ch...@truememories.com]

Yes, I tried that. Unfortunately, because the prototypes in the files
do not also contain the static modifier, the compiler then err's out
telling me that the prototype doesn't match the definition. I know that
the answer is then, "change the prototypes", - but again - I'm trying
to get this stuff to compile as much as possible without modifiying the
source - 'cause there are HUNDREDS of files - and all of it builds
without errors or warnings under VS6.

-Chris