Go to the first, previous, next, last section, table of contents.


Distributing Binaries

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:

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:

`bin/g77'
This is the command most users use to compile Fortran.
`bin/gcc'
This is the command some users use to compile Fortran, typically when compiling programs written in other languages at the same time. The `bin/gcc' executable file must have been built from a gcc source tree into which a g77 source tree was merged and configured, or it will not know how to compile Fortran programs.
`info/g77.info*'
This is the documentation for 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.
`man/man1/g77.1'
This is the short man page for g77. It is not always kept up-to-date, but you might as well include it for people who really like "man" pages.
`lib/gcc-lib'
This is the directory containing the "private" files installed by and for gcc, g77, g++, and other GNU compilers.
`lib/gcc-lib/.../f771'
This is the actual Fortran compiler.
`lib/gcc-lib/.../libg2c.a'
This is the run-time library for 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.