Hello Ralf,
On Sun, 1 Feb 2009 10:27:21 +0100, "Ralf Wildenhues"
<Ralf.Wildenhues@xxxxxx> said:
> 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.
Thank you for suggesting config.site. I see that it is discussed in
Chapter 14 of the manual, although it doesn't appear in the index.
config.site appears to be a better answer than what I was doing, which
was to define OSSH_CHECKRUN_FUNCS and OSSH_TRY_LINKRUN, as below, and
use them instead of AC_CHECK_FUNCS and AC_TRY_LINK. You're right that
this would hurt cross-compiling. I hadn't contemplated sending the
changes upstream, since what I'm doing is trying to build an ssh client
and server that supports GSSAPI authentication, which isn't supported by
RHEL3.
The code I'm trying to build is from RHEL4, but in an RHEL3 environment.
Both Red Hat and OpenBSD have moved well beyond what I'm trying to
address: Red Hat, by policy, provides bug fixes but (very rarely) new
features to older major releases, and OpenBSD has a much newer release
of openssh. I'm dealing with RHEL3 because I'm supporting chip design
platforms where adjustments are being made to designs already in
production, and it's more important that the tools get the *same* answer
than any arguably more correct answer. Nonetheless, the environment,
including security requirements, changes around them. I'm using an
older version of openssh under the likely flawed theory that more
contemporaneous code will better fit the environment.
> > sschaefe@modela022 ./conftest
> > ./conftest: relocation error: ./conftest: undefined symbol: setpcred
> > sschaefe@modela022 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.
For curiousity's sake, but not recommended:
dnl get around inappropriate exit 0 from gcc
m4_define([_OSSH_LINKRUN_IFELSE],
[m4_ifvaln([$1], [AC_LANG_CONFTEST([$1])])dnl
rm -f conftest.$ac_objext conftest$ac_exeext
AS_IF([AC_TRY_EVAL(ac_link) &&
AC_TRY_COMMAND([test -s conftest$ac_exeext]) &&
AC_TRY_COMMAND([./conftest$ac_exext])],
[$2],
[_AC_MSG_LOG_CONFTEST
m4_ifvaln([$3], [$3])dnl])[]dnl
rm -f conftest.$ac_objext conftest$ac_exeext m4_ifval([$1],
[conftest.$ac_ext])[]dnl
])# _OSSH_LINKRUN_IFELSE
dnl # OSSH_LINKRUN_IFELSE(PROGRAM, [ACTION-IF-FOUND],
[ACTION-IF-NOT-FOUND])
dnl # -----------------------------------------------------------------
dnl # Try to link PROGRAM. Requires that the compiler for the current
dnl # language was checked for, hence do not use this macro in macros
looking
dnl # for a compiler.
AC_DEFUN([OSSH_LINKRUN_IFELSE],
[AC_LANG_COMPILER_REQUIRE()dnl
_OSSH_LINKRUN_IFELSE($@)])
dnl # OSSH_CHECK_FUNC(FUNCTION, [ACTION-IF-FOUND],
[ACTION-IF-NOT-FOUND])
dnl # -----------------------------------------------------------------
AC_DEFUN([OSSH_CHECKRUN_FUNC],
[AS_VAR_PUSHDEF([ac_var], [ac_cv_func_$1])dnl
AC_CACHE_CHECK([for $1], ac_var,
[OSSH_LINKRUN_IFELSE([AC_LANG_FUNC_LINK_TRY([$1])],
[AS_VAR_SET(ac_var, yes)],
[AS_VAR_SET(ac_var, no)])])
AS_IF([test AS_VAR_GET(ac_var) = yes], [$2], [$3])dnl
AS_VAR_POPDEF([ac_var])dnl
])# OSSH_CHECKRUN_FUNC
dnl # AC_CHECK_FUNCS(FUNCTION..., [ACTION-IF-FOUND],
[ACTION-IF-NOT-FOUND])
dnl #
---------------------------------------------------------------------
AC_DEFUN([OSSH_CHECKRUN_FUNCS],
[AC_FOREACH([AC_Func], [$1],
[AH_TEMPLATE(AS_TR_CPP(HAVE_[]AC_Func),
[Define to 1 if you have the `]AC_Func[' function.])])dnl
for ac_func in $1
do
OSSH_CHECKRUN_FUNC($ac_func,
[AC_DEFINE_UNQUOTED([AS_TR_CPP([HAVE_$ac_func])]) $2],
[$3])dnl
done
])
dnl # OSSH_TRY_LINKRUN(INCLUDES, FUNCTION-BODY,
dnl # [ACTION-IF-FOUND], [ACTION-IF-NOT-FOUND])
dnl # -----------------------------------------------------
dnl # Contrarily to AC_LINK_IFELSE, this macro double quote its first
two args.
AU_DEFUN([OSSH_TRY_LINKRUN],
[OSSH_LINKRUN_IFELSE([AC_LANG_PROGRAM([[$1]], [[$2]])], [$3], [$4])])
> 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
I believe you're correct in your speculation about -pie. When (this)
gcc gets called without "-pie" and an undefined reference, I see a
message
collect2: ld returned 1 exit status
...but with the -fpie -pie flags, that message does not occur. GCC has
been so reliable that I've forgotten any of the internals I used to know
15 years ago :-).
Thank you for the advice.
- Stephen
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
