[RFC, Patch, gfortran] make -static-libgfortran work on darwin.

[IainS <developer at sandoe-acoustics dot co dot uk>]

The current implementation of -static-libgfortran has no effect on  
darwin{8,9}
[http://gcc.gnu.org/ml/fortran/2008-05/msg00365.html, http:// 
gcc.gnu.org/ml/fortran/2008-06/msg00017.html ]

Linking a static ".a" lib works fine on the platform.  However, since  
the vendor doesn't provide a (userland) static system library, it  
seems that collect2 must always be invoked with '-dynamic' when  
building an executable.   [neglecting the special case of kernel  
extensions].

--

The current '-static-libgfortran' implementation has the same  
basename for the static and dynamic library versions, and "-dynamic"  
is invoked by collect2.

according to the (darwin8) ld man page:
"-lx    This  option  is  an abbreviation for the library name  
`libx.a',  where x is a string.  If -dynamic is specified the   
abbreviation
              for  the  library  name is first search as  
`libx.dylib' and then `libx.a' is searched for."

The man page for ld(64) on darwin9 is less categorical on the subject  
- but it seems that the behavior is the same on 9.

-----
The solution is to name the libs differently (as is done elsewhere in  
gcc).

Even though this appears to be a simple issue, I don't know my way  
around the gcc tree/build system very well...
so I find it difficult to forecast if these proposed changes would  
impact elsewhere.

==== proposed changes.

I opted to call the static library "libgfortran_static" and to leave  
the shared name unchanged.

It would be great if libtool could be persuaded to change the  
basename as well as the extension for the dynamic/static
but despite RTFM and googling I can't seem to find any example of how  
to achieve that in an easy manner.
====

Patch1 modifies gfortranspec.c to use different lib names.

It is possible to accommodate the required lib name change at install  
time by renaming libgfortran.a and ranlib-ing the new one.
however, I decided to leave the existing lib alone - and generate  
what was wanted explicitly.

Patch2  modifies the libgfortran/Makefile.am to generate a  
libgfortran_static.

====
regtested on powerpc-apple-darwin8 (m32)

however, I'm not sure how to make a formal test case for the change:
...  since to prove that the static lib has been used requires  
inspection of the generated executable.

[ if you tested the current implementation then  "-static- 
libgfortran" would compile and execute perfectly OK
.... but the actual library being used would be libgfortran.3.dylib ]

====

These are against 4.4.0/trunk - although pretty much the same should  
be OK on 4.3.x

Hopefully, at least this will start the ball rolling.
Iain

Attachment: gfortranspec.diff
Description: Binary data

Attachment: libgf-makefile-am.diff
Description: Binary data