This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
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
Attachment:
gfortranspec.diff
Description: Binary data
Attachment:
libgf-makefile-am.diff
Description: Binary data
-- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |