Re: gen-params problem

Re: gen-params problem

[Ulrich Drepper]

sxthree@penfeld.tls.mms.fr (SXTHREE) writes:

> Since some OSes do not perform a final link (do not
> produce an executable, but instead an object that may
> still contain relocations) we should not rely on that
> behaviour.

Which OSes do you refer to?

The mechanism to use linking is used in all GNU packages.  There
shouldn't be a problem except for embedded platforms which will be
treated special.

> Since when _G_HAVE_PRINTF_FP is defined, printf.h
> is included (in iostream.cc), we should check for 
> the presence of this file.

This is not ok since the header is also present in some situations
where the function is not available.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: gen-params problem

[Jeffrey A Law]

  In message < 199804230705.JAA08541@penfeld.tls.mms.fr >you write:
  > 
  > > Which OSes do you refer to?
  > 
  > > The mechanism to use linking is used in all GNU packages.  There
  > > shouldn't be a problem except for embedded platforms which will be
  > > treated special.
  > 
  > Indeed it is an embedded platform (VxWorks).
Actually VxWorks is pretty special in this regard -- I don't think
other embedded targets have this problem.

jeff

Re: gen-params problem

[Ulrich Drepper]

sxthree@penfeld.tls.mms.fr (SXTHREE) writes:

> OK, then the only solution seems to be making some specific code
> for handling special OSes.

This is how it will be.  I have no solution at hand in the moment, though.
In theory, gen-params shouldn't run for embedded platforms.

> One strange thing is that I've successfully built egcs-1.02 release
> for a m68k-wrs-vxworks5 platform and I've got many problems with
> egcs-19980411 for powerpc-wrs-vxworks5.3.
> What are the major differences regarding _G_HAVE_PRINTF_FP ?

There are none.  This definition is meaningless for all these
platforms.  The only difference can be that the tools on m68k work
different than on ppc and so linking did not succeed on m68k.

-- Uli
---------------.      drepper at gnu.org  ,-.   1325 Chesapeake Terrace
Ulrich Drepper  \    ,-------------------'   \  Sunnyvale, CA 94089 USA
Cygnus Solutions `--' drepper at cygnus.com   `------------------------

Re: gen-params problem

[SXTHREE]

> Which OSes do you refer to?

> The mechanism to use linking is used in all GNU packages.  There
> shouldn't be a problem except for embedded platforms which will be
> treated special.

Indeed it is an embedded platform (VxWorks).

> > Since when _G_HAVE_PRINTF_FP is defined, printf.h
> > is included (in iostream.cc), we should check for 
> > the presence of this file.

> This is not ok since the header is also present in some situations
> where the function is not available.

OK, then the only solution seems to be making some specific code
for handling special OSes.

One strange thing is that I've successfully built egcs-1.02 release
for a m68k-wrs-vxworks5 platform and I've got many problems with
egcs-19980411 for powerpc-wrs-vxworks5.3.
What are the major differences regarding _G_HAVE_PRINTF_FP ?

FM

gen-params problem

[SXTHREE]

While checking for the availability of __printf_fp,
gen-params expects the linker to return an error
while trying to link a program using __printf_fp
if it is undefined.

Since some OSes do not perform a final link (do not
produce an executable, but instead an object that may
still contain relocations) we should not rely on that
behaviour.

Since when _G_HAVE_PRINTF_FP is defined, printf.h
is included (in iostream.cc), we should check for 
the presence of this file.

Following patch works for me:
diff gen-params.old gen-params
707,712c707
< cat >dummy.c <<EOF
< int main()
< {
<     return __printf_fp ();
< }
< EOF
---
> echo '#include <printf.h>' > dummy.c

FM