strtoul vs g77

strtoul vs g77

[Jeffrey A Law]

I've added autoconf code to automatically detect when strtoul and
bsearch should be compiled into f771 from proj.c.

This code will appear in the next snapshot and should remove the need
to hack up proj.h or pass gross options around to work g77 work on
sunos4 and other lame hosts.

jeff

Re: strtoul vs g77

[Alexandre Oliva]

Jeffrey A Law writes:

> I've added autoconf code to automatically detect when strtoul and
> bsearch should be compiled into f771 from proj.c.

I had thought of doing that as soon as egcs started, but there's the
cross-compiler issue.  Will your tests behave correctly in case of
cross-compilation? 

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
Universidade Estadual de Campinas, SP, Brasil

Re: strtoul vs g77

[Jeffrey A Law]

  In message < orhgbhn8xr.fsf@sunsite.dcc.unicamp.br >you write:
  > Jeffrey A Law writes:
  > 
  > > I've added autoconf code to automatically detect when strtoul and
  > > bsearch should be compiled into f771 from proj.c.
  > 
  > I had thought of doing that as soon as egcs started, but there's the
  > cross-compiler issue.  Will your tests behave correctly in case of
  > cross-compilation? 
Yes/No.

For a simple cross compiler, yes it should work since it's testing
a feature of the host/build machine.

I don't think it will work for a 3-way cross, then again, it
might.  Someone will have to try it.

Jeff

Re: strtoul vs g77

[Craig Burley]

>Jeffrey A Law writes:
>
>> I've added autoconf code to automatically detect when strtoul and
>> bsearch should be compiled into f771 from proj.c.
>
>I had thought of doing that as soon as egcs started, but there's the
>cross-compiler issue.  Will your tests behave correctly in case of
>cross-compilation? 

I hope this all works.  It'd be a *huge* relief if it did.  As
any of you might observe in my commentary in gcc/f/proj.c, we
*did* attempt to do this a couple of years ago (or so -- has it
been that long?!).  The effect worked on SunOS systems IIRC, but
it *broke* the configuration on some systems that *did* have a
working ANSI C library, complete with bsearch() and strtoul(),
and we couldn't figure out why.

So maybe enough time has passed and bugs in tools we were relying
upon (autoconf, ld, shells, sed, who knows what ;-) have been
fixed.

But just a word of caution -- if you write a perfectly reasonable
autoconf clause that *should* detect strtoul, but somehow results
in breakages on ANSI C systems, don't worry that you're the first
person to run into this problem.  Just worry that you're the first
to fix it (I hope).  :)

Sure is nice having lots more people look at, and care about, g77.

        tq vm, (burley)

Re: strtoul vs g77

[Jeffrey A Law]

  In message < 199709190627.CAA28904@churchy.gnu.ai.mit.edu >you write:
  > I hope this all works.  It'd be a *huge* relief if it did.  As
  > any of you might observe in my commentary in gcc/f/proj.c, we
  > *did* attempt to do this a couple of years ago (or so -- has it
  > been that long?!).
Yes, it was a comment dated sometime in 1995.

  > The effect worked on SunOS systems IIRC, but
  > it *broke* the configuration on some systems that *did* have a
  > working ANSI C library, complete with bsearch() and strtoul(),
  > and we couldn't figure out why.
Well, that's what we have autoconf for -- if it doesn't work on
some system that has bsearch and/or strtoul, then we'll go fix
autoconf.  This is precisely the kind of problem autoconf should
be solving for us.

  > So maybe enough time has passed and bugs in tools we were relying
  > upon (autoconf, ld, shells, sed, who knows what ;-) have been
  > fixed.
Or autoconf is just better at hiding many of the details of those
broken tools from us; which is just as good as far as I'm concerned.

jeff

Re: strtoul vs g77

[Dave Love]

>>>>> "Jeffrey" == Jeffrey A Law <law@cygnus.com> writes:

 >> The effect worked on SunOS systems IIRC, but
 >> it *broke* the configuration on some systems that *did* have a
 >> working ANSI C library, complete with bsearch() and strtoul(),
 >> and we couldn't figure out why.
 Jeffrey> Well, that's what we have autoconf for -- if it doesn't work
 Jeffrey> on some system that has bsearch and/or strtoul, then we'll
 Jeffrey> go fix autoconf.  This is precisely the kind of problem
 Jeffrey> autoconf should be solving for us.

Yes.  The only reason it wasn't just fixed or noted somewhere as a
problem was lack of a proper bug report; I think the information got
lost about what system it was on.

[I know of at least one system where the (constant?) status returned
by ld rendered autoconf rather useless, but I don't remember in what
direction this went -- whether it caused trouble or just fell back to
OK defaults.  AFAIR the autoconf maintainer declined to put in a
sanity check for such lossage.]

Assuming you did it the same way as originally, it's fine for cross
situations (insofar as the rest of things are); you necessarily have
the tools available when the configuration test is done because you're
about to build f771.

What would be nice would be if we could pick up stuff from libiberty
so that the appropriate routines were just available anyhow (possibly
even for the target by adding them to libgcc.a if appropriate).  I
initially thought that was why libiberty was included.

Re: strtoul vs g77

[Jeffrey A Law]

  In message < rzqzpp9dlyv.fsf@djlvig.dl.ac.uk >you write:
  > Yes.  The only reason it wasn't just fixed or noted somewhere as a
  > problem was lack of a proper bug report; I think the information got
  > lost about what system it was on.
Well, if it crops up again, we'll be able to get a full report and
deal with it.

  > Assuming you did it the same way as originally, it's fine for cross
  > situations (insofar as the rest of things are); you necessarily have
  > the tools available when the configuration test is done because you're
  > about to build f771.
Basically, yes, though marginally simpler.  The code in proj.c has
#ifndef BLAH conditionals around it rather than dealing with FFEPROJ_BLAH

  > What would be nice would be if we could pick up stuff from libiberty
  > so that the appropriate routines were just available anyhow (possibly
  > even for the target by adding them to libgcc.a if appropriate).  I
  > initially thought that was why libiberty was included.
It's in the back of my mind :-) :-)

jeff

Re: strtoul vs g77

[Dave Love]

>>>>> "Jeffrey" == Jeffrey A Law <law@hurl.cygnus.com> writes:

 >> Assuming you did it the same way as originally, it's fine for cross
 >> situations (insofar as the rest of things are); you necessarily have
 >> the tools available when the configuration test is done because you're
 >> about to build f771.
 Jeffrey> Basically, yes, though marginally simpler.  The code in proj.c has
 Jeffrey> #ifndef BLAH conditionals around it rather than dealing with 
 Jeffrey> FFEPROJ_BLAH

I now realize why there was a query about this for cross-compiling.
It seems the new configure tests only apply to the build system, not
the host, whereas what I meant by `same way as originally' tested the
host (generating f/proj.h with a configure script at build time).  Am
I missing something about this?  If not, should I reinstate the old
mechanism for host tests?

Re: strtoul vs g77

[Jeffrey A Law]

  In message < rzq3emn22dt.fsf@djlvig.dl.ac.uk >you write:
  > I now realize why there was a query about this for cross-compiling.
  > It seems the new configure tests only apply to the build system, not
  > the host, whereas what I meant by `same way as originally' tested the
  > host (generating f/proj.h with a configure script at build time).  Am
  > I missing something about this?  If not, should I reinstate the old
  > mechanism for host tests?
For a canadian cross, we're in the same position before and after
my strtoul patch.

ie most of time it'll work, but for a few oddballs you'll have
to pass a -D arg into the compiler to get it to work.

jeff