FX
Début du message réexpédié :
De : IainS <[EMAIL PROTECTED]> Date : 10 juin 2008 16:50:11 GMT+01:00 À : Fortran List <[EMAIL PROTECTED]>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.xHopefully, at least this will start the ball rolling. Iain
gfortranspec.diff
Description: Binary data
libgf-makefile-am.diff
Description: Binary data
-- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/
