RE: How to properly determin _G_HAVE_PRINTF_FP in cross environs

RE: How to properly determin _G_HAVE_PRINTF_FP in cross environs

[David Korn]

>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 mentioned this in the message at:

http://gcc.gnu.org/ml/gcc/2001-02/msg00294.html

which also contains a couple of pointers to other threads on the same
topic.  This one has been around for a while; general concensus seems to
be to work around it with a constant definition rather than try and
do proper detection.

>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.

  This is pretty much the same solution that Uli Drepper came up with 
in http://gcc.gnu.org/ml/gcc-patches/1999-09n/msg01197.html , although
he actually provided a new target-fragment to contain the definitions.

  My solution was to turn the 'undefined function' warning into an error
with -Wimplicit -Werror added to the compiler invocation in the bit of
code (do the existing test).

  So why do you set it to 1 in the environment when there isn't any 
printf_fp function in VxWorks?

     DaveK
-- 
 All your base are belong to us!


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

Re: How to properly determin _G_HAVE_PRINTF_FP in cross environs

[Peter Dufault]

>   So why do you set it to 1 in the environment when there isn't any 
> printf_fp function in VxWorks?

Umm, I don't.  My mistake, I meant zero.  I'll go through the pointers
you provided.

Peter

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

How to properly determin _G_HAVE_PRINTF_FP in cross environs

[Peter Dufault]

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