Re: libtool 1.5.8 on Solaris 8
Hi Bob, On Fri, 2004-08-27 at 17:53, Bob Friesenhahn wrote: I am glad to see that you responded to this since you were the one who made multi-lingual libtool possible. Thank you very much. Thanks! It seems to me that if the C++ compiler is used to link, then C++ exceptions will work. That's what I thought at the time, too, and still think so. However, I'm sure there was a reason why we did things this way. I unfortunately don't recall the details. If the system linker is used, then it is possible that C++ exceptions will not work at all, even if the extra libraries are applied. I missed part of the thread. Is the system linker being using instead of the compiler? I thought that we were using the compiler in all cases, and that we were manually prepending and appending start files and libraries. Is that not the case, i.e. are we using the linker? -Ossama ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.5 1.4.3
Hi Robert, On Wed, Oct 09, 2002 at 02:57:39PM -0500, Robert Boehne wrote: I intend to spin a release 1.4.3 this weekend from the branch-1-4 sources. Any properly formatted patches will be considered for inclusion before the release. I have seen a tendency to post patches on any list in any format, which makes it more work to get that particular patch installed in CVS. As of late, Gary and I have precious little of that! Perhaps it might be useful to refresh everyone's memory about the Libtool contribution guidelines available on the Libtool web site here: http://www.gnu.org/software/libtool/contribute.html -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Shared C++ libraries on AIX
Hi,
On Mon, Oct 07, 2002 at 07:01:04PM +0200, Martin Frydl wrote:
progname=`$echo $0 | ${SED} 's%^.*/%%'`
The problem is with SED variable, it is not defined anywhere in libtool
script. I think the CVS version is currently unstable.
Did you run aclocal in your package to pull in the latest libtool M4
macros? Some of libtool's functionality is now at done at
`configure'-time, meaning that you have to pull in the latest libtool
M4 macros.
HTH,
-Ossama
--
Ossama Othman [EMAIL PROTECTED]
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
libtool assumes all ARM distributions use glibc 2.1.1
Hi, libtool.m4 (both head and 1.4 branch) has the following: # This must be Linux ELF. linux-gnu*) case $host_cpu in alpha* | hppa* | i*86 | powerpc* | sparc* | ia64* ) lt_cv_deplibs_check_method=pass_all ;; *) # glibc up to 2.1.1 does not perform some relocations on ARM lt_cv_deplibs_check_method='file_magic ELF [[0-9]][[0-9]]*-bit [[LM]]SB (shared object|dynamic lib )' ;; esac lt_cv_file_magic_test_file=`echo /lib/libc.so* /lib/libc-*.so` ;; This incorrectly assumes that all ARM builds use glibc 2.1.1, which is no longer true for recent Linux distributions. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool doesn't allow make DESTDIR=`pwd`/foo install anymore.
Hi, On Tue, Nov 27, 2001 at 10:38:37AM -0600, Paul E Johnson wrote: I do now know what patch is required to make libtool-1.4.2 work as it is currently released, I've been asking about. My understanding is that the Debian packager of libtool has a patch which fixes the problem. Yep, I applied Mo Dejong's patch. However, I'll resynch with the libtool-1-4 patch just in case. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[egagnon@j-meg.com: Bug#97759: libtool: build problem]
Hi guys, Bug report for libtool 1.4 from a Debian user. Any ideas? -Ossama - Forwarded message from Etienne M. Gagnon [EMAIL PROTECTED] - Subject: Bug#97759: libtool: build problem Reply-To: Etienne M. Gagnon [EMAIL PROTECTED], [EMAIL PROTECTED] Resent-From: Etienne M. Gagnon [EMAIL PROTECTED] Orignal-Sender: egagnon Resent-To: [EMAIL PROTECTED] Resent-CC: Ossama Othman [EMAIL PROTECTED] Resent-Date: Thu, 17 May 2001 06:03:45 GMT Resent-Message-ID: [EMAIL PROTECTED] Resent-Sender: [EMAIL PROTECTED] X-Debian-PR-Message: report 97759 X-Debian-PR-Package: libtool X-Debian-PR-Keywords: X-Loop: [EMAIL PROTECTED] Date: Thu, 17 May 2001 00:49:20 -0400 From: Etienne M. Gagnon [EMAIL PROTECTED] Organization: J-Meg inc. X-Mailer: Mozilla 4.7 [en] (X11; U; Linux 2.2.18 i586) X-Accept-Language: en To: [EMAIL PROTECTED] Delivered-To: [EMAIL PROTECTED] Hi again, Sorry, bug seems to be buggy. My message was cut in the middle. Here it is, again Package: libtool Version: 1.4-1 Severity: important Hi, Here's a new problem that appeared since the upgrade to libtool 1.4. I am also using a locally compiled automake 1.4-p1 (see bug #97690 for the reason I'm not using unstable's automake). Here is what I get when I compile a project (sablevm). The Makefile.am contains: libsablevm_la_LIBADD = -lffi -lpthread -lm -ldl Of these 4 libraries, 3 are static, but libffi is dynamic. Notice how the gcc command fails because it tries to link to /usr/lib/.libs/libffi.so instead of /usr/lib/libffi.so. I have manually added blank lines between commands, for clarity. The 3rd commad is the interesting one. The 1st one shows that everything is in order. I have taken time to check the generated Makefile, it looks ok (it includes: libsablevm_la_LIBADD = -lffi -lpthread -lm -ldl as expected). /bin/sh ../../libtool --mode=link gcc -g -O2 -Wall -W -Wundef -Wshadow -Wpointer-arith -Wbad-function-cast -Wcast-align-Wwrite-strings -Wsign-compare -Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations -Wnested-externs -Winline -Wlong-long -O0 -ggdb -Werror -o libsablevm.la -rpath /home/egagnon/work/lib -version-info 0:6:0 invoke_interface.lo init.lo alloc.lo thread.lo util.lo native_interface.lo class_loader.lo macros.lo clalloc.lo error.lo system.lo class_file.lo class_init.lo verifier.lo resolve.lo global_refs.lo local_refs.lo prepare.lo prepare_code.lo heap_manager.lo interpreter.lo method_invoke.lo pthread_rec_svm.lo vmlib.lo native.lo -lffi -lpthread -lm -ldl rm -fr .libs/libsablevm.la .libs/libsablevm.* .libs/libsablevm.* gcc -shared invoke_interface.lo init.lo alloc.lo thread.lo util.lo native_interface.lo class_loader.lo macros.lo clalloc.lo error.lo system.lo class_file.lo class_init.lo verifier.lo resolve.lo global_refs.lo local_refs.lo prepare.lo prepare_code.lo heap_manager.lo interpreter.lo method_invoke.lo pthread_rec_svm.lo vmlib.lo native.lo -Wl,--rpath -Wl,/usr/lib/.libs /usr/lib/.libs/libffi.so -lpthread -lm -ldl -Wl,-soname -Wl,libsablevm.so.0 -o .libs/libsablevm.so.0.0.6 gcc: /usr/lib/.libs/libffi.so: No such file or directory make[3]: *** [libsablevm.la] Error 1 This bug is relatively serious, to me. Do you have any quick suggestion to circumvent this bug? Or should I get an older libtool version and compile it from sources manually? Please, feel free to ask for precisions (and source code). Thanks, Etienne -- -- Etienne M. Gagnon, M.Sc. e-mail: [EMAIL PROTECTED] Author of SableCC: http://www.sablecc.org/ and SableVM: http://www.sablevm.org/ -- System Information Debian Release: testing/unstable Kernel Version: Linux www 2.2.18 #1 Tue Jan 2 17:52:31 EST 2001 i586 unknown Versions of the packages libtool depends on: ii cpp2.95.3-7 The GNU C preprocessor. ii file 3.33-5 Determines file type using magic numbers ii gcc2.95.3-7 The GNU C compiler. ii libc6-dev 2.2.3-1GNU C Library: Development Libraries and Hea ii gcc-2.95 2.95.4-0.01050 The GNU C compiler. ^^^ (Provides virtual package c-compiler) ii libc6-dev 2.2.3-1GNU C Library: Development Libraries and Hea ^^^ (Provides virtual package libc-dev) - End forwarded message - -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
[bam@snoopy.apana.org.au: Bug#97224: libtoolize reports aclocal.m4 out-of-date when it isn't]
Hi, Another problem with libtool 1.4 reported by a Debian user. -Ossama - Forwarded message from Brian May [EMAIL PROTECTED] - [snip] [544] [snoopy:unstable:bam] ~/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e aclocal -I cf [545] [snoopy:unstable:bam] ~/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e libtoolize -f -c Using `AC_PROG_RANLIB' is rendered obsolete by `AC_PROG_LIBTOOL' You should update your `aclocal.m4' by running aclocal. My guess is that the problem is due to this condition: if egrep '^AC_DEFUN\(A[MC]_PROG_LIBTOOL' aclocal.m4 /dev/null 21; then which does not match this data: egrep '^AC_DEFUN\(\[A[MC]_PROG_LIBTOOL' aclocal.m4 AC_DEFUN([AC_PROG_LIBTOOL], AC_DEFUN([AM_PROG_LIBTOOL], [AC_PROG_LIBTOOL]) because of the extra [. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
lots of -lresolv added to command line?
Hi, Here's another libtool 1.4 bug report from a Debian user: --- Is this a bug or a feature? /bin/sh ../../libtool --mode=link gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs -g -O2 -o ipropd-slave ipropd_slave.o libkadm5srv.la ../../lib/hdb/libhdb.la ../../lib/krb5/libkrb5.la ../../lib/asn1/libasn1.la -lcrypto ../../lib/vers/libvers.la ../../lib/roken/libroken.la -ldb -lgdbm -ldl -lresolv -lresolv gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs -g -O2 -o .libs/ipropd-slave ipropd_slave.o ./.libs/libkadm5srv.so -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv /home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/hdb/.libs/libhdb.so -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv ../../lib/hdb/.libs/libhdb.so /home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/krb5/.libs/libkrb5.so -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv ../../lib/krb5/.libs/libkrb5.so -lresolv -lresolv -lresolv /home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/asn1/.libs/libasn1.so -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv /home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/roken/.libs/libroken.so -lresolv -lresolv -lresolv -lresolv -lresolv ../../lib/asn1/.libs/libasn1.so /home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/com_err/.libs/libcom_err.so -lresolv -lresolv -lresolv -lresolv ../../lib/vers/.libs/libvers.al -lresolv -lresolv ../../lib/roken/.libs/libroken.so -lresolv -lcrypto -lresolv -lresolv -ldb -lgdbm -ldl -lresolv -lresolv creating ipropd-slave ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: lots of -lresolv added to command line?
Hi Robert, -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv ../../lib/krb5/.libs/libkrb5.so -lresolv -lresolv -lresolv /home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/asn1/.libs/libasn1.so -lresolv -lresolv -lresolv -lresolv -lresolv -lresolv /home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/roken/.libs/libroken.so -lresolv -lresolv -lresolv -lresolv -lresolv ../../lib/asn1/.libs/libasn1.so /home/bam/source/ext2fs/heimdal-0.3e/build-tree/heimdal-0.3e/lib/com_err/.libs/libcom_err.so -lresolv -lresolv -lresolv -lresolv ../../lib/vers/.libs/libvers.al -lresolv -lresolv ../../lib/roken/.libs/libroken.so -lresolv -lcrypto -lresolv -lresolv -ldb -lgdbm -ldl -lresolv -lresolv creating ipropd-slave Ossama: That depends on your point of view. :) I don't think we totally resolved this issue when it came up last time, so I'll rehash. The duplicate library opetions are preserved to support some systems' static library linking that needs to have dependent libraries linked in particular order, sometimes that means with duplicates. So code was added to Libtool to preserve duplicates, or rather duplicate removal code was taken out. This turned out to cause problems when the list of duplicates gets long, often too long for the shell to execute. So this code was revised to find 'special' libraries $special_deplibs, and preserve only those in duplicates. I can't tell you how these get deemed special though. Right, I recall that. However, having a dozen or so libraries with the same name one after the other such as above seems really unnecessary. Can't we just check if two consecutive libraries in the link command are the same, and if so then zap the second one. A library certainly shouldn't depend on itself. Doing so would fix the duplicate consecutive libraries (e.g. -lresolv -lresolv -lresolv) and still retain the semantics of having more than one instance of the library in the link command such as -lgcc -lfoo -lgcc. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: lots of -lresolv added to command line?
Hi Thomas, On Thu, May 17, 2001 at 07:02:50PM +0200, Thomas Tanner wrote: On 17-May-2001 Ossama Othman wrote: /bin/sh ../../libtool --mode=link gcc -Wall -Wmissing-prototypes -Wpointer-arith -Wbad-function-cast -Wmissing-declarations -Wnested-externs -g -O2 -o ipropd-slave ipropd_slave.o libkadm5srv.la ../../lib/hdb/libhdb.la ../../lib/krb5/libkrb5.la ../../lib/asn1/libasn1.la -lcrypto ../../lib/vers/libvers.la ../../lib/roken/libroken.la -ldb -lgdbm -ldl -lresolv -lresolv ^^^ simply remove the second -lresolv Okay, I'll pass your suggestion on to the Debian user who had the problem. Thanks Thomas! On the other hand, shouldn't libtool be able to handle stuff like this without producing dozens of consecutive duplicates? -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool drops -static from LDFLAGS?
Hi Alexandre, On Tue, May 08, 2001 at 03:55:36PM -0300, Alexandre Oliva wrote: On May 8, 2001, Ossama Othman [EMAIL PROTECTED] wrote: Right, but the problem is that is it prevents users who know what they're doing from using gcc's -static option. Nope. -all-static does that. It's in the libtool manual. If they ``know what they're doing'', they should know that :-D I understand that, but why should a user who downloads a libtoolized package have to read the libtool manual, especially since passing in gcc's -static flag via $LDFLAGS is not an uncommon thing to do. That behavior is now changed due to libtool's own -static flag conflicting with gcc's -static flag. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool drops -static from LDFLAGS?
Hi Alexandre, On Tue, May 08, 2001 at 07:49:30AM -0300, Alexandre Oliva wrote: Libtool drops the user supplied -static flag (e.g. in $LDFLAGS) from the link command. Is this what we want? Yep. To really force static linking, use -all-static. -static tells libtool to *prefer* static libraries, not to *require* them. Right, but the problem is that is it prevents users who know what they're doing from using gcc's -static option. It seems to me that libtool shouldn't do this sort of filtering. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Libtool drops -static from LDFLAGS?
Hi, Libtool drops the user supplied -static flag (e.g. in $LDFLAGS) from the link command. Is this what we want? This behavior has been a source of confusion for some users. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Building c++ library with cxx/osf with libtool
Hi Patrick, On Fri, Nov 03, 2000 at 07:45:08PM +0100, Patrick Guio wrote: Do you think it could be possible to insert this in the libtool? Maybe automake/depcomp has to be modified to be able to use the option -MD with the cxx compaq compiler for osf machines? Does the Compaq C++ support in the libtool multi-language branch work for you? There may be no need to modify libtool, if so. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: KCC and cxx archiver
Hi Patrick, On Fri, Oct 27, 2000 at 05:58:33PM +0200, Patrick Guio wrote: For the KCC compiler I had to include in the configure.in CXX="KCC" CXX_OPTIMIZE_FLAGS="+K3 -O3" CXX_DEBUG_FLAGS="-g +K0 -DBZ_DEBUG" CXXFLAGS="--restrict --strict_warnings --one_instantiation_per_object" AR="KCC" AR_FLAGS="-o" and of cours declare properly the AC_SUBST Note that the --one_instantiation_per_object is very important otherwise you get error message when linking about multi-definitions of instantiations... Would you happen to know why "--one_instantiation_per_object" is not the KCC default? I'm not sure that it is a good idea to make libtool change the default behavior of the compiler. IMHO, it should be up to the user to add "--one_instantiation_per_object" to CXXFLAGS if they need it, not libtool. For the cxx compiler (for DEC alpha, maybe Compaq now?) I had to do The Compaq C++ compiler is also already supported in the multi-language branch libtool. I'd be interested in any feedback you might have regarding that support. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: arg list too long (so, split it into two?)
Hi, On Thu, Oct 05, 2000 at 09:44:19PM +0200, Morten Eriksen wrote: * make larger and fewer object-files, by using some small number of sourcefiles to include the "real" sourcefiles by "#include" statements, and compile and link these instead. For an example of how this can be done and integrated as a configure and build-option, see the Coin library at http://www.coin3d.org. Just an observation... This strategy has the side-effect of increasing footprint, since combining object files pulls in code that may not be necessary at run-time, which is a problem if you're developing embedded applications, for example. This isn't an issue if your linker does function-level linking (MSVC's linker does this I think), but many linkers link entire object files to pull in the appropriate symbols, as I understand. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Three problems with libtools
Hi Marc, On Mon, Oct 02, 2000 at 10:41:12AM +0200, Marc Espie wrote: * the link lines output by libtool are ludicrously long. Since our linker does NOT prune excess libraries, but reloads the symbols each time, this is a fairly large problem... Observe: I thought that we fixed this problem, but I also ran into this problem with one my own packages. I'll try to get this problem soon, if the rest of the team doesn't have time. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool convenience library question
Hi, Is there any reason why libtool convenience libraries use an intermediate static library? Isn't it possible to just add the object files directly to the link command? Are issues such as command line length involved here? Thanks, -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Libtool] Multi-lingual libtool nit
Hi Bob, On Mon, Sep 18, 2000 at 09:02:10PM -0500, Bob Friesenhahn wrote: checking for X... libraries /usr/openwin/lib, headers /usr/openwin/include checking whether -R must be followed by a space... cat: cannot open conftest.c cat: cannot open conftest.c This one isn't coming from the ML-branch libtool. It actually looks like an autoconf test. this is in addition to the previously reported checking for dlopen in -ldl... yes checking for dlfcn.h... yes checking whether a program can dlopen itself... cat: cannot open conftest.cc no I just committed a fix for this to the ML-branch libtool. Thanks for the report Bob! -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [Libtool] How about a C++ test in the multi-language-branch?
Hi Robert, On Tue, Sep 19, 2000 at 11:44:06AM -0500, Robert Boehne wrote: I'm currently attempting to add support for C++ under AIX to libtool, but it would be nice if there was a test case that created a C++ shared library that checked libtool for correct behavior. I currently have g++ shared libraries being created in another project, but they are rather large and time consuming to build, any volunteers? The `tagdemo' already does that. It is part of the test suite. However, it is a rather simple test. It could be improved to take advantage of additional libtool features. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: multi-language-branch: --tag=CXX not specified
Hi Robert, On Fri, Sep 15, 2000 at 03:37:37PM -0500, Robert Boehne wrote: I can now run "make" from the top level and the library will be built. Perhaps there is some confustion using libtool with CXX and CC for files in the same Makefile? This should be transparent. A couple of months ago I added a feature to libtool that automatically selects which tagged configuration to use, even without the "--tag" argument, to specifically handle the situation you describe above. I'll try to reproduce the problem you're getting but I'm fairly certain that this feature was working a few months ago. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: multi-language-branch: --tag=CXX not specified
Hi Robert, I only noticed the following after I posted my last message: On Fri, Sep 15, 2000 at 03:37:37PM -0500, Robert Boehne wrote: libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' Are you using a C++ compiler different (even if only by name) from the one libtool was configured with? Specifically, is the "CXX" tagged configuration set up to use "c++" or "g++?" The above message implies that the libtool configured compiler and the compiler passed by automake are different. Is this the case? BTW, the above message is coming from the automatic tagged configuration selection code I mentioned in my last message. Thanks, -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: multi-language-branch: --tag=CXX not specified
Hi Alexandre,
On Fri, Sep 15, 2000 at 06:58:02PM -0300, Alexandre Oliva wrote:
On Sep 15, 2000, Robert Boehne [EMAIL PROTECTED] wrote:
% ../../libtool --tag=CXX --config | grep '^CC=' | tail -1
CC="cc"
That's the problem. It should be 'g++', in the CXX configuration.
Remove the `tail -1' and make sure you get two lines, one for the
default configuration and one overrider for CXX.
Then go figure why ltconfig got the wrong value when creating the CXX
configuration. Search for `TAG CONFIG: CXX' to see the configuration
variables passed to ltconfig. Also check what version of libtool
you're using.
Robert sent me his generated libtool script. Part of the CXX
configuration is listed below. It appears that ltconfig wasn't
invoked properly. The C++ compiler was not set when configuring the
C++ tagged configuration.
### BEGIN LIBTOOL TAG CONFIG: CXX
# Libtool was configured as follows, on host boreas:
#
# AR="" AR_FLAGS="" LTCC="gcc" CC="" \
# CFLAGS="" CPPFLAGS="" \
# MAGIC="" LD="" LDFLAGS="" LIBS="" \
# LN_S="ln -s" NM="/bin/nm -B" RANLIB="ranlib" STRIP="strip" \
# AS="" DLLTOOL="" OBJDUMP="" \
# objext="" exeext="" reload_flag=" -r" \
# deplibs_check_method="pass_all" \
# file_magic_cmd="\${MAGIC}" \
# make/ltconfig -o libtool --cache-file=/dev/null --with-gcc
--build=powerpc-ibm-aix4.3.3.0 --add-tag=CXX make/ltcf-cxx.sh
powerpc-ibm-aix4.3.3.0
#
BTW, Robert thanks so much for working on the AIX port! I've been
aching to get that port completed but since I don't have access to an
AIX box I've been waiting for someone to come along to help out. :-)
-Ossama
--
Ossama Othman [EMAIL PROTECTED]
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: Link static library into libtool library
Hi, On Thu, Jul 20, 2000 at 04:01:10PM -0400, Paul Berrevoets wrote: Thomas Tanner wrote: Yep. That's already implemented in CVS libtool: Just a minor question ... does CVS libtool require CVS autoconf and/or CVS automake? No. The multi-language branch should work with stable autoconf and automake, in addition to the CVS versions. However, there may still be a problem with using CVS autoconf. I'm not sure if the problem was ever resolved. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
ML libtool: shared libs linked against static ones
Hi, I finally got around to digging into the libtool code to figure out why the static libstdc++.a was't being dropped when linking on Solaris using g++. It turns out that the culprit is the "deplibs_check_method" setting used by libtool on Solaris. It is currently set to "pass_all," which is why the static lib never gets dropped during the ILD analysis loop. Does Solaris actually support linking shared libs against static ones? If not, then it may be a better idea to use the "file_magic" deplibs check method. Thoughts? -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ML libtool: shared libs linked against static ones
Hi Michael, On Sun, Jun 11, 2000 at 02:33:36AM +0200, Michael Matz wrote: On Sat, 10 Jun 2000, Ossama Othman wrote: BTW, I finally got around to setting up two default GNU C++ configurations, one for when g++ uses GNU ld as its linker, and one for the general case (simple and not as robust). I also fixed the cases where an assumption was made that the GNU linker was used with g++, instead of the native linker. I'll submit the patch to libtool-patches in about half an hour. This should make the KDE guys happy. :-) Oops. I forgot to submit the patch for that, and only installed it in our own libtool copy :( FWIW it at least seem to work according to one Solaris user ;) Are you interested in it? So much for avoiding duplication of effort. :-) Feel free to send me the patch. Your patch may be better than mine, or maybe they can be integrated. Thanks! -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ML branch: okay to switch to CVS automake/autoconf?
Hi, On Sat, Jun 03, 2000 at 06:15:34PM -0700, Mo DeJong wrote: Why don't we just create a new branch in the libtool CVS for autoconf 2.14 support? We can fix all the problems caused by the autoconf upgrade on the branch and then merge it back into the HEAD down the road. Does anyone see a problem with that? Just one: time. :-) I don't have the time to maintain another branch. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ml weiredness
Hi Michael and Stephan, On Fri, Jun 02, 2000 at 10:38:54PM +0200, Michael Matz wrote: On Fri, 2 Jun 2000, Stephan Kulow wrote: I only wanted to add, that $predeps are added before $libs if $linkmode==lib. This is also a problem, because e.g for me $predeps contains "-L/usr/local/lib/gcc-lib/i586-pc-linux-gnu/2.95.3 -L/usr/local/lib". This also gets added in _front_ of the user specified -L* by libtool and may have undesired side effect. The problem is, that in the output of the compiler command which is parsed to get the libstdc++, these -L* are in front of the conftest.o. Now g++ itself of course would add any user specified -L* in front of them, and so should libtool too. Thanks for pointing that out. How does the following patch look to you? Index: ltmain.in === RCS file: /cvs/libtool/ltmain.in,v retrieving revision 1.200.2.19 diff -u -r1.200.2.19 ltmain.in --- ltmain.in 2000/05/29 10:40:46 1.200.2.19 +++ ltmain.in 2000/06/03 21:23:09 @@ -1469,8 +1469,20 @@ libs="$libs $deplib" done -if test $linkmode = lib; then - libs="$predeps $libs $postdeps" +if test $linkmode = lib; the + # Internal compiler library paths should come after those + # provided the user. The postdeps already come after the user + # supplied libs so there is no need to process them. + old_predeps=$predeps + new_predeps= + predeps_lib_path= + for p in $old_predeps; do +case "$p" in + -L*|-R*) predeps_lib_path="$predeps_lib_path $p";; + *) new_predeps="$new_predeps $p";; + esac + done + libs="$new_predeps $libs $predeps_lib_path $postdeps" fi deplibs= Furthermore this wrong ordering is saved into the .la files and every other lib I want to link against them picks that up. The above patch should fix the problem. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ml weiredness
Hi, There was a slight bug in the patch I just posted, but I think that you get the idea of what it was supposed to do. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ml weiredness
Hi Stephan, You're too quick. :-) I'm testing a different patch which should be better, and incurs less overhead during link-time, since it is run at config-time. On Sun, Jun 04, 2000 at 01:12:53AM +0200, Stephan Kulow wrote: Ossama Othman wrote: There was a slight bug in the patch I just posted, but I think that you get the idea of what it was supposed to do. You were talking about the the, no? :) Well, "slightly" more than that. :-) OK, it doesn't work. Yep, I realized that just before I got your message. Sorry for the false alarm. I patched your patch to have some debug output: + echo "new_predeps $new_predeps" + echo "libs $libs" + echo "predepds $predeps_lib_path" libs="$new_predeps $libs $predeps_lib_path $postdeps" And this is the result: /bin/sh ../libtool --mode=link g++ -g -ansi -D_XOPEN_SOURCE -D_BSD_SOURCE -fno-exceptions -fno-rtti -fno-check-new -Wall -pedantic -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -Wno-long-long -fno-builtin -frtti -DQT_CLEAN_NAMESPACE -L/usr/X11R6/lib -L/home/coolo/prod/qt/lib -L/home/coolo/prod/KDE/lib -o dcopserver.la -rpath /home/coolo/prod/KDE/lib -module -avoid-version dcopserver.lo libDCOP.la new_predeps libs -L/usr/X11R6/lib -L/home/coolo/prod/qt/lib -L/home/coolo/prod/KDE/lib libDCOP.la predepds -L/usr/lib/gcc-lib/i386-linux/egcs-2.91.66 -L/usr/i386-linux/lib rm -fr .libs/dcopserver.la .libs/dcopserver.lai .libs/dcopserver.so g++ -shared -nostdlib /usr/lib/crti.o /usr/lib/gcc-lib/i386-linux/egcs-2.91.66/crtbeginS.o .libs/dcopserver.o -L/usr/lib -L/usr/i386-linux/lib -L/usr/lib/gcc-lib/i386-linux/egcs-2.91.66 -L/usr/X11R6/lib -L/home/coolo/prod/qt/lib -L/home/coolo/prod/KDE/lib ./.libs/libDCOP.so -lstdc++ -lm -lc -lgcc -lc /usr/lib/gcc-lib/i386-linux/egcs-2.91.66/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,dcopserver.so -o .libs/dcopserver.so creating dcopserver.la Note, that /usr/lib is unknown at the point the code runs you've patched I'm not sure what you mean by it being "unknown." Can you please clarify that point? In any case, my new patch should be better. I'm testing it right now. Thanks, -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ml weiredness
Hi Stephan,
The following patch should be better:
Index: ltcf-cxx.sh
===
RCS file: /cvs/libtool/Attic/ltcf-cxx.sh,v
retrieving revision 1.1.2.11
diff -u -5 -r1.1.2.11 ltcf-cxx.sh
--- ltcf-cxx.sh 2000/05/26 05:49:14 1.1.2.11
+++ ltcf-cxx.sh 2000/06/03 23:24:52
@@ -725,11 +725,11 @@
EOF
if eval $ac_compile 25; then
# Parse the compiler output and extract the necessary
- # object, libraries and library flags.
+ # objects, libraries and library flags.
# Sentinel used to keep track of whether or not we are before
# the conftest object file.
pre_test_object_deps_done=no
@@ -747,15 +747,24 @@
else
prev=
fi
if test "$pre_test_object_deps_done" = no; then
- if test -z "$predeps"; then
- predeps="${prev}${p}"
- else
- predeps="${predeps} ${prev}${p}"
- fi
+ case $p in
+-L* | -R*)
+ # Internal compiler library paths should come after those
+ # provided the user. The postdeps already come after the
+ # user supplied libs so there is no need to process them.
+ if test -z "$compiler_lib_search_path"; then
+ compiler_lib_search_path="${prev}${p}"
+ else
+ compiler_lib_search_path="${compiler_lib_search_path} ${prev}${p}"
+ fi
+ ;;
+# The "-l" case would never come before the object being
+ # linked, so don't bother handling this case.
+ esac
else
if test -z "$postdeps"; then
postdeps="${prev}${p}"
else
postdeps="${postdeps} ${prev}${p}"
Index: ltconfig.in
===
RCS file: /cvs/libtool/ltconfig.in,v
retrieving revision 1.246.2.18
diff -u -5 -r1.246.2.18 ltconfig.in
--- ltconfig.in 2000/05/30 00:31:59 1.246.2.18
+++ ltconfig.in 2000/06/03 23:24:52
@@ -220,10 +220,11 @@
## Dependencies to place before and after the object being linked:
predep_objects=
postdep_objects=
predeps=
postdeps=
+compiler_lib_search_path=
## Link characteristics:
allow_undefined_flag=
no_undefined_flag=
need_lib_prefix=unknown
@@ -1923,11 +1924,11 @@
thread_safe_flag_spec whole_archive_flag_spec libname_spec \
library_names_spec soname_spec \
RANLIB old_archive_cmds old_archive_from_new_cmds old_postinstall_cmds \
old_postuninstall_cmds archive_cmds archive_expsym_cmds postinstall_cmds \
postuninstall_cmds extract_expsyms_cmds old_archive_from_expsyms_cmds \
-predep_objects postdep_objects predeps postdeps \
+predep_objects postdep_objects predeps postdeps compiler_lib_search_path \
old_striplib striplib file_magic_cmd export_symbols_cmds \
deplibs_check_method allow_undefined_flag no_undefined_flag \
finish_cmds finish_eval global_symbol_pipe global_symbol_to_cdecl \
hardcode_libdir_flag_spec hardcode_libdir_separator \
sys_lib_search_path_spec sys_lib_dlsearch_path_spec \
@@ -2216,10 +2217,14 @@
predeps=$predeps
# Dependencies to place after the objects being linked to create a
# shared library.
postdeps=$postdeps
+
+# The library search path used internally by the compiler when linking
+# a shared library.
+compiler_lib_search_path=$compiler_lib_search_path
# Method to check whether dependent libraries are shared objects.
deplibs_check_method=$deplibs_check_method
# Command to use when deplibs_check_method == file_magic.
Index: ltmain.in
===
RCS file: /cvs/libtool/ltmain.in,v
retrieving revision 1.200.2.19
diff -u -5 -r1.200.2.19 ltmain.in
--- ltmain.in 2000/05/29 10:40:46 1.200.2.19
+++ ltmain.in 2000/06/03 23:24:53
@@ -1468,11 +1468,11 @@
esac
libs="$libs $deplib"
done
if test $linkmode = lib; then
- libs="$predeps $libs $postdeps"
+ libs="$predeps $libs $compiler_lib_search_path $postdeps"
fi
deplibs=
newdependency_libs=
newlib_search_path=
Here are the results for the tagdemo in the libtool CXX tagged
configuration on Linux:
# Dependencies to place before the objects being linked to create a
# shared library.
predeps=""
# Dependencies to place after the objects being linked to create a
# shared library.
postdeps="-lstdc++ -lm -lgcc -lc -lgcc"
# The library search path used internally by the compiler when linking
# a shared library.
compiler_lib_search_path="-L/usr/lib/gcc-lib/i386-linux/2.95.2"
Here is the contents of the "$libs" variable passed to the ILD
analyser:
libs: -lm -L/usr/lib/gcc-lib/i386-linux/2.95.2 -lstdc++ -lm -lgcc -lc -lgcc
You're KDE test is of course much more exhaustive then this simple
test. Can you please g
Re: ml weiredness
Hi Stephan, On Sun, Jun 04, 2000 at 01:42:18AM +0200, Stephan Kulow wrote: OK, your patch doesn't heal the problem and now that the deps are so much clearer, I think it's clear that the ml stuff isn't to blame per se :) Whew! :-) /bin/sh ../libtool --mode=link g++ -g -ansi -D_XOPEN_SOURCE -D_BSD_SOURCE -fno-exceptions -fno-rtti -fno-check-new -Wall -pedantic -W -Wpointer-arith -Wmissing-prototypes -Wwrite-strings -Wno-long-long -fno-builtin -frtti -DQT_CLEAN_NAMESPACE -L/usr/X11R6/lib -L/home/coolo/prod/qt/lib -L/home/coolo/prod/KDE/lib -o dcopserver.la -rpath /home/coolo/prod/KDE/lib -module -avoid-version dcopserver.lo libDCOP.la libs = -L/usr/X11R6/lib -L/home/coolo/prod/qt/lib -L/home/coolo/prod/KDE/lib libDCOP.la -L/usr/lib/gcc-lib/i386-linux/egcs-2.91.66 -L/usr/i386-linux/lib -lstdc++ -lm -lgcc -lc -lgcc rm -fr .libs/dcopserver.la .libs/dcopserver.lai .libs/dcopserver.so g++ -shared -nostdlib /usr/lib/crti.o /usr/lib/gcc-lib/i386-linux/egcs-2.91.66/crtbeginS.o .libs/dcopserver.o -L/usr/i386-linux/lib -L/usr/lib/gcc-lib/i386-linux/egcs-2.91.66 -L/usr/lib -L/usr/X11R6/lib -L/home/coolo/prod/qt/lib -L/home/coolo/prod/KDE/lib ./.libs/libDCOP.so -lstdc++ -lm -lc -lgcc -lc /usr/lib/gcc-lib/i386-linux/egcs-2.91.66/crtendS.o /usr/lib/crtn.o -Wl,-soname -Wl,dcopserver.so -o .libs/dcopserver.so creating dcopserver.la to the libs = everything looks perfect, but then the conv pass seems to run wild ;) Ah okay. Well, at least we're narrowing down the problem. the libDCOP.la file looks like this dependency_libs=' -L/usr/X11R6/lib -L/home/coolo/prod/qt/lib -L/home/coolo/prod/KDE/lib -lSM -lICE -lICE -lqt -lpng -lz /usr/lib/libjpeg.la -lXext -lX11 -lSM -lICE -L/usr/lib/gcc-lib/i386-linux/egcs-2.91.66 -L/usr/i386-linux/lib -lstdc++ -lm -lc -lgcc' Also quite perfect. I investigate further Great! Thank you very much! -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
ML branch: okay to switch to CVS automake/autoconf?
Hi, Since many of you are using the libtool multi-language branch, I wanted to check with you about switching that branch to use CVS autoconf and CVS automake. I have some patches ready for approval (i.e. I haven't submitted them for approval yet), but if there is too much opposition to such a move then I may rethink the switch. Does anyone have problems with such a change? Thanks, -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ML branch: okay to switch to CVS automake/autoconf?
Hi Stephan, On Fri, Jun 02, 2000 at 09:46:59PM +0200, Stephan Kulow wrote: Ossama Othman wrote: Since many of you are using the libtool multi-language branch, I wanted to check with you about switching that branch to use CVS autoconf and CVS automake. I have some patches ready for approval (i.e. I haven't submitted them for approval yet), but if there is too much opposition to such a move then I may rethink the switch. Does anyone have problems with such a change? It would make _my_ task a lot more difficult as I would have to backport your changes to released versions of auto*. We already keep our own copy of libtool in our CVS, anything else wouldn't work for KDE. *sigh* Maintaining backward compatiblity with Autoconf 2.13 and Automake 1.4 makes things harder for me. However, I don't want to make your job harder either. I'll try to make the patches backward compatible. If I can't then I'll hold off on them. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ltcf-cxx.sh
Hi Kevin, On Wed, May 31, 2000 at 12:46:34AM -0400, Kevin Atkinson wrote: On Tue, 30 May 2000, Ossama Othman wrote: Thanks for the simple test. I just need to find a Solaris system with a busted libstdc++ installation, i.e. one that built without "--enable-shared." That should not be too difficult because that is the default option when building gcc. Right. The problem is that we were aware of the problem with gcc attempting to link a static libstdc++ on Solaris so we built all of our gcc installations with "--enabled-shared." out the AC_LIBTOOL_CXX, so the C++ support is really transparent now (well, theoretically :-). Oh, that well it is insisting on having the unneeded ltcf-gcj.sh in the current directory if it is missing I get: ... loading cache ./config.cache ltconfig: `./ltcf-gcj.sh' does not exist Try `ltconfig --help' for more information. configure: error: libtool tag configuration failed Not that big of a deal but quite annoying, especially since libtoolize doesn't install it for you. Hmm. Alexandre? In any case, if Alexandre doesn't get a chance to fix this problem, I'll take a look at it tomorrow when I get in. Another thing, what version of autoconf/automake due you recommend using? Using the CVS version I get all sorts of warning over obsolete variables, but don't want to change them as that will loose all hope with working with the released version. I remember trying the released version and had some problems with automake making the file exec.C as the executable I'm currently using Autoconf 2.13 and Automake 1.4. However, Alexandre is using the CVS Automake. I'm going to switch to the CVS Automake very soon, too. Alexandre, Gary, Thomas, which version of Autoconf are you guys using? -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ltcf-cxx.sh
Hi Kevin, I've run through the libtool code again, and I think that I was wrong about the ML branch bypassing the part of libtool that drops static libs. AFAICT, the ML branch simply adds the libraries it detected from the internal C++ compiler link commands, and adds them to the list of libraries that libtool's inter-library dependency analyzer goes through. This means that libtool should be dropping the static libs from the dependency list. Do you get a warning message from Libtool such as: *** Warning: This library needs some functionality provided by some lib. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. or do you get this warning: *** Warning: Linking the shared library some lib against the *** static library some dep lib is not portable! Do you get any warning from libtool? Thanks, -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ltcf-cxx.sh
Hi Kevin, On Tue, May 30, 2000 at 05:37:59PM -0400, Kevin Atkinson wrote: On Tue, 30 May 2000, Ossama Othman wrote: goes through. This means that libtool should be dropping the static libs from the dependency list. Do you get a warning message from Libtool such as: None: This is what I get rac10:~/test: ./configure --enable-shared --disable-static creating cache ./config.cache [snip] mkdir .libs c++ -DPACKAGE=\"test\" -DVERSION=\"1.0\" -I. -I. -g -O2 -c test.cc -Wp,-MD,.deps/test.TPlo -fPIC -DPIC -o .libs/test.o /bin/sh ./libtool --mode=link c++ -g -O2 -o libtest.la -rpath /usr/local/lib test.lo [snip] _IO_do_write0x154 /usr/local/gnu/lib/gcc-lib/sparc-sun-solaris2.6/2.95.1/libstdc++.a(filebuf.o) ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `libtest.la' This is using the latest libtool ml checked out at arounf 5:00 PM EST. *sigh* :-( Okay, that's certainly busted. I'll dive into the code again. Thanks for the feedback Kevin! I am using a CVS Version of Autoconf and automake not sure of the last checkout data but it was within a month. AFAIK, this shouldn't be a problem. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ltcf-cxx.sh
Hi Kevin,
Thanks for the simple test. I just need to find a Solaris system with
a busted libstdc++ installation, i.e. one that built without
"--enable-shared."
On Tue, May 30, 2000 at 08:43:17PM -0400, Kevin Atkinson wrote:
AC_INIT(test.cc)
AM_INIT_AUTOMAKE(test, 1.0)
AC_PROG_CXX
AC_LANG_CPLUSPLUS
AM_PROG_LIBTOOL
AC_LIBTOOL_CXX
BTW, Alexandre committed some changs that make it possible to leave
out the AC_LIBTOOL_CXX, so the C++ support is really transparent now
(well, theoretically :-).
AC_OUTPUT(Makefile)
test.cc:
#include iostream
void foo() {
cout "What!" endl;
}
Thanks!
-Ossama
--
Ossama Othman [EMAIL PROTECTED]
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ltcf-cxx.sh
Hi Kevin, On Sun, May 28, 2000 at 07:37:11PM -0400, Kevin Atkinson wrote: I was just informed that the HEAD branch does indeed drop static library dependencies when making shared libraries. Perhaps the HEAD branch needs to be merged with the ML branch or is it something else? The core HEAD branch libtool files ltmain.in, ltconfig.in and libtool.m4 have been merged into the ML branch. However, the ML branch probably reintroduced the static libs due to the fact it analyses what the C++ compiler links internally based on output from "g++ -v," for example. What is most likely happening is that the new C++ library analysing code is bypassing the code in libtool that would normally drop the static libs. Now that I think about it, libtool is only reproducing what the C++ compiler would normally do internally, so why would libtool be wrong? Specifically, libtool disables the internal library link commands that the C++ compiler would normally perform automatically, and simply does the linking itself. Why does it work for the C++ compiler? -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ltcf-cxx.sh
Hi Stephan, On Sat, May 27, 2000 at 10:10:44AM +0200, Stephan Kulow wrote: Kevin Atkinson wrote: Hopefully since KDE will be using it some KDE people will help to improve the C++ support. I am sure they will run into the problem with non-pic static libraries being linked into shared libraries also. Especially on Solaries. If you look at http://bugs.kde.org/db/40/4094.html, you'll find out that they indeed didn't long to find the flaws in the ml-libtool :) Is this flaw specific to the ML branch, or does the HEAD branch suffer from this flaw too? -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: ltcf-cxx.sh
Hi Michael, On Fri, May 26, 2000 at 12:51:01AM +0200, Michael Matz wrote: On Mon, 22 May 2000, Ossama Othman wrote: Great! KDE would be a great smoke test for the multi-language branch libtool. It's smoking already ;) Even with problem reports ;) Great! Well, at least for the libtool team. :-) On Wed, 24 May 2000, Ossama Othman wrote: I'll try to move the general g++ configurations outside of the platform-specific configurations soon. Great. Note that it's all not only depending on the compiler, but also on the actual linker used, so $with_gnu_ld should also be tested. E.g. just today I had a report from someone using KDE on Solaris with gcc and GNU ld. Currently that won't work, because on Solaris ltcf-cxx.sh thinks its using the native linker. (for -export-symbols it tries to give -M bla.exp to the linker). Ah! Good point! I guess, the easiest solution would be, to structure ltcf-cxx.sh like: if test $with_gcc = yes test $with_gnu_ld = yes ; then # do useful things, mostly independent from the OS # note, that mostly (if $with_gnu_ld -- also $with_gcc) else if test $with_gcc = yes ; then # do stuff where we at least can count on g++, while using the native # linker else # do ugly stuff for each OS fi fi That way, I think we can factorize out most similarities in behaviour. (I'm not just whining ;) on the weekend I'll try to implement something similar to above, the next BETA is not that far away ;) That sounds good. Thanks so much for your help Michael! Needless to say, it is greatly appreciated! Btw. just a small thing: in all 'case' statements testing for $CXX you should use $compiler, as $CXX can have arguments. In fact it is set already in the beginning, just not used. No diff, because it would be larger than the description ;) Hmm, I though that Alexandre as already took care of this. It must've been a patch that wasn't integrated. Alexandre, should I integrate your patch? Thanks for reminding me of this problem Michael! All of this feedback is great! I think that we can make some real progress on the multi-language branch because of it!!! Thanks again, -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: Status Update Request (C++, static libraries)
Hi Kevin, On Thu, May 18, 2000 at 11:43:28PM -0400, Kevin Atkinson wrote: On Thu, 18 May 2000, Ossama Othman wrote: Sure. I don't know anything about libtool's internals but if you send me a patch I can try it out on several different platforms including Digital UNIX which currently doesn't have C++ support. I'll try to put one together soon, when I have some spare time. Donations are always welcome. :-) Well if you point me in the right direction I may just give you one I'll review the libtool code again to see where and how the static library problem can be fixed. Hopefully, I'll have some time to back into this stuff this weekend. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: parallel build
On Thu, Feb 24, 2000 at 10:46:47AM +0100, Stephan Kulow wrote: Thomas Tanner wrote: On 11-Feb-2000 Stephan Kulow wrote: mkdir .libs mkdir .libs mkdir: Failed to make directory ".libs"; File exists ../libtool: test: argument expected make[2]: *** [ksconfig.lo] Error 1 make[2]: *** Waiting for unfinished jobs As it seems, the libtool runs start a little race to create the .libs directory and one failed ;( Strange. There should be no problem with creating .libs at the same time. How can the following code in libtool fail? if test -d "$dir"; then $show "$rm $libobj" $run $rm $libobj else $show "$mkdir $dir" $run $mkdir $dir status=$? if test $status -ne 0 test ! -d $dir; then exit $status fi fi I suppose there's a bug in your shell that doesn't set status correctly. Could you please add "echo $status" after "status=$?" and try it again? Well, I think I found the bug. The multi-language branch creates the objdir and the code looks like this: if test ! -d $objdir; then $show "$mkdir $objdir" $run $mkdir $objdir status=$? if test $status -ne 0 test ! -d $dir; then exit $status fi fi And the $dir is quite not existant :) Thanks for pointing me at the right place. Hmm, I guess I missed that one. Sorry. :-) I'll check in a fix later today. Thanks! -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
