emu buildfarm failure
Buildfarm member emu is failing in some branches with
checking libintl.h usability... yes
checking libintl.h presence... no
configure: WARNING: libintl.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: libintl.h: proceeding with the preprocessor's result
checking for libintl.h... no
configure: error: header file <libintl.h> is required for NLS
I think this is probably because of
'config_env' => {
'CFLAGS' => '-I/usr/local/include',
'CC' => 'gcc',
'LDFLAGS' => '-L/usr/local/lib/ -lcrypto -liconv'
},
The config.log trace suggests that libintl.h is installed in
/usr/local/include, because the "working" tests succeed when they have
"-I/usr/local/include" while the "failing" tests don't have that.
-I switches should logically go in CPPFLAGS not CFLAGS. I'm not sure
this explains emu's failure to build 7.4 and 8.0, because I don't know
why 8.1 and HEAD wouldn't fail the same way ... but it looks wrong
anyway.
regards, tom lane
Tom Lane wrote:
Buildfarm member emu is failing in some branches with
checking libintl.h usability... yes
checking libintl.h presence... no
configure: WARNING: libintl.h: accepted by the compiler, rejected by the preprocessor!
configure: WARNING: libintl.h: proceeding with the preprocessor's result
checking for libintl.h... no
configure: error: header file <libintl.h> is required for NLSI think this is probably because of
'config_env' => {
'CFLAGS' => '-I/usr/local/include',
'CC' => 'gcc',
'LDFLAGS' => '-L/usr/local/lib/ -lcrypto -liconv'
},The config.log trace suggests that libintl.h is installed in
/usr/local/include, because the "working" tests succeed when they have
"-I/usr/local/include" while the "failing" tests don't have that.-I switches should logically go in CPPFLAGS not CFLAGS. I'm not sure
this explains emu's failure to build 7.4 and 8.0, because I don't know
why 8.1 and HEAD wouldn't fail the same way ... but it looks wrong
anyway.
sorry for that - c&p error on my part when I reenabled emu to do regular
reports again. I actually tested the conf with a -HEAD build but since
it didn't fail I didn't noticed the error immediately.
The problem itself is fixed now and new reports for all affected
branches should be up very soon.
Stefan