Hi Bruno,
Your patch looks like a random hack around an unknown problem.
I'd suggest more investigations.
Errr, that sounds harsh!
But you are right, I do need more investigation.
However I can not reproduce a problem which cc on HP-UX 11.
hpux 11.00 with ansi c A.11.01.25171.GP has this build failure.
hpux 11.11 with ansi c B.11.11.28706 GP works okay.
Try this code with gcc -std:
% cat static-inline.c
static inline int add (int a, int b)
{
return a + b;
}
% gcc --version
gcc (GCC) 3.3.2
...
% gcc -v -std=iso9899:1990 static-inline.c
static-inline.c:1: error: syntax error before "int"
% gcc -v -std=iso9899:199409 static-inline.c
static-inline.c:1: error: syntax error before "int"
% gcc -v -std=iso9899:1999 static-inline.c
%
Now, if you don't trust gcc -std, you or I can go to the gcc@ mailing
list or comp.std.c and ask some real language lawyers. However I hope
that the above test makes you question whether 'static inline' is an
ISO C standard feature, for some versions of the ISO C standard.
Maybe the 'inline' keyword is not defined correctly in config.h?
The config.h file on HP-UX 11 with cc should contain the line
#define inline
In gettext 0.13, gettext-runtime/configure, the conftest.c program for
'inline' looks like this:
# Generated by GNU Autoconf 2.58.
#ifndef __cplusplus
typedef int foo_t;
static $ac_kw foo_t static_foo () {return 0; }
$ac_kw foo_t foo() { return 0; }
#endif
But in the intl/ directory of gcc HEAD and gdb 6.0 and gdb HEAD,
configure looks like this:
# Generated automatically using autoconf version 2.12.1
#include "confdefs.h"
int main() {
} $ac_kw foo() {
; return 0; }
The difference comes from the version of autoconf that is used to
generate 'configure'.
So with the version of intl/ in gcc HEAD and gdb 6.0 and gdb HEAD,
the "inline" test does not test whether "static inline" works.
So it looks like gettext 0.13 should be fine. In fact, I should
check gettext-0.13 on hpux 11.00 before reporting a problem.
I apologize for not doing that. I am doing it now ...
Is something wrong with nls_uint32? This type should be defined
in gmo.h. Is it not?
nls_uint32 is working fine.
Is the user attempting to use a global configure cache?
I'm not sure what you mean by "global configure cache".
However, ac_cv_c_inline is tested and cached in many subdirectories of the
projects that use intl/. In gdb 6.0, ac_cv_c_inline is tested in:
libiberty bfd intl opcodes gdb
And in gdb 6.0, libiberty/configure was built with autoconf 2.13,
which looks like:
#include "confdefs.h"
int main() {
} $ac_kw foo() {
; return 0; }
However, gcc HEAD and gdb HEAD have updated libiberty/configure
so that it's generated with autoconf 2.57, with the new test for
ac_cv_c_inline:
#ifndef __cplusplus
typedef int foo_t;
static $ac_kw foo_t static_foo () {return 0; }
$ac_kw foo_t foo () {return 0; }
#endif
So the problem ought to go away with gdb HEAD, which has a libiberty
with the new ac_cv_c_inline test in it. I am relying on the fact that
libiberty is configured first, which might not be true in
multi-processor build.
I will pursue that.
By the way, the gdb-6.0 intl/ directory is hopelessly outdated:
it's from gettext 0.10.35 and uses a macro named CY_GNU_GETTEXT.
Ouch.
gdb is supposed to pull intl/ from gcc. gcc HEAD has an intl/
from gettext 0.12.1. So I will chase the gdb people to update
their intl/.
That should not have any effect on this problem but we don't want to
have an intl/ from 1998.
So I will:
. try gettext 0.13 on this really slow hpux 11.00 machine that I have,
and let you know what happens.
It was sloppy of me to jump upstream from a problem in gdb/intl to
gettext without actually trying the last released version of gettext.
Sorry about that!
. try gdb HEAD on hpux 11.00 as well.
. file a PR against gdb to upgrade their intl/ from the upstream copy
in the gcc repository.
Thanks,
Michael C