configure bug? / questions to gcc
Craig Burley
burley@gnu.org
Sat Apr 18 18:12:00 GMT 1998
>Hi,
>I have some questions:
>
>1. Why does egcs-980404 install libf2c into /usr/local/lib
> when doing a 'make cross;make install'?
> There it overwrites the native version of it, which makes
> the native g77 worthless. I think it should go into
> /usr/local/<target-system>/lib.
I have just posted (to egcs@cygnus.com and the g77 alpha-tester
mailing list) a proposal to remove libf2c.a and f2c.h installation
(into system-standard places) from g77 entirely. It's also
in < ftp://alpha.gnu.org/g77.plan > -- please check it out and
comment if you like!
Meanwhile, that egcs automatically overwrites the system's version
of ${prefix}/lib/libf2c.a and ${prefix}/include/f2c.h (or whatever)
is, IMO, a bug in egcs, probably resulting from trying to
convert from gcc's organization to egcs's. What was lost was
that g77 did these installations *conditionally* on whether
a file named `f2c-install-ok' existing in the source or build
directories (or whether the relevant `make' macro was defined during
the build). This is an easy bug to fix, fortunately, at least
by simply deleting or modifying the relevant line(s) in the makefile,
but I'm not ready to work on that just yet myself (I don't have
a recent working egcs snapshot, for one thing).
Not sure about any possible egcs 1.0.3, but I'm hoping that
egcs 1.1 will no longer install libf2c.a and f2c.h, thus avoiding
the problem entirely. f2c.h isn't needed at all except during
the build; libf2c.a can just be installed within the `gcc-lib'
area, a "private" one used only by gcc. They can both be copied
by hand to /usr/local/lib and /usr/local/include, or whatever, by a
sysadmin who wants to enable more reliable inter-operability between
g77 and f2c, and that's probably more reliable than g77/egcs guessing
as to where f2c's installed bits live on a given system. See the
post in the g77.plan file (URL above) for more info.
>3. I would like to do some hacking of gcc/g77. Is there some
> documentation about the compiler internals? How does it work?
See the gcc docs for gcc. See a file named README.g77 and the
g77 docs for some very sketchy info on the g77 front end.
> Which intermediate code? How is code-generaion done? What
> has the front end to provide, which file implements what?...
That's mostly gcc-specific, and the front-end stuff is not yet
very well described.
> How long did it take you to get an principal idea of the way it
> works?
Well, writing the g77 front end helped me understand that ;-), but
learning the basics behind the gcc back end and the interface it
provides to the front end took me quite awhile, at least by my
own standards, probably because I was spending a lot of time fighting
bugs in my own code as well as in the back end early on, leaving
not much time to acclimate myself to the interface and design.
Due to the pace of change in gcc, well, now, egcs, I personally
work on a "need-to-know" basis for the most part. That is, if I
don't need to know it now, I put learning it off until later,
at which point it might have changed, after all. Well, the problem
with that is, it's completely different from the way I learn
most of my programming skills, guess I'm just too busy and the
planet is spinning too fast these days.
Note that a rapid way to learn about gcc's code generation in one
fell swoop is to read about and learn from reading the RTL dumps
provided by the -dA option (or whatever) when compiling sample
code (C, Fortran, whatever). That's pretty fascinating stuff,
though it can be overwhelming to a newcomer.
tq vm, (burley)
More information about the Gcc-bugs
mailing list