autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Workaround for incorrect gcc exit code?


From: Ralf Wildenhues
Subject: Re: Workaround for incorrect gcc exit code?
Date: Sun, 1 Feb 2009 10:27:21 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

Hello Stephen,

* Stephen P. Schaefer wrote on Fri, Jan 30, 2009 at 03:07:47AM CET:
> I'm seeing the following in config.log;
> 
> configure:8972: checking for setpcred
> configure:9022: gcc -o conftest -O2 -march=i386 -mcpu=i686 -g -fpie
> -I/usr/kerberos/include -I/usr/kerberos/include/gssapi -Wall
> -Wpointer-arith -Wno-uninitialized  -I/usr/kerberos/include
> -I/usr/kerberos/include/gssapi  -pie -L/usr/kerberos/lib conftest.c -lz 
> >&5
> /tmp/ccijWTnn.o(.text+0x19): In function `main':
> /.automount/rfgbfiler1/vol/work/work/sps/rpmbuild/BUILD/openssh-3.9p1/configure:9131:
> undefined reference to `setpcred'
> /tmp/ccijWTnn.o(.data.rel+0x0):/.automount/rfgbfiler1/vol/work/work/sps/rpmbuild/BUILD/openssh-3.9p1/configure:9130:
> undefined reference to `setpcred'
> configure:9025: $? = 0
> configure:9028: test -s conftest
> configure:9031: $? = 0
> configure:9042: result: yes
> 
> ...i.e., gcc is exiting 0 even though it doesn't successfully create
> conftest, and "HAVE_SETPCRED" is getting defined when it shouldn't.  Is
> there a workaround for this?  Some way to attempt to invoke conftest and
> note the failure?

Well, I don't remember seeing such a failure before, not the least with
some gcc version.  I see you are working on a rather old system, but I
guess just updating tools must not be possible for you.

If the link test comes from some AC_CHECK_FUNC* macro, then you can work
around this by presetting the respective cache variable, e.g.,
  ./configure ac_cv_func_setpcred=no

You can seed a config.site file with all the right answers.

> address@hidden ./conftest
> ./conftest: relocation error: ./conftest: undefined symbol: setpcred
> address@hidden echo $?
> 127
> 
> The problem environment is RHEL3, gcc-3.2.3-53.i386,
> binutils-2.14.90.0.4-39.i386 (/bin/ld), autoconf-2.57-3.noarch

This is all quite old.  I don't think that a newer Autoconf alone will
help you, though; I don't remember that we ever worked around such an
issue.

In principle, when not cross-compiling, one could start doing execution
tests.  However, that would make cross compilation a second-class
citizen even more, slow down configure, and can even add other
systematic errors to the results: if libraries are found at link time,
by the link editor, but not at run time, by the runtime linker.  So it's
unlikely Autoconf can fix this well, you may just have to bite the
bullet and get a fixed compiler or linker, whichever of the two is
broken here.

Is that only with -pie -fpie BTW?  I can't imagine such a bug to be
present in the normal compiler/linker modes, and PIE support was only
added right around then to GCC.

Cheers,
Ralf




reply via email to

[Prev in Thread] Current Thread [Next in Thread]