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

[Ralf Wildenhues <Ralf.Wildenhues@gmx.de>]

Hello,

* FX wrote on Tue, Jun 10, 2008 at 05:59:36PM CEST:
>> De : IainS <developer@sandoe-acoustics.co.uk>
>>
>> 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.

It doesn't do that because that breaks the abstraction.  It might also
increase a bit the risk of ending up with bits of the static library
included, and bits of shared deplibs you use pulling in the shared
version of the library.

Can the driver use path/to/libgfortran.a instead of '-Lpath/to
-lgfortran' to avoid being hindered by missing -Bstatic/-Bdynamic?

Independently, does anybody know whether odcctools is dead (homepage
seems to be down ATM)?
<http://thread.gmane.org/gmane.comp.gnu.libtool.general/7158/focus=7173>

>> It is possible to accommodate the required lib name change at install
>> time by renaming libgfortran.a and ranlib-ing the new one.

Don't try this on AIX, where libtool may create a shared archive with
that name.

>> 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.

This is what we use within the libtool testsuite (not fool-proof!):
- remove the shared library before running the executable.

To make it a bit more fool-proof:
- after generating the executable, create an incompatible shared
  library, install it in some temporary directory, let that directory
  be searched early by the runtime linker.

Not sure what level of overkill is suitable for GCC.  ;-)


I agree with FX that it would be nice to limit a change to Darwin if at
all.

Cheers,
Ralf