From mboxrd@z Thu Jan  1 00:00:00 1970
From: Peter Dufault <dufault@hda.hda.com>
To: gcc-help@gcc.gnu.org
Subject: How to properly determin _G_HAVE_PRINTF_FP in cross environs
Date: Sat, 24 Mar 2001 14:03:00 -0000
Message-id: <200103242203.f2OM38210103@hda.hda.com>
X-SW-Source: 2001-03/msg00228.html

In searching the archives I saw this came up several times but I didn't
find a solution provided.  I have a work around, I'd like pointers to
the correct solution.

When building a cross toolset (target=vxworks host=FreeBSD but I
believe only target=vxworks is the problem) libio/gen-params
improperly decides that there is a printf.h because the cross ld
leaves programs relocateable and gen-params determines there is a printf.h by
cross-compiling this and not getting an error for an undefined symbol:

> int main() { return __printf_fp (); }

I'm using binutils 2.10.1 and gcc-2.95.3, configuration info at the bottom.

Here is what gen-params is doing, using -v so we can see the link line:

> $ CC="/cross-build/client/gcc-2.95.3/i486-wrs-vxworks/gcc/xgcc -B/cross-build/client/gcc-2.95.3/i486-wrs-vxworks/gcc/ -B/client/i486-wrs-vxworks/i486-wrs-vxworks/bin/ -I. -I../../../libio"; export CC;
> $ echo "int main() { return __printf_fp (); }" > dummy.c
> $ ${CC} -v dummy.c
(...)
>  /cross-build/client/gcc-2.95.3/i486-wrs-vxworks/gcc/cc1 /var/tmp/ccpHqOvV.i -quiet -dumpbase dummy.c -version -o /var/tmp/cc2BicGM.s
> GNU C version 2.95.3 20010315 (release) (i486-wrs-vxworks) compiled by GNU C version 2.95.2 19991024 (release).
>  /client/i486-wrs-vxworks/i486-wrs-vxworks/bin/as -o /var/tmp/ccBaSy7j.o /var/tmp/cc2BicGM.s

Here's the problem: ld is collect2 and it uses -r so this doesn't fail:

>  /cross-build/client/gcc-2.95.3/i486-wrs-vxworks/gcc/collect2 -r -L/client/i486-wrs-vxworks/i486-wrs-vxworks/bin -L/cross-build/client/gcc-2.95.3/i486-wrs-vxworks/gcc -L/client/i486-wrs-vxworks/lib/gcc-lib/i486-wrs-vxworks/2.95.3 -L/client/i486-wrs-vxworks/i486-wrs-vxworks/lib /var/tmp/ccBaSy7j.o -lgcc -lgcc

but note:

> $ nm386 a.out | grep printf
>         U ___printf_fp

Now for my workaround.

I put a test into gen-params similar to the one for HAVE_BOOL a few
lines earlier:

> if test -n "${HAVE_PRINTF_FP}" ; then
>  echo "#define ${macro_prefix}HAVE_PRINTF_FP ${HAVE_PRINTF_FP}"
>  echo "#define ${macro_prefix}HAVE_LONG_DOUBLE_IO ${HAVE_PRINTF_FP}"
> else
(do the existing test)
> fi

then I set HAVE_PRINTF_FP to 1 in the environment which is obviously
wrong.

How should this be done properly?  In what file would HAVE_PRINTF_FP be
set based on a vxworks target so that things run through without any
hand tweaking?  Is this a problem with gcc or binutils?

Peter

Configuration: Binutils:

> configure --program-suffix=386 --prefix=someplace --target=i486-wrs-vxworks 

gcc:

> configure --program-suffix=386 --prefix=someplace --target=i486-wrs-vxworks \
--enable-languages=cc,c++ \
--with-march=486 --without-newlib


--
Peter Dufault (dufault@hda.com)   Realtime development, Machine control,
HD Associates, Inc.               Fail-Safe systems, Agency approval