Go to the first, previous, next, last section, table of contents.
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.