Re: Compiliation failure

[Craig Burley <burley at gnu dot org>]

>  In message <rzq90m4piwh.fsf@djlvig.dl.ac.uk>you write:
>  > I'm not sure which build directory that means, but when I tried
>  > deleting just the library one it definitely didn't DTRT, possibly
>  > under some specific condition I don't recall.
>  > 
>  > If someone expert at configuration stuff could volunteer quickly to
>  > sort out the libf2c configure/build to Craig's satisfaction, it would
>  > be very helpful.
>What issues need to be resolved for libf2c?  I thought we took care of
>all the configury junk a long time ago.

I got the stuff to configure and build purely in a "minimalist" way,
to pattern g77 0.5.23, as part of trying to learn all these twisty
mazes of tools and dependencies.  My main goal was trying to get
libf2c to build properly in a normal build, along with being sure
I understood each step of the process.

Dave (and most everyone else) properly wants the libf2c build process
to work from whatever subdirectory it is built from and to properly
recognize when individual things need to be rebuilt.

I've expressed concerns about a patch he sent to me to rework lots
of it, initially just ones that reflect old bugs it took me a long
time to fix and I don't want to see resurface.

But there's evidence that they won't with his approach, so if it's
still okay, I'd like for his work to go into egcs 1.1, though I
have yet to send him the more minor comments I had.  He'll probably
send his "final" patch to egcs-patches first.

        tq vm, (burley)

P.S. The main concern I had was to not regress to where g77 was
awhile ago, namely, `make install' under normal, post-build
circumstances rebuilding anything.  If it does that, then `root'
cannot reliably do `make install' from an NFS-mounted build tree
without adequate write permissions in the build tree.  g77's
approach to handling the warts relating to trying to have multiple
Makefiles contribute to a single archive, libf2c.a, used to result
in `make install' always doing `$(AR) rc libf2c.a ...', which
resulted from fixing other bugs relating to not always properly
rebuilding libf2c-related targets and adding .o's to the archive.