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 <[EMAIL PROTECTED]>
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
