-soname passed directly to the compiler
A package we're converting to the autotools is having an issue building
a library; it seems to think gcc supports a -soname option.
/bin/sh ../libtool --tag=CC --mode=link mpicc -I/home/tfogal/sw/include
-L/home/tfogal/sw/lib -o libH5Part.la -rpath
/home/tfogal/dev/install-h5part/lib H5Part.lo H5PartAttrib.lo H5Block.lo
H5BlockReadWrite.lo H5MultiBlock.lo H5MultiBlockReadWrite.lo -lhdf5
mpicc -shared .libs/H5Part.o .libs/H5PartAttrib.o .libs/H5Block.o
.libs/H5BlockReadWrite.o .libs/H5MultiBlock.o .libs/H5MultiBlockReadWrite.o
-L/home/tfogal/sw/lib /home/tfogal/shigeru/lib/libhdf5.a -lc -soname
libH5Part.so.0 -o .libs/libH5Part.so.0.0.0
gcc: libH5Part.so.0: No such file or directory
gcc: unrecognized option '-soname'
I do not think I am doing anything all that special:
lib_LTLIBRARIES = libH5Part.la
libH5Part_la_SOURCES = H5Part.c \
H5PartAttrib.c \
H5Block.c \
H5BlockReadWrite.c \
H5MultiBlock.c \
H5MultiBlockReadWrite.c
I tried adding -version-info in hopes it would avoid the soname
problems, to no avail. Attached is the gzip'd output of the libtool
invocation, with --debug. I also attached the full Makefile.am.
It seems like we should get a -Wl, in front of that -soname, but we are
not. What am I doing wrong?
-tom
ltmain.sh (GNU libtool) 1.5.26 Debian 1.5.26-4+lenny1 (1.1220.2.493 2008/02/01
16:58:18)
automake (GNU automake) 1.10.1
autoconf (GNU Autoconf) 2.63
�jJXM~����+ %�*��:�hԽA8�f�����7*�F���Ũ� �9XC�
5��(��b�G��+�2.�:�WX
���Oew��U5��{+o1��\C�]���'b5��8���V�$��q/��;V@ܸ�� �i �,'���
��쀙IbphZ� {I���O�{��㹽
!V:�}0���J$��Ge���\$��,#�9
�0�����?W%���(x���a��HI^���o�R˻
gSF�/�EY����46Ҫ��Y��fJX�����8a�g�1�k� +�ƴy�b��P$\°�{ ��fBrۡ
b*��Ҫ!=+�D�H@�����m\ʫ%.� �xԍU�a��n|���?'��$1�� ڔ�
��kf� ��Ϡs2�ڔ��T��4�x����-1�qo{A*@z3�v�Ev�FC�p���(�O �
ׅza�N}w��^��@]�m��V�w�p?�(gOud�3\�c��
�F�?N m��G���l���CN6\�d7��x���p��|����w�V���̫�큜� *� ���v'�i� �iK�-Ч��
�S�9�'�vc��kt�fN#�u���ٺ��)I��|221+wc�`��,�v�\6G6�Y �9o1]o�B �Y�]��nQ˥� ���I*�c���U���9ף�.��k�E��=Z�$�L_a t��l
05 +O.C �u����#�t�nC ��t��aH�L�;��Oq�У��FƎmP���s���0�+-j�v���rBDw�9�ūI�K�`P�IX�KH���#�g�I�DO0���J1�퐭�؈-Z�
��w=6lzt6/!sҢ�a=dJ-��CR�y���Y�ܬ�d���c�-�n �s�1u�'��3� �j�˽��O秀��
8���|�bܘ�A���+Q��f���O��@+�5���ՄV�D�� �Y� ��
F��(�� 0N��Sd7�!�iz��@�6�'��J{?)ǧ@3Ԁ���[t�V��!ʎ�G�䇿}��Ǫ�ͷ�)�[�Y���v��2M
�AC�O �����bK �ˢ��ik���-���� �'-^�C�b�|\�â
x%�]I;��
�ђy����Dم�� �yA0�)�-���Ya�z�VY]�@[���X�D@�]!���� �a
kx�\�t�Ŏ���4ݱڧ�ed�xL�(P��TxC+G��ZjQ�cq3ܺ�5�5ç���d{�k��F?��P��j�d]���.�Fw���7��L����J=�Vh�a���^�zس
�`ڴ[`c������.Z$��~��C��ᙶ/D ��4ɆL�(��];��Y�W:� �7ʜ��ma�-
p�[ɲw7;cqC�u'T�G�5^-
�j,�;c*��E,UwH�+k,CG-����H�3��f`�DR�(Cx��,�K���k���
�9����\_؞B P����e�сӌ�oъ-�l�
�Z�Ek��~mk@�^���6���g��cG�� �w.B�$���qbG���ai=�i��������۴��n��j��Eњ�?�`|?���P�Re�:����+v��@���`���$�60R�2�����z �+��H��*= r����B�:y�vp��Fz� 7lS t3�3�_�a35�}���q`�E��6l�%���
�lPz8�6
$��q��p�~�����A7# src level Makefile.am
#OBJEXT=o
INCLUDES = -I@HDF5ROOT@/include @MPIINC@
EXTRA_HEADERS = H5PartPrivate.h \
H5BlockPrivate.h \
H5MultiBlockPrivate.h \
H5PartAttrib.h
# Extra files that I wish to include in the dist tar ball.
EXTRA_DIST =TestUnderscoreC.c \
TestUnderscore.f \
generate-attr.py \
generate-h5bl-readwrite.py \
generate-h5multi-readwrite.py \
H5Part.f90 \
H5PartAttrib.f90 \
H5Block.f90 \
H5BlockReadWrite.f90 \
$(EXTRA_HEADERS)
# Files that I don't want to include in the dist tar ball
nodist_include_HEADERS = H5PartF.h @UNDERSCORE_H@
# What to build... Will be determined by configure script.
lib_LTLIBRARIES = libH5Part.la
# Listing of all possible targets that I may build.
#EXTRA_LTLIBRARIES = libH5Part.la libH5PartF.la
# Header files that I wish to install in $(prefix)/include
include_HEADERS = H5Part.h \
H5PartTypes.h \
H5PartErrors.h \
H5PartAttrib.h \
H5Block.h \
H5BlockTypes.h \
H5BlockErrors.h \
H5BlockReadWrite.h \
H5MultiBlock.h \
H5MultiBlockTypes.h \
H5MultiBlockErrors.h \
H5MultiBlockReadWrite.h \
H5PartF.h \
doc: clarification of convenience archi and --preserve-dup-deps
Attached is a patch to make the concept of a convenience archive and
the --preserve-dup-deps option clearer, after much discussion with
Ralf.
This is against HEAD.
Please CC me on replies, I am not subscribed.
-tom
Index: ChangeLog
===
RCS file: /cvsroot/libtool/libtool/ChangeLog,v
retrieving revision 1.2028
diff -u -r1.2028 ChangeLog
--- ChangeLog 23 Aug 2005 16:04:24 - 1.2028
+++ ChangeLog 24 Aug 2005 02:53:23 -
@@ -1,3 +1,14 @@
+ ChangeLog
+2005-08-23 Tom Fogal [EMAIL PROTECTED]
+Ralf Wildenhues [EMAIL PROTECTED]
+
+ * doc/libtool.texi (Linking Static Libraries): Convenience archives
+ are similar to GNU ld's --whole-archive option.
+ (Invoking libtool): Option --preserve-dup-deps must come before CC.
+
+ * TODO: CC, --preserve-dup-deps ordering should not matter.
+
+===
2005-08-23 Stepan Kasal [EMAIL PROTECTED],
Ralf Wildenhues [EMAIL PROTECTED]
@@ -146,6 +157,7 @@
* m4/ltdl.m4 (LTDL_INIT): Fix mismatched parens.
+ 1.2028
2005-08-13 Ralf Wildenhues [EMAIL PROTECTED]
* tests/inherited_flags.at: Store intermediate libtool output
Index: TODO
===
RCS file: /cvsroot/libtool/libtool/TODO,v
retrieving revision 1.69
diff -u -r1.69 TODO
--- TODO18 Aug 2005 09:51:57 - 1.69
+++ TODO24 Aug 2005 02:53:23 -
@@ -76,6 +76,11 @@
* Look at better -no-undefined support, maybe along the idea of
[support #103719] for CC.
+* Remove the limitation that --preserve-dup-deps appear before CC in the
+ libtool command line.
+ The documentation currently mentions this limitation under @chapter Invoking
+ @command{libtool}, and will therefore need to be updated as well.
+
1.2. libtldl
Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.196
diff -u -r1.196 libtool.texi
--- doc/libtool.texi22 Aug 2005 11:12:26 - 1.196
+++ doc/libtool.texi24 Aug 2005 02:53:26 -
@@ -1050,6 +1050,34 @@
objects, and link against that with the other libraries, instead of
listing all the object files every time.
+When another libtool-created archive is linked to a convenience library, all
+objects from the convenience library are linked into the newly created
+archive. This is different from a traditional static library, which only
+includes the objects required to resolve the current set of undefined
+references. Due to this behavior, we can use a convenience archive or
+archives to create any other type of library (static, shared, or another
+convenience archive). This allows us to create a single convenience archive
+that is the union of multiple convenience archives.
+
[EMAIL PROTECTED]
+host$ @kbd{libtool --mode=link $CC $CFLAGS $LDFLAGS -o lib123.la \
+ subdirA/lib1.la subdirB/lib2.la subdirC/lib3.la}
[EMAIL PROTECTED] example
+
+This provides a logical and portable way of linking a project that includes
+several different modules, stored in different subdirectories. Each
+subdirectory can create a libtool convenience archive, and then one archive
+can be created that has all the symbols from each of the different modules,
+by a command similar to the above. Finally the application can be linked
+against the new all-encompassing convenience archive.
+
[EMAIL PROTECTED] convenience archives are similar in concept to the
[EMAIL PROTECTED] @command{ld} option, @option{--whole-archive}. The subtle
+difference is that libtool will bring together all of the objects at
+the time the convience archive is linked, whereas @command{ld}
[EMAIL PROTECTED] would bring together the objects when the
+output object is linked.
+
If you just want to link this convenience library into programs, then
you could just ignore libtool entirely, and use the old @command{ar} and
@command{ranlib} commands (or the corresponding @sc{gnu} Automake
@@ -1191,7 +1219,8 @@
situations, where -la -lb -la is required, and the second -la may not be
stripped or the link will fail. In cases where these duplications are
required, this option will preserve them, only stripping the libraries
-that libtool knows it can safely.
+that libtool knows it can safely. Please be aware that in current versions
+of libtool, this option must appear before @option{$CC} to be effective.
@item --quiet
@itemx --silent
Documentation patch
Alright, I'm very new at this so feel free to berate me mention if I
did something wrong here.
Attached is a short doc patch that (I think) provides better
information on how convenience libraries work, and mentions that the
ordering is important to --preserve-dup-deps. For the latter, I've
mentioned that the limitation will eventually be removed, although I've
given no timescale for this.
Maybe it would be appropriate to patch TODO as well... ?
-tom
? doc.patch
Index: doc/libtool.texi
===
RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v
retrieving revision 1.193
diff -r1.193 libtool.texi
1052a1053,1075
When another libtool-created archive is linked to a convenience library, all
objects from the convenience library are linked into the newly created
archive. This is different from a traditional static library, which only
includes the objects required to resolve the current set of undefined
references. Due to this behavior, we can create one convenience library that
is the union of a set of convenience libraries.
@example
host$ @kbd{libtool --mode=link $CC $CFLAGS $LDFLAGS -o lib123.la \
subdirA/lib1.la subdirB/lib2.la subdirC/lib3.la}
@end example
This provides a logical and portable way of linking a project that includes
several different modules, stored in different subdirectories. Each
subdirectory can create a libtool convenience archive, and then one archive
can be created that has all the symbols from each of the different modules,
by a command similar to the above. Finally the application can be linked
against the new all-encompassing convenience archive.
For those familiar with @sc{gnu} @command{ld}, convenience archives can be
thought of as an abstracted, portable implementation of
@option{--whole-archive}.
1194c1217,1219
that libtool knows it can safely.
---
that libtool knows it can safely. Please be aware that in current versions
of libtool, this option must appear before @option{$CC} to be effective.
This limitation will be removed in future versions of libtool.
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: how to use circular dependencies
[EMAIL PROTECTED]Ralf Wildenhues writes:
Hi Tom,
* tom fogal wrote on Wed, Aug 10, 2005 at 09:52:07PM CEST:
Ralf Wildenhues writes:
snip
This is a \emph{lot} clearer after looking up what --whole-archive does.
Thank you. I think the --whole-archive reference would be a good thing
to mention in the documentation. Maybe thats just my $0.02 though...
Ah, ok. Would you be willing to update the documentation to this end?
(Be sure to work on the CVS HEAD or branch-2-0 copy of libtool.texi, if
you do.)
Sure. Probably next week, though.
snip
Its been too long for my little brain to remember clearly, but I
vaguely remember having that slash there and seeing an extra / during
builds. The build didn't seem to care about it, but it was
aesthetically displeasing to me...
*snip*
With the below as part of a Makefile.am:
### /src/develop/Makefile.am snippet ###
partrj_LDADD= \
../ui/libParTrjUI.a \
../grid/libSPPgrid.a \
../models/libSPPModels.a \
../share/libShare.a \
../fields/libSPPFields.a \
../menus/libParTrjMenu.a \
@[EMAIL PROTECTED]/strings/src/libSPPStrings.a \
You meant to write this here, right?
| @top_builddir@/srcs/strings/src/libSPPStrings.a \
Oops. Yes. I had originally done a copy and paste, but then when I got
to the second one I realized that the directory is srcs not src.
Stupidly I fixed it in the Makefile.am and then tried to do a manual
edit here in the email. Bad idea.
To clarify:
@top_builddir@/srcs/strings/src/libSPPStrings.a \
gives
../..//srcs/strings/src/libSPPStrings.a
on the link line, and
@[EMAIL PROTECTED]/strings/src/libSPPStrings.a \
gives
../../srcs/strings/src/libSPPStrings.a
... and I swear those are copy-and-pasted, undefiled by my editor this
time =)
This is an autoconf + automake + libtool project, so its fully possible
I'm screwing things up in a configure.in or something. 'grep' tells me
I'm not doing anything totally braindead though, like overwriting it.
Let's see the following:
- the exact configure line you issued (copy and paste!)
./configure FFLAGS=-g -Wall -O0 --enable-static --disable-shared
Yes, this is fortran... :|
- egrep 'top_(src|build)dir.=' Makefile
In the toplevel Makefile:
[EMAIL PROTECTED] ~/tmp/F77_Projects $ egrep 'top_(src|build)dir.='
Makefile
top_srcdir = .
top_builddir = .
In srcs/develop/Makefile, where partrj_LDADD is and where I got the
Makefile.am snippets from before:
[EMAIL PROTECTED] ~/tmp/F77_Projects/srcs/develop $ egrep
'top_(src|build)dir.=' Makefile
top_srcdir = ../..
top_builddir = ../..
Do you modify any of the directory variables mentioned in
info 'Preset Output Variables'
in your configure script?
I'm not very familiar with info, but at the top right after that
command I see This is the top of the INFO tree, leading me to believe
I'm not looking at what you expected me to look at.
I eventually found what I \emph{think} you wanted me to look at, in
autoconf's infodoc. The first variable it mentions is CFLAGS, then
configure_input, then CPPFLAGS, etc.
Anyway I do not modify anything given in that list. Among things that
might be 'weird', I do have the following in my configure.in:
AM_FFLAGS=-Wall -I../include/ -pedantic-errors -fno-f90
-fno-automatic\
-finit-local-zero -fugly-complex -fugly-init -Wno-globals
AC_SUBST([AM_FFLAGS])
snip
Thanks a lot! It can be fixed without changing libtool, see below.
Oh. awesome =)
It includes a 'makefile' and a 'makefile.working'. The former uses
libtool and fails to link because libtool strips off a couple of
libraries. The latter works fine, although it lists some libraries
multiple times.
Its basically three directories (liba, libb, libc...) that are built
into static libraries. liba needs a symbol from libc, libb needs
symbols from both liba and libc, and libc needs symbols from both liba
and libb.
First, naming a test library libc is, umm, interesting (as would be
libm, libl, liby, all of which you should avoid on POSIX systems unless
you provide their functionality, also libC -- often the C++ standard lib).
This prevents using -Lpath/to/libc -lc, for example.
Yeah, I was somewhat uncomfortable with the name but it seemed to serve
for the demonstrative purposes I was going for, on my platform. Don't
worry, I haven't used this name in a 'real' project =)
Second, the flag --preserve-dup-deps is used wrongly: Unfortunately, it
needs to go before $CC. We should look into removing this limitation.
Interesting. I was unaware of this restriction.
Perhaps I could mention this in the forthcoming doc patch, in section
4, Invoking libtool ?
Now, there are a couple of ways to solve your problem IMHO, but they
depend on what you actually want. This is the crux of the matter: it's
not clear.
In your example, you create a bunch of convenience archives which have
mutual (or circular, FWIW) dependencies. We don't get to see whether
you want
Re: how to use circular dependencies
[EMAIL PROTECTED]Ralf Wildenhues writes: Hi Tom, Sorry for the high response latency. I saw your post on the automake Oh, no worries. list. From your response below (you stated that you did not need libtool after all), I gathered that this bug report is not so urgent resp. that without using libtool things would work for you. More below. Well yes and no =). The post I made on the this list a little while back was for a work project, and I eventually found I didn't really need libtool and worked around it that way. Now I'm trying with a different, personal project that happens to have circular dependencies too, but theres no way I can avoid circular dependencies here =) * tom fogal wrote on Mon, Jul 11, 2005 at 10:24:34PM CEST: [EMAIL PROTECTED]Ralf Wildenhues writes: * tom fogal wrote on Fri, Jul 08, 2005 at 08:14:51PM CEST: Hi all, I'm trying to get libtool to link a program that depends on a circular list of static (libtool) libraries. I'm using a command line like: *snip* unfortunately this ends up not working because libtool is removing/reordering some of the libraries: I presume this is because the libraries have interdependencies listed in the respective .la files. erm.. hopefully? This is all an autoconf/automake generated thing; it appears I was doing what are called 'libtool convenience libraries'. I simply pulled out + posted the line that caused problems. OK. snip - how one of the libraries is linked (they are all similar) I don't understand exactly what you mean by this. Do you have circular dependencies in shared libraries, in static libraries, or in convenience libraries (or a combination of these)? If I understand what a convenience library is correctly (static library that doesnt get installed), then both these projects are/were stuck with circular dependencies in convenience libraries only. The line I just gave above is from me changing one of the Makefile.ams to use libtool again. The relevant Makefile.am snippets are: # old way -- using libtool noinst_LTLIBRARIES=libSPPdbg.la libSPPdbg_la_SOURCES= \ dbg_basics.f \ *snip* [EMAIL PROTECTED]@lib/libSPPstrings.la ^^ I believe there is a slash (/) missing here. Its been too long for my little brain to remember clearly, but I vaguely remember having that slash there and seeing an extra / during builds. The build didn't seem to care about it, but it was aesthetically displeasing to me... Anyway let me verify that before you quote me on it =) The new way is the same but s/LTLIBRARIES/LIBRARIES/ and s/la/a/. All the libaries are (were) built in this same manner. *snip* snip Well if theres more I can do to help in building a test case, just let me know / ask. It would save us some work if you could create a small/minimal test case project which exhibits your failure. I can't guarantee a quick fix though, I haven't delved into the deplibs code for a while and it's quite intricate. Okay. Would it suffice if I made a minimal project that demonstrates the behavior? I'm not sure I completely understand the libtool tests, but it seems there is a series of sub-projects that are run by shell scripts in the tests/ directory... Thanks for all your help! -tom ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: how to use circular dependencies
I have devised a test for this. More near the bottom, in the
appropriate context.
[EMAIL PROTECTED]Ralf Wildenhues writes:
Hi Tom,
* tom fogal wrote on Wed, Aug 10, 2005 at 04:58:50PM CEST:
[EMAIL PROTECTED]Ralf Wildenhues writes:
list. From your response below (you stated that you did not need
libtool after all), I gathered that this bug report is not so urgent
resp. that without using libtool things would work for you. More below.
Well yes and no =). The post I made on the this list a little while
back was for a work project, and I eventually found I didn't really
need libtool and worked around it that way. Now I'm trying with a
different, personal project that happens to have circular dependencies
too, but theres no way I can avoid circular dependencies here =)
Ah, ok.
Actually, this shouldve read personal project that happens to have
circular dependencies too, but theres no way I can avoid libtool, but
you seem to have picked up what I meant and not what I said, anyway =)
* tom fogal wrote on Mon, Jul 11, 2005 at 10:24:34PM CEST:
[EMAIL PROTECTED]Ralf Wildenhues writes:
* tom fogal wrote on Fri, Jul 08, 2005 at 08:14:51PM CEST:
I don't understand exactly what you mean by this.
Do you have circular dependencies in shared libraries, in static
libraries, or in convenience libraries (or a combination of these)?
If I understand what a convenience library is correctly (static library
that doesnt get installed), then both these projects are/were stuck
with circular dependencies in convenience libraries only.
Convenience libraries are just collections of objects in an archive.
When another libtool-created library is linked against the archive, it
will be added as a whole, i.e., each object in the convenience lib will
be present in the output library (like the GNU ld --whole-archive
option). When a program is linked against it, it will behave just as if
you link against a plain old archive -- each used symbol will be linked
in.
Does this make matters clear?
This is a \emph{lot} clearer after looking up what --whole-archive does.
Thank you. I think the --whole-archive reference would be a good thing
to mention in the documentation. Maybe thats just my $0.02 though...
[EMAIL PROTECTED]@lib/libSPPstrings.la
^^
I believe there is a slash (/) missing here.
Its been too long for my little brain to remember clearly, but I
vaguely remember having that slash there and seeing an extra / during
builds. The build didn't seem to care about it, but it was
aesthetically displeasing to me...
Anyway let me verify that before you quote me on it =)
If you can let us reproduce it, we can either fix it or point out the
mis-use. :)
With the below as part of a Makefile.am:
### /src/develop/Makefile.am snippet ###
partrj_LDADD= \
../ui/libParTrjUI.a \
../grid/libSPPgrid.a \
../models/libSPPModels.a \
../share/libShare.a \
../fields/libSPPFields.a \
../menus/libParTrjMenu.a \
@[EMAIL PROTECTED]/strings/src/libSPPStrings.a \
../hash/libHash.a \
../dbg/libSPPdbg.la \
../t89files/libSPPt89.a \
../models/libSPPModels.a
### /src/develop/Makefile.am snippet ###
I get the following build output:
### '$ make' output snippet
Making all in develop
make[3]: Entering directory
`/home/tfogal/tmp/F77_Projects/srcs/develop'
/bin/sh ../../libtool --mode=link g77 -Wall -I../include/
snip -- bunch of object files + compiler options
write_rkt.o write_rvt.o xyzstart.o ../ui/libParTrjUI.a
../grid/libSPPgrid.a ../models/libSPPModels.a ../share/libShare.a
../fields/libSPPFields.a ../menus/libParTrjMenu.a
\/\/
../..//srcs/strings/src/libSPPStrings.a ../hash/libHash.a
^^^
../dbg/libSPPdbg.la ../t89files/libSPPt89.a ../models/libSPPModels.a
### '$ make' output snippet
emphasis lines added.
If I get rid of the '/' after the '@', making the Makefile.am line
read:
@[EMAIL PROTECTED]/strings/src/libSPPStrings.a \
I get:
### '$ make' output with no trailing / ###
Making all in develop
make[3]: Entering directory
`/home/tfogal/tmp/F77_Projects/srcs/develop'
/bin/sh ../../libtool --mode=link g77 -Wall -I../include/
snip -- bunch of object files + compiler options
write_rkt.o write_rvt.o xyzstart.o ../ui/libParTrjUI.a
../grid/libSPPgrid.a ../models/libSPPModels.a ../share/libShare.a
../fields/libSPPFields.a ../menus/libParTrjMenu.a
\/\/
../../srcs/strings/src/libSPPStrings.a ../hash/libHash.a
^^^
../dbg/libSPPdbg.la ../t89files/libSPPt89.a ../models/libSPPModels.a
### '$ make' output with no trailing / ###
again, emphasis lines added.
This is an autoconf + automake + libtool project, so its fully possible
I'm screwing things up in a configure.in or something. 'grep' tells me
I'm not doing anything totally braindead though, like overwriting it.
In any case, the result is the same with or without the extra slash.
Well if theres more I can
Re: how to use circular dependencies
[EMAIL PROTECTED]Ralf Wildenhues writes: Hi Tom, * tom fogal wrote on Fri, Jul 08, 2005 at 08:14:51PM CEST: Hi all, I'm trying to get libtool to link a program that depends on a circular list of static (libtool) libraries. I'm using a command line like: ../../libtool --mode=link --preserve-dup-deps g77 -Wall -I../include -O0 -o partrj -static *.o ../ui/libParTrjUI.la ../models/libSPPModels.la ../share/libSPPShare.la ../models/libSPPModels.la ../grid/libSPPgrid.la ../fields/libSPPFields.la ../share/libSPPShare.la ../menus/libParTrjMenu.la ../strings/src/libSPPStrings.la ../hash/libHash.la ../dbg/libSPPdbg.la ../t89files/libSPPt89.la unfortunately this ends up not working because libtool is removing/reordering some of the libraries: I presume this is because the libraries have interdependencies listed in the respective .la files. erm.. hopefully? This is all an autoconf/automake generated thing; it appears I was doing what are called 'libtool convenience libraries'. I simply pulled out + posted the line that caused problems. g77 -Wall -I../include -O0 -o partrj bunch of .o files ../ui/.libs/libParTrjUI.a ../models/.libs/libSPPModels.a ../grid/.libs/libSPPgrid.a ../fields/.libs/libSPPFields.a ../share/.libs/libSPPShare.a ../menus/.libs/libParTrjMenu.a ../strings/src/.libs/libSPPStrings.a ../hash/.libs/libHash.a ../dbg/.libs/libSPPdbg.a ../t89files/.libs/libSPPt89.a --preserve-dup-deps doesn't seem to have an effect. I also tried remaking the command line using -L and -l options instead of explicitly specifying the .la file, with the same effect of libtool stripping out libraries from the link line. Hmm. Is the package that contains these libraries freely available online? If not: could you show the corresponding link lines for the unfortunately, no. libraries? (Either the Makefile.am snippets, or whatever `make' makes of it as libtool command line; plus libtool's output.) Sure. /bin/sh ../../libtool --mode=link g77 -Wall -I../include/ -pedantic-errors -fno-f90 -fno-automatic -finit-local-zero -fugly-complex -fugly-init -Wno-globals -g -O2 -o libSPPdbg.la dbg_basics.lo dbg_bevals.lo dbg_constants.lo dbg_harpol.lo dbg_interp.lo dbg_position.lo dbg_ivector.lo dbg_vector.lo dbg_vlstrn.lo ar cru .libs/libSPPdbg.a .libs/dbg_basics.o .libs/dbg_bevals.o .libs/dbg_constants.o .libs/dbg_harpol.o .libs/dbg_interp.o .libs/dbg_position.o .libs/dbg_ivector.o .libs/dbg_vector.o .libs/dbg_vlstrn.o ranlib .libs/libSPPdbg.a creating libSPPdbg.la (cd .libs rm -f libSPPdbg.la ln -s ../libSPPdbg.la libSPPdbg.la) You'll notice that the above has slightly different flags than what you would guess based on earlier lines I've included. Since I reported this, I've determined we don't really /need/ libtool at all, so I removed it from the project. After that I heard the project was missing some flags that should be there, from the source code author, so I've added them in. The line I just gave above is from me changing one of the Makefile.ams to use libtool again. The relevant Makefile.am snippets are: # old way -- using libtool noinst_LTLIBRARIES=libSPPdbg.la libSPPdbg_la_SOURCES= \ dbg_basics.f \ dbg_bevals.f \ dbg_constants.f \ dbg_harpol.f \ dbg_interp.f \ dbg_position.f \ dbg_ivector.f \ dbg_vector.f \ dbg_vlstrn.f [EMAIL PROTECTED]@lib/libSPPstrings.la The new way is the same but s/LTLIBRARIES/LIBRARIES/ and s/la/a/. All the libaries are (were) built in this same manner. I found a post on libtool-patches from 2002, where someone else had run into this issue. They expected linker flags of -Wl,-( libs -Wl,-) to fix it. I changed my link line above to use these linker flags in the libtool command line, but I still get the same error. It appears as if the patch was never applied (why?)? Are you talking about this? http://lists.gnu.org/archive/html/libtool-patches/2002-09/msg7.html Ooops, sorry! I had thought I included the link; mea culpa. Thanks for doing the research again for me =) I can only guess it was not applied because it's a hack.. =( I am using libtool version '1.5.18 (1.1220.2.246 2005/05/16 10:00:18'. What am I doing wrong? How can one link in circular dependencies using libtool? Oh, most likely they are broken, but to be honest, I have no idea. We don't have a proper test for them, so we can't expect them to stay unbroken. The reason I have asked for details above is that we may be able to generate a decent test case from your situation, and then work from that. Well if theres more I can do to help in building a test case, just let me know / ask. -tom ___ http://lists.gnu.org/mailman/listinfo/libtool
how to use circular dependencies
Hi all, I'm trying to get libtool to link a program that depends on a circular list of static (libtool) libraries. I'm using a command line like: ../../libtool --mode=link --preserve-dup-deps g77 -Wall -I../include -O0 -o partrj -static *.o ../ui/libParTrjUI.la ../models/libSPPModels.la ../share/libSPPShare.la ../models/libSPPModels.la ../grid/libSPPgrid.la ../fields/libSPPFields.la ../share/libSPPShare.la ../menus/libParTrjMenu.la ../strings/src/libSPPStrings.la ../hash/libHash.la ../dbg/libSPPdbg.la ../t89files/libSPPt89.la unfortunately this ends up not working because libtool is removing/reordering some of the libraries: g77 -Wall -I../include -O0 -o partrj bunch of .o files ../ui/.libs/libParTrjUI.a ../models/.libs/libSPPModels.a ../grid/.libs/libSPPgrid.a ../fields/.libs/libSPPFields.a ../share/.libs/libSPPShare.a ../menus/.libs/libParTrjMenu.a ../strings/src/.libs/libSPPStrings.a ../hash/.libs/libHash.a ../dbg/.libs/libSPPdbg.a ../t89files/.libs/libSPPt89.a --preserve-dup-deps doesn't seem to have an effect. I also tried remaking the command line using -L and -l options instead of explicitly specifying the .la file, with the same effect of libtool stripping out libraries from the link line. I found a post on libtool-patches from 2002, where someone else had run into this issue. They expected linker flags of -Wl,-( libs -Wl,-) to fix it. I changed my link line above to use these linker flags in the libtool command line, but I still get the same error. It appears as if the patch was never applied (why?)? I am using libtool version '1.5.18 (1.1220.2.246 2005/05/16 10:00:18'. What am I doing wrong? How can one link in circular dependencies using libtool? Thanks, -tom ___ http://lists.gnu.org/mailman/listinfo/libtool
