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

[FX]

I'm forwarding this to the generic GCC development list, as more  
people might be of help there (including the darwin maintainers), as  
it's more of a darwin and build system issue.

FX


Début du message réexpédié :

> De : IainS <developer@sandoe-acoustics.co.uk>
> Date : 10 juin 2008 16:50:11 GMT+01:00
> À : Fortran List <fortran@gcc.gnu.org>
> Objet : [RFC, Patch, gfortran] make -static-libgfortran work on  
> darwin.
>
> 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
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gfortranspec.diff
Type: application/octet-stream
Size: 3410 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20080610/3706cca0/attachment.obj>
-------------- next part --------------
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: libgf-makefile-am.diff
Type: application/octet-stream
Size: 1167 bytes
Desc: not available
URL: <https://gcc.gnu.org/pipermail/gcc/attachments/20080610/3706cca0/attachment-0001.obj>
-------------- next part --------------
>
>

-- 
François-Xavier Coudert
http://www.homepages.ucl.ac.uk/~uccafco/