If you are building g77
for distribution to others in binary form,
first make sure you are aware of your legal responsibilities (read
the file `gcc/COPYING' thoroughly).
Then, consider your target audience and decide where g77
should
be installed.
For systems like GNU/Linux that have no native Fortran compiler (or
where g77
could be considered the native compiler for Fortran and
gcc
for C, etc.), you should definitely configure
g77
for installation
in `/usr/bin' instead of `/usr/local/bin'.
Specify the
`--prefix=/usr' option when running `./configure'.
You might also want to set up the distribution
so the `f77' command is a link to `g77',
although a script that accepts "classic" UNIX f77
options and translates the command-line to the
appropriate g77
command line would be more appropriate.
If you do this, please also provide a "man page" in
`man/man1/f77.1' describing the command.
(A link to `man/man1/g77.1' is appropriate
if `bin/f77' is a link to `bin/g77'.)
For a system that might already have f2c
installed,
consider whether inter-operation with g77
will be
important to users of f2c
on that system.
If you want to improve the likelihood
that users will be able to use both f2c
and g77
to compile code for a single program
without encountering link-time or run-time incompatibilities,
make sure that,
whenever they intend to combine f2c
-produced code
with g77
-produced code in an executable, they:
g77
build
in place of the `f2c.h' file
that normally comes with f2c
(or versions of g77
prior to 0.5.23)
when compiling all of the f2c
-produced C code
lib/gcc-lib/.../libg2c.a
library
built by the g77
build
instead of the `libf2c.a' library
that normally comes with f2c
(or versions of g77
prior to 0.5.23)
How you choose to effect the above depends on whether
the existing installation of f2c
must be
maintained.
In any case, it is important to try and ensure that
the installation keeps working properly even after
subsequent re-installation of f2c
,
which probably involves overwriting
`/usr/local/lib/libf2c.a' and
`/usr/local/include/f2c.h',
or similar.
At least, copying `libg2c.a' and `g2c.h' into
the appropriate "public" directories
allows users to more easily select the version of
libf2c
they wish to use for a particular
build.
The names are changed by g77
to make this
coexistence easier to maintain;
even if f2c
is installed later,
the g77
files normally installed
by its installation process aren't disturbed.
Use of symbolic links from one set of files to
another might result in problems after a subsequent
reinstallation of either f2c
or g77
,
so be sure to alert users of your distribution
accordingly.
(Make sure you clearly document, in the description of
your distribution, how installation of your distribution will
affect existing installations of gcc
, f2c
,
f77
, `libf2c.a', and so on.
Similarly, you should clearly document any requirements
you assume will be met by users of your distribution.)
For other systems with native f77
(and cc
) compilers,
configure g77
as you (or most of your audience) would
configure gcc
for their installations.
Typically this is for installation in `/usr/local',
and would not include a new version of `/usr/bin/f77'
or `/usr/local/bin/f77',
so users could still use the native f77
.
In any case, for g77
to work properly, you must ensure
that the binaries you distribute include:
gcc
source tree into which a g77
source
tree was merged and configured, or it will not know how
to compile Fortran programs.
g77
.
If it is not included, users will have trouble understanding
diagnostics messages and other such things, and will send
you a lot of email asking questions.
Please edit this documentation (by editing `gcc/f/*.texi'
and doing `make doc' from the `/usr/src/gcc' directory)
to reflect any changes you've made to g77
, or at
least to encourage users of your binary distribution to
report bugs to you first.
Also, whether you distribute binaries or install g77
on your own system, it might be helpful for everyone to
add a line listing this manual by name and topic to the
top-level info
node in `/usr/info/dir'.
That way, users can find g77
documentation more
easily.
See section Updating Your Info Directory.
g77
.
It is not always kept up-to-date,
but you might as well include it
for people who really like "man" pages.
gcc
, g77
, g++
,
and other GNU compilers.
g77
-compiled programs.
Whether you want to include the slightly updated (and possibly improved) versions of `cc1', `cc1plus', and whatever other binaries get rebuilt with the changes the GNU Fortran distribution makes to the GNU back end, is up to you. These changes are highly unlikely to break any compilers, because they involve doing things like adding to the list of acceptable compiler options (so, for example, `cc1plus' accepts, and ignores, options that only `f771' actually processes).
Please assure users that unless they have a specific need for their existing, older versions of `gcc' command, they are unlikely to experience any problems by overwriting it with your version--though they could certainly protect themselves by making backup copies first!
Otherwise, users might try and install your binaries in a "safe" place, find they cannot compile Fortran programs with your distribution (because, perhaps, they're invoking their old version of the `gcc' command, which does not recognize Fortran programs), and assume that your binaries (or, more generally, GNU Fortran distributions in general) are broken, at least for their system.
Finally, please ask for bug reports to go to you first, at least
until you're sure your distribution is widely used and has been
well tested.
This especially goes for those of you making any
changes to the g77
sources to port g77
, e.g. to OS/2.
fortran@gnu.org has received a fair number of bug
reports that turned out to be problems with other peoples' ports
and distributions, about which nothing could be done for the
user.
Once you are quite certain a bug report does not involve
your efforts, you can forward it to us.
Go to the first, previous, next, last section, table of contents.