This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

libio / gen-params and __printf_fp test



      Hi Per,

  Your name is at the top of this file, so I thought I'd ask you about
one of the tests in it, lines 712-725 (in 2.95.2 release, and probably
the same in 2.95.3)

-------------------------------------------------------------------------
# A little test program to check if __printf_fp is available.
cat >dummy.c <<EOF
int main()
{
    return __printf_fp ();
}
EOF

if ${CC} dummy.c >/dev/null 2>&1 ; then
  echo "#define ${macro_prefix}HAVE_PRINTF_FP 1"
  echo "#define ${macro_prefix}HAVE_LONG_DOUBLE_IO 1"
else
  echo "#define ${macro_prefix}HAVE_PRINTF_FP 0"
  echo "#define ${macro_prefix}HAVE_LONG_DOUBLE_IO 0"
fi
-------------------------------------------------------------------------

  Now, on the cross-target I'm developing for (powerpc-wrs-vxworks),
we don't have printf_fp.  But this test still sets the defines to 1.  This
is because under vxworks, we always compile with the linker -r flag; the
C runtime lib. is build into the OS and dynamically linked into our
applications at runtime.

  So the test succeeds because the compiler treats __printf_fp as an
implicitly declared function and doesn't complain, and the linker expects
that it is a symbol that will be dynamically linked at runtime and doesn't
complain, and then the target libs fail to build quite dramatically,
because they don't actually have __printf_fp.

  In my local tree I've added -Wimplicit and -Werror to the $(CC) command,
which makes the test compile fail properly.  Problem is, this doesn't
seem like quite the right thing either, because what we're then testing
is a matter of whether or not the function is declared in the target
headers, rather than whether it actually exists in the target library or
OS.

  I was wondering if you had any thoughts on what would be the most
generic, portable and robust way to tighten up this test?

  A patch to let the makefile override this test was suggested in 
http://gcc.gnu.org/ml/gcc-patches/1999-09n/msg01197.html
and the issue was also mentioned in
http://gcc.gnu.org/ml/gcc/1999-08n/msg00995.html
as it arose in another port as well.

         DaveK
-- 
we are not seats or eyeballs or end users or consumers.
we are human beings - and our reach exceeds your grasp.
                    deal with it.                      - cluetrain.org 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]