> I notice in the problem link line, the shared libdefobj.4.dylib is > linked to ../../avcall/.libs/libavcall.a twice.
Quite so, but it is libtool versions 1.4.2 or the current cvs that does it. Libtool 1.4.3 does not put avcall on the command line twice and produces functional libraries. Following is a transcript with libtool 1.4.3 which you can compare with the failure for the current version: /bin/sh ../../libtool --mode=link /Users/billn/Public/GNU/dst/bin/gcc -g -O2 -fgnu-runtime -fno-strict-aliasing -Wall -Wno-import -Wno-protocol -Wno-long-long -Wno-unknown-pragmas -Wno-unknown-pragmas -o libdefobj.la -rpath /Users/billn/Public/Swarm/swarm/macosx/swarmx/build/dst/usr/lib -version-info 4:0:0 Archiver.lo LispArchiver.lo HDF5Archiver.lo Arguments.lo Create.lo Customize.lo DefClass.lo DefObject.lo HDF5Object.lo Program.lo Symbol.lo Zone.lo FCall.lo FArguments.lo defobj.lo internal.lo java.lo directory.lo JavaProxy.lo JavaClassProxy.lo JavaCollection.lo JavaCollectionIndex.lo COMProxy.lo fcall_objc.lo fcall_java.lo COM.lo modulemap.lo ../../avcall/libavcall.la mkdir .libs rm -fr .libs/libdefobj.la .libs/libdefobj.* .libs/libdefobj.* (cd . && ln -s Archiver.lo Archiver.o) <...a lot of lines like this removed...> (cd . && ln -s fcall_java.lo fcall_java.o) (cd . && ln -s COM.lo COM.o) (cd . && ln -s modulemap.lo modulemap.o) /Users/billn/Public/GNU/dst/bin/gcc -dynamiclib -flat_namespace -undefined suppress -o .libs/libdefobj.4.0.0.dylib Archiver.lo LispArchiver.lo HDF5Archiver.lo Arguments.lo Create.lo Customize.lo DefClass.lo DefObject.lo HDF5Object.lo Program.lo Symbol.lo Zone.lo FCall.lo FArguments.lo defobj.lo internal.lo java.lo directory.lo JavaProxy.lo JavaClassProxy.lo JavaCollection.lo JavaCollectionIndex.lo COMProxy.lo fcall_objc.lo fcall_java.lo COM.lo modulemap.lo -all_load ../../avcall/.libs/libavcall.al -lc -install_name /Users/billn/Public/Swarm/swarm/macosx/swarmx/build/dst/usr/lib/libdefobj.4.dylib -compatibility_version 5 -current_version 5.0 The only difference between the source tree that fails and the one that builds is the version of ltmain.sh. 1.4.3 works the others don't. > Aside from the obvious problem of linking a shared library > to a static archive, which is not portable, I think this > is the source of your problem. I may be being dense, but I thought the point of libtool was to do things differently on different platforms. The code concerned builds happily on a wide range of other UNIXen (Solaris, Linux x86 and PPC, Tru64, AIX etc..) and Cygwin. My real concern was the apparent regression from 1.4.3 to the current libtool code. >Can you tell us what happens > in Libtool that causes this? i.e. run the same command with > "/bin/sh -x ../../libtool" and pipe the output to a file. I will try to do this for both cases and send you the files. I will include another point in the source code where all versions of libtool fail to link. Bill Northcott _______________________________________________ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
