This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: More .so hell
- From: Dan Kegel <dank at kegel dot com>
- To: "securehell at hushmail dot com" <securehell at hushmail dot com>
- Cc: binutils at sourceware dot org
- Date: Thu, 9 Feb 2006 17:33:34 -0800
- Subject: Re: More .so hell
- References: <200602092231.k19MV7Oa050190@mailserver2.hushmail.com>
On 2/9/06, securehell@hushmail.com <securehell@hushmail.com> wrote:
> This might be more appropriate for a GCC list
Yes, it would.
> I have a header file that includes the code for a funcion and is
> declared __forceinline on a different (Windows) platform. I am
> trying to get it to build on Linux and have tried __forceinline,
> __inline__, inline, and __attribute__((always_inline)) but gcc
> 3.4.4 doesn't seem to compile it as the header is called several
> times by various .c files.
http://lkml.org/lkml/2006/1/6/84 suggests
#define __always_inline inline __attribute__((always_inline))
> For example: __attribute__(allways_inline)) gave me this:
> file.h:64: sorry, unimplemented: inlining failed in call to
> 'your_function': function not inlinable
That might make sense if you had the __attribute__((always_inline))
but forgot to also say inline.
See also
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14950
which says a similar problem (perhaps the same one)
is fixed in gcc-4.0 but won't be fixed in 3.4.
If that doesn't help enough, please post a minimal test
case.
There are quite a few other bugzilla entries about
inlining that make good reading, too.
- Dan
--
Wine for Windows ISVs: http://kegel.com/wine/isv