[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [dmidecode] Dmidecode 2.6 to be released soon
From: |
Petter Reinholdtsen |
Subject: |
Re: [dmidecode] Dmidecode 2.6 to be released soon |
Date: |
Sat, 19 Feb 2005 10:23:58 +0100 |
User-agent: |
Mutt/1.4.1i |
[Jean Delvare]
> Ah, OK. That's odd. I've always seen it in the "static inline" order
> (the linux kernel source is full of it, for example). Even the gcc
> manual mentions them in that order at times [1].
It is odd, and wrong. I was mistaken. The error occur when compiling
with -ansi, and I didn't notice that the -ansi flag was removed
between compiles. Using __inline instead of inline, fixes the
problem.
> I am also really curious as to why only you hit that problem. Are
> you using a special compiler, or additional compilation flags? Or
> does it happen on an exotic architecture?
I suspect it was my use of -ansi -pedantic.
The autoconf macro AC_C_INLINE try to detect if inline or __inline
should be used, and defines inline to __inline when needed. Perhaps
you should do something similar? The problem is that 'inline' in fact
isn't ANSI C.
> > But 'inline' is just a compiler hint, and will be ignored if the
> > compiler find it useful.
>
> I assume "doesn't find it (the inline hint) useful" here.
Yes, a typo.
> If simply reverting the keywords order does the trick, I'll go with
> this.
I was mistaken. Swapping the keywords do not solve the problem.
Using __inline does.
Re: [dmidecode] Dmidecode 2.6 to be released soon, Petter Reinholdtsen, 2005/02/26