Peter Eisentraut <peter_e@gmx.net> writes:
> HP-UX hpunix5 B.11.00 U 9000/803 2002765023
> Using the system compiler, I get several complaints about our use of
> "inline", for example:
Interesting. CVS tip works fine for me on HPUX 10.20, using cc -Ae.
It looks like configure deduces inline is not supported on this
compiler, though:
/* Define as `__inline' if that's what the C compiler calls it, or to nothing if it is not supported. */
#define inline
What do you get on that compiler?
> I had to patch it as follows to get it to work:
Odd. I count ten inline functions in the backend:
src/backend/storage/lmgr/lock.c: 94: inline static bool
src/backend/storage/lmgr/lock.c: 105: inline static void
src/backend/storage/lmgr/lock.c: 126: inline static void
src/backend/storage/lmgr/lwlock.c: 67: inline static void
src/backend/storage/lmgr/lwlock.c: 77: inline static void
src/backend/utils/adt/pg_lzcompress.c: 389: static inline int
src/backend/utils/hash/dynahash.c: 465: static inline uint32
src/backend/utils/mmgr/aset.c: 256: static inline int
src/backend/utils/sort/tuplesort.c: 1787: static inline Datum
src/backend/utils/sort/tuplesort.c: 1819: static inline int32
Why would only three of them fail?
I'm not eager to remove the inlining optimization for everyone just
because this one compiler fails. I think a more reasonable approach
would be to force inline to be #define'd as empty on that platform.
Or file a bug report with HP.
regards, tom lane