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

[IainS]

On 10 Jun 2008, at 20:06, Ralf Wildenhues wrote:

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

OK, I appreciate the first part;
I don't immediately understand how  libfoo-static.a  is any more  
dangerous than libfoo.a
or libfoo-s.dylib ....  libfoo.so

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

this doesn't appear to work. [I've unset DYLD_LIBRARY_PATH in the  
following]

  ./dst-powerpc/usr/bin/gfortran-4.4.0 helloi.F90 /Volumes/UFSScratch/ 
GCC/gcc-44-build/dst-powerpc/usr/lib/gcc/powerpc-apple-darwin8/4.4.0/ 
libgfortran.a -o helloif

thor:/Volumes/UFSScratch/GCC/gcc-44-build $ ./helloif

dyld: Library not loaded: /usr/lib/gcc/powerpc-apple-darwin8/4.4.0/ 
libgfortran.3.dylib
   Referenced from: /Volumes/UFSScratch/GCC/gcc-44-build/./helloif
   Reason: image not found
Trace/BPT trap

it appears to be ignoring my directly-specified library and linking  
in the dynamic one anyway.

we could campaign for a different linker on OSX/Darwin I guess...
... but it seems that ld64 is the vendor's preferred solution (given  
the publicly released source for 10.5)

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

macports does install this; although it doesn't understand m64 mach-o  
(at least objdump doesn't)
The difficulty becomes that one cannot supply something that is  
compatible with the vendor's standard installation.

We start to require that the end user has administration rights to  
install into /usr simply in order to run a program?

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

OK. - so the solution as I have it is in the right direction...  (bar  
removing the extra static lib).

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

-static-libgcc works on darwin.
it's accommodated by different libnames.
I don't know if that change extends to other triplets - at present I  
only have OSX machines to hand.

> Cheers,
> Ralf

thanks for your responses,
Iain