Re: gfortran patch - g77 record markers

[Paul Brook <paul at codesourcery dot com>]

> I was wondering about the need for 2 separate, complete, libraries.
> I guess the above answers that.   Should we then consider doing
> something simliar to f2c where it has a libI77, libU77, and libF77?
> That is, we should have a libF95 with the common intrinsics
> procedure, and a libF95io for the current IO implementation and
> libF95io_g77 for Bud's and your implementation of g77 record marks.
>
> The libraries (ie., libgfortran.a and libgfortran.so.0) currently
> take about 4.5 MB of disk space.  Duplicating the libs for g77
> record marks comes to 9 MB, and if someone decides to deal with
> the HP record mark, we'll have 13.5 MB, etc.  Yes, I know disks
> are getting bigger and cheaper, but having several libraries
> with numerous duplicate entries seems inelegant.

You're misunderstanding how the libraries are organised.

We still only have once copy of libgfortran. This contains the whole 
implementation of both types of record markers.

The libgfortran_seqio* libraries do not contain any implementation code. They 
simply contain a startup routine which calls back into the main library to 
select the default record format.

The number of libraries is linear in the number of options we want to support 
(not quadratic), and each library is very small (one function).

Having said that I don't think this is the correct implementation of the 
link-time mechanism. My preference would be instead of linking a shared 
library we link an object file into the executable. This contains an 
__attribute__((constructor)) routine that calls set_default_record_marker_*.
It should be possible to link with just libgfortran.{so,a}, and get a working 
executable with sensible defaults.

Your system with multiple inter-dependant could get messy when linking against 
third party shared libraries that also use libgfortran. Not all OS are quite 
as permissive as linux when it comes to shared library dependencies.

Paul