This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
How to properly determin _G_HAVE_PRINTF_FP in cross environs
- To: gcc-help at gcc dot gnu dot org
- Subject: How to properly determin _G_HAVE_PRINTF_FP in cross environs
- From: Peter Dufault <dufault at hda dot hda dot com>
- Date: Sat, 24 Mar 2001 17:03:08 -0500 (EST)
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