Re: [libtool 2.2] testsuite: 34 failed
Ralf Wildenhues wrote: * Roberto Bagnara wrote on Sun, Mar 02, 2008 at 08:48:07AM CET: I got errors on a Fedora 7 system (x86_64): the log file is attached. I have also tried using Libtool 2.2 on one of my projets, but I get the following: /bin/sh ../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I.. -I/home/roberto/ppl/ppl/src -I.. -I/home/roberto/ppl/ppl/src-g -frounding-math -W -Wall -MT Box.lo -MD -MP -MF .deps/Box.Tpo -c -o Box.lo /home/roberto/ppl/ppl/src/Box.cc ../libtool: line 459: CDPATH: command not found ../libtool: line 1262: func_opt_split: command not found libtool: Version mismatch error. This is libtool 2.2, but the libtool: definition of this LT_INIT comes from an older release. libtool: You should recreate aclocal.m4 with macros from libtool 2.2 libtool: and run autoconf again. I think I did that on entirely new directories and after running `autoreconf -f' to recreate (among other things), aclocal.m4. What am I missing? Which Autoconf, M4 versions were used? What says grep LT_INIT aclocal.m4 m4/libtool.m4 (modify the latter to point at the libtool.m4 file that's copied into your project if any). Hi Ralf, this was entirely my fault: I did something stupid in my first attempt of switching from Libtool 1.5.24 to Libtool 2.2 (m4/libtool.m4 was not even there). However, things still do not seem to work properly for me. Trying to understand what is going on, I have distilled the following: $ cat mycommand #!/bin/sh echo mycommand invoked with argument '$1' $ mycommand ciao mycommand invoked with argument 'ciao' $ ./libtool --mode=execute mycommand ciao mycommand invoked with argument '/home/roberto/tppl/' $ Note that /home/roberto/tppl/ is the directory where the libtool script is located. I can also do $ cd interfaces/ $ ../libtool --mode=execute ../mycommand ciao mycommand invoked with argument '/home/roberto/tppl/' Is this behavior normal? ./libtool is what has been created at configure time and a bzipped version of it is attached to this file. Still looking at your the testsuite failure (but it's anyway an issue separate from the above). Cheers, and thanks for the report, Thanks to you! Best, Roberto P.S. In ./libtool there is the line # Generated automatically by config.status (GNU ppl) 0.10pre16 `ppl' is indeed the short name of the project. I don't know why it is preceded by GNU. -- Prof. Roberto Bagnara Computer Science Group Department of Mathematics, University of Parma, Italy http://www.cs.unipr.it/~bagnara/ mailto:[EMAIL PROTECTED] ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: libltdl memory corruption
Ralf Wildenhues wrote: Hello Andreas, * Andreas Schwab wrote on Mon, Mar 03, 2008 at 03:39:47PM CET: libltdl uses memory after free when initialized twice. Thank you very much for the bug report. Proposed patch below. I tested it on i686-unknown-linux-gnu but it should be tested with as many loaders as possible. So I'd appreciate a review of this, and also test results on systems with loaders other than preopen and dlopen. (I haven't even tested successful compilation on those other systems.) This looks ok with a quick visual inspection. I'll try it on a couple of systems tonight (dyld on mac os x 10.2, and shl_load on hpux10.20). Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
RE: Libtool HEAD on Windows.
Hi! Ralf Wildenhues mailto:[EMAIL PROTECTED] wrote: * Duft Markus wrote on Mon, Mar 03, 2008 at 09:33:44AM CET: [[...]] Still waiting for _something_... Sorry about being completely silent. Your patch is intrusive in that it changes more than should be necessary, it changes code that should not be changed. The ideal is: only libtool.m4 and ltdl.m4 contain system specifics, all other code is generic. Now I know that we're far from this ideal, but every step further away is one that should be scrutinized. Then Windows won't work, i think. I really need to add dllimport stuff (which is ifdef'd out in first place, and which is there allready partially for cygwin/mingw...) to c/h files. I tried to change as little as possible anyway allready :( I could throw away the changes to the loadlibrary loader, since the dlopen interface which i implemented is used anyway. I don't know if it would have any side effects on other software if RTDL_GLOBAL is not defined. If not, then maybe i could remove the definition for it to avoid the other ifdef. As for beeing generic: all the locations where there is a switch/case on the host, i have to insert winnt. Also, some of the testsuite changes look like they are papering over the failure rather than fix the issue. The template.at changes fall into this category. Hmm Here i had to add libraries to the command line for the linker to find symbols. If this isn't desired i'll have to xfail or skip the test, since i cannot link with unresolved symbols on windows. Last but not least, I don't know if you noticed that Libtool was in regression fixes mode up to the 2.2 release (yeah, I know it was an ugly long time). Given limited time, I for one simply ignored everything that wasn't fixing a regression or easy to verify as safe. No, i didn't notice that... I might give a detailed review on your patch, but that may be some days. Thats absolutely no problem, now that i have some status :) Thanks for the (now) fast answer :) Cheers, Markus Cheers, Ralf
Re: libltdl memory corruption
Hello Andreas,
* Andreas Schwab wrote on Mon, Mar 03, 2008 at 03:39:47PM CET:
libltdl uses memory after free when initialized twice.
Thank you very much for the bug report. Proposed patch below.
I tested it on i686-unknown-linux-gnu but it should be tested
with as many loaders as possible.
So I'd appreciate a review of this, and also test results on systems
with loaders other than preopen and dlopen. (I haven't even tested
successful compilation on those other systems.)
Thanks,
Ralf
2008-03-03 Ralf Wildenhues [EMAIL PROTECTED]
* libltdl/loaders/dld_link.c (vl_exit): New function, zero out ...
(vtable): ... this new file static variable split out from ...
(get_vtable): ... here. Initialize vtable, register vl_exit as
dlloader_exit function.
* libltdl/loaders/dlopen.c: Likewise.
* libltdl/loaders/dyld.c: Likewise.
* libltdl/loaders/load_add_on.c: Likewise.
* libltdl/loaders/loadlibrary.c: Likewise.
* libltdl/loaders/shl_load.c: Likewise.
* libltdl/loaders/preopen.c: Likewise; vl_exit existed here
already
* tests/lt_dlexit.at (lt_dlexit unloading libs): Update test.
Report by Andreas Schwab.
Index: libltdl/loaders/dld_link.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/loaders/dld_link.c,v
retrieving revision 1.9
diff -u -r1.9 dld_link.c
--- libltdl/loaders/dld_link.c 8 May 2007 14:38:50 - 1.9
+++ libltdl/loaders/dld_link.c 3 Mar 2008 21:41:03 -
@@ -1,7 +1,7 @@
/* loader-dld_link.c -- dynamic linking with dld
Copyright (C) 1998, 1999, 2000, 2004, 2006,
- 2007 Free Software Foundation, Inc.
+ 2007, 2008 Free Software Foundation, Inc.
Written by Thomas Tanner, 1998
NOTE: The canonical source of this file is maintained with the
@@ -45,20 +45,21 @@
/* Boilerplate code to set up the vtable for hooking this loader into
libltdl's loader list: */
+static int vl_exit (lt_user_data loader_data);
static lt_module vm_open (lt_user_data loader_data, const char *filename,
lt_dladvise advise);
static int vm_close (lt_user_data loader_data, lt_module module);
static void * vm_sym (lt_user_data loader_data, lt_module module,
const char *symbolname);
+static lt_dlvtable *vtable = 0;
+
/* Return the vtable for this loader, only the name and sym_prefix
attributes (plus the virtual function implementations, obviously)
change between loaders. */
lt_dlvtable *
get_vtable (lt_user_data loader_data)
{
- static lt_dlvtable *vtable = 0;
-
if (!vtable)
{
vtable = lt__zalloc (sizeof *vtable);
@@ -70,6 +71,7 @@
vtable-module_open = vm_open;
vtable-module_close = vm_close;
vtable-find_sym = vm_sym;
+ vtable-dlloader_exit= vl_exit;
vtable-dlloader_data= loader_data;
vtable-priority = LT_DLLOADER_APPEND;
}
@@ -92,6 +94,15 @@
# include dld.h
#endif
+/* A function called through the vtable when this loader is no
+ longer needed by the application. */
+static int
+vl_exit (lt_user_data LT__UNUSED loader_data)
+{
+ vtable = NULL;
+ return 0;
+}
+
/* A function called through the vtable to open a module with this
loader. Returns an opaque representation of the newly opened
module for processing with this loader's other vtable functions. */
Index: libltdl/loaders/dlopen.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/loaders/dlopen.c,v
retrieving revision 1.12
diff -u -r1.12 dlopen.c
--- libltdl/loaders/dlopen.c12 Jan 2008 17:00:51 - 1.12
+++ libltdl/loaders/dlopen.c3 Mar 2008 21:41:03 -
@@ -45,20 +45,21 @@
/* Boilerplate code to set up the vtable for hooking this loader into
libltdl's loader list: */
+static int vl_exit (lt_user_data loader_data);
static lt_module vm_open (lt_user_data loader_data, const char *filename,
lt_dladvise advise);
static int vm_close (lt_user_data loader_data, lt_module module);
static void * vm_sym (lt_user_data loader_data, lt_module module,
const char *symbolname);
+static lt_dlvtable *vtable = 0;
+
/* Return the vtable for this loader, only the name and sym_prefix
attributes (plus the virtual function implementations, obviously)
change between loaders. */
lt_dlvtable *
get_vtable (lt_user_data loader_data)
{
- static lt_dlvtable *vtable = 0;
-
if (!vtable)
{
vtable = (lt_dlvtable *) lt__zalloc (sizeof *vtable);
@@ -73,6 +74,7 @@
vtable-module_open = vm_open;
vtable-module_close = vm_close;
vtable-find_sym = vm_sym;
+ vtable-dlloader_exit= vl_exit;
vtable-dlloader_data= loader_data;
vtable-priority
Re: libltdl memory corruption
Ralf Wildenhues wrote: Hello Andreas, * Andreas Schwab wrote on Mon, Mar 03, 2008 at 03:39:47PM CET: libltdl uses memory after free when initialized twice. Thank you very much for the bug report. Proposed patch below. I tested it on i686-unknown-linux-gnu but it should be tested with as many loaders as possible. So I'd appreciate a review of this, and also test results on systems with loaders other than preopen and dlopen. (I haven't even tested successful compilation on those other systems.) This looks ok with a quick visual inspection. I'll try it on a couple of systems tonight (dyld on mac os x 10.2, and shl_load on hpux10.20). Peter -- Peter O'Gorman http://pogma.com
Re: libltdl memory corruption
Ralf Wildenhues wrote: Hello Andreas, * Andreas Schwab wrote on Mon, Mar 03, 2008 at 03:39:47PM CET: libltdl uses memory after free when initialized twice. Thank you very much for the bug report. Proposed patch below. I tested it on i686-unknown-linux-gnu but it should be tested with as many loaders as possible. So I'd appreciate a review of this, and also test results on systems with loaders other than preopen and dlopen. (I haven't even tested successful compilation on those other systems.) I did not manage to try the shl_load loader, only tested dyld. This patch causes no regressions on Mac OS X 10.2. If that is also true for the loaders you get around to trying, this is ok. Thank you. Once again you sent a patch for a bug before I even got around to reading the list. Peter -- Peter O'Gorman http://pogma.com
Re: why does libtool reorder -Wl, arguments to the end making -Wl, --as-needed unusable
Peter O'Gorman kirjoitti: Petteri Räty wrote: Albert Chin kirjoitti: On Thu, Feb 28, 2008 at 03:17:54PM +0200, Petteri Räty wrote: [EMAIL PROTECTED] /mnt/checkouts/classpath/native/jni/qt-peer $ make make all-am make[1]: Entering directory `/mnt/checkouts/classpath/native/jni/qt-peer' /bin/sh ../../../libtool --tag=CXX --mode=link g++ -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -g -O2 -module -version-info 0:0:0 -no-undefined -avoid-version -Wl,--as-needed -o libqtpeer.la -rpath /usr/local/classpath/lib/classpath ... [snip snip] --as-needed needs to come before the object files and libs to be effective but libtool moves it to the end. This happens with both 1.5.26 and cvs head. The fact that libtool reorders _any_ of the command-line is a bug. I think Ralf has a fix for this but I don't think it'll happen until 2.1 or 2.2. Still there in libtool 2.2 As a workaround until we get this fixed, if an automake based project try 'make CXXLD='g++ -Wl,--as-needed' CCLD='gcc -Wl,--as-needed'. I'll look into this. Peter that does not help: [EMAIL PROTECTED] ~/cpp/libtooltest $ grep CXXLD * Makefile:CXXLD = $(CXX) Makefile: --mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) $(AM_LDFLAGS) \ Makefile.in:CXXLD = $(CXX) Makefile.in:--mode=link $(CXXLD) $(AM_CXXFLAGS) $(CXXFLAGS) $(AM_LDFLAGS) \ But with CXX set to CXX='g++ -Wl,--as-needed' it does work. I don't know if that will break anything but we shall see. I also wonder why libtool brings all these dependency libraries with -lpulse: [EMAIL PROTECTED] ~/cpp/libtooltest $ ldd .libs/libfoobar.so linux-gate.so.1 = (0xb7f82000) libpulse.so.0 = /usr/lib/libpulse.so.0 (0xb7f23000) libSM.so.6 = /usr/lib/libSM.so.6 (0xb7f1a000) libICE.so.6 = /usr/lib/libICE.so.6 (0xb7f02000) libX11.so.6 = /usr/lib/libX11.so.6 (0xb7e1b000) libXau.so.6 = /usr/lib/libXau.so.6 (0xb7e17000) libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0xb7e12000) libcap.so.1 = /lib/libcap.so.1 (0xb7e0e000) librt.so.1 = /lib/librt.so.1 (0xb7e05000) libdl.so.2 = /lib/libdl.so.2 (0xb7e01000) libstdc++.so.6 = /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libstdc++.so.6 (0xb7d14000) libm.so.6 = /lib/libm.so.6 (0xb7cee000) libc.so.6 = /lib/libc.so.6 (0xb7bb9000) libgcc_s.so.1 = /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libgcc_s.so.1 (0xb7bad000) libpthread.so.0 = /lib/libpthread.so.0 (0xb7b95000) /lib/ld-linux.so.2 (0x8000) After -Wl,--as-needed: [EMAIL PROTECTED] ~/cpp/libtooltest $ ldd .libs/libfoobar.so linux-gate.so.1 = (0xb7ffa000) libstdc++.so.6 = /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libstdc++.so.6 (0xb7eec000) libc.so.6 = /lib/libc.so.6 (0xb7db7000) libm.so.6 = /lib/libm.so.6 (0xb7d92000) libgcc_s.so.1 = /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libgcc_s.so.1 (0xb7d86000) /lib/ld-linux.so.2 (0x8000) Regards, Petteri ___ http://lists.gnu.org/mailman/listinfo/libtool
libltdl memory corruption
libltdl uses memory after free when initialized twice.
$ cat ltdl.c
#include ltdl.h
int
main ()
{
lt_dlinit ();
lt_dlexit ();
lt_dlinit ();
lt_dlexit ();
}
$ gcc ltdl.c -o ltdl -lltdl
$ MALLOC_CHECK_=2 ./ltdl
Segmentation fault
The bug is that preopen_LTX_get_vtable returns a pointer to memory that
has already been freed by lt_dlexit.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
And now for something completely different.
___
Bug-libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: why does libtool reorder -Wl, arguments to the end making -Wl, --as-needed unusable
There is some sort of patch available at: http://bugs.debian.org/347650#60 Kurt On Thu, Feb 28, 2008 at 03:17:54PM +0200, Petteri Räty wrote: [EMAIL PROTECTED] /mnt/checkouts/classpath/native/jni/qt-peer $ make make all-am make[1]: Entering directory `/mnt/checkouts/classpath/native/jni/qt-peer' /bin/sh ../../../libtool --tag=CXX --mode=link g++ -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -g -O2 -module -version-info 0:0:0 -no-undefined -avoid-version -Wl,--as-needed -o libqtpeer.la -rpath /usr/local/classpath/lib/classpath libqtpeer_la-componentevent.lo libqtpeer_la-keybindings.lo libqtpeer_la-mainqtthread.lo libqtpeer_la-mainthreadinterface.lo libqtpeer_la-nativewrapper.lo libqtpeer_la-qmatrix.lo libqtpeer_la-qpainterpath.lo libqtpeer_la-qpen.lo libqtpeer_la-qtaudioclip.lo libqtpeer_la-qtbuttonpeer.lo libqtpeer_la-qtcanvaspeer.lo libqtpeer_la-qtcheckboxpeer.lo libqtpeer_la-qtchoicepeer.lo libqtpeer_la-qtcomponent.lo libqtpeer_la-qtcomponentpeer.lo libqtpeer_la-qtdialogpeer.lo libqtpeer_la-qtembeddedwindowpeer.lo libqtpeer_la-qtfiledialogpeer.lo libqtpeer_la-qtfontmetrics.lo libqtpeer_la-qtfontpeer.lo libqtpeer_la-qtframepeer.lo libqtpeer_la-qtgraphics.lo libqtpeer_la-qtimage.lo libqtpeer_la-qtlabelpeer.lo libqtpeer_la-qtlistpeer.lo libqtpeer_la-qtmenubarpeer.lo libqtpeer_la-qtmenucomponentpeer.lo libqtpeer_la-qtmenuitempeer.lo libqtpeer_la-qtmenupeer.lo libqtpeer_la-qtpanelpeer.lo libqtpeer_la-qtpopupmenupeer.lo libqtpeer_la-qtscreendevice.lo libqtpeer_la-qtscrollbarpeer.lo libqtpeer_la-qtscrollpanepeer.lo libqtpeer_la-qtstrings.lo libqtpeer_la-qttextareapeer.lo libqtpeer_la-qttextfieldpeer.lo libqtpeer_la-qttoolkit.lo libqtpeer_la-qtvolatileimage.lo libqtpeer_la-qtwindowpeer.lo libqtpeer_la-slotcallbacks.lo -L/usr/lib/qt4 -lQtGui -lpng -lSM -lICE -lQtCore -lz -lrt -lpthread -lXrender -lXrandr -lXfixes -lXcursor -lXinerama -lfreetype -lfontconfig -lXext -lX11 -lm -ldl -lpulse libtool: link: rm -fr .libs/libqtpeer.la .libs/libqtpeer.lai .libs/libqtpeer.so libtool: link: g++ -shared -nostdlib /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/../../../crti.o /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/crtbeginS.o .libs/libqtpeer_la-componentevent.o .libs/libqtpeer_la-keybindings.o .libs/libqtpeer_la-mainqtthread.o .libs/libqtpeer_la-mainthreadinterface.o .libs/libqtpeer_la-nativewrapper.o .libs/libqtpeer_la-qmatrix.o .libs/libqtpeer_la-qpainterpath.o .libs/libqtpeer_la-qpen.o .libs/libqtpeer_la-qtaudioclip.o .libs/libqtpeer_la-qtbuttonpeer.o .libs/libqtpeer_la-qtcanvaspeer.o .libs/libqtpeer_la-qtcheckboxpeer.o .libs/libqtpeer_la-qtchoicepeer.o .libs/libqtpeer_la-qtcomponent.o .libs/libqtpeer_la-qtcomponentpeer.o .libs/libqtpeer_la-qtdialogpeer.o .libs/libqtpeer_la-qtembeddedwindowpeer.o .libs/libqtpeer_la-qtfiledialogpeer.o .libs/libqtpeer_la-qtfontmetrics.o .libs/libqtpeer_la-qtfontpeer.o .libs/libqtpeer_la-qtframepeer.o .libs/libqtpeer_la-qtgraphics.o .libs/libqtpeer_la-qtimage.o .libs/libqtpeer_la-qtlabelpeer.o .libs/libqtpeer_la-qtlistpeer.o .libs/libqtpeer_la-qtmenubarpeer.o .libs/libqtpeer_la-qtmenucomponentpeer.o .libs/libqtpeer_la-qtmenuitempeer.o .libs/libqtpeer_la-qtmenupeer.o .libs/libqtpeer_la-qtpanelpeer.o .libs/libqtpeer_la-qtpopupmenupeer.o .libs/libqtpeer_la-qtscreendevice.o .libs/libqtpeer_la-qtscrollbarpeer.o .libs/libqtpeer_la-qtscrollpanepeer.o .libs/libqtpeer_la-qtstrings.o .libs/libqtpeer_la-qttextareapeer.o .libs/libqtpeer_la-qttextfieldpeer.o .libs/libqtpeer_la-qttoolkit.o .libs/libqtpeer_la-qtvolatileimage.o .libs/libqtpeer_la-qtwindowpeer.o .libs/libqtpeer_la-slotcallbacks.o -L/usr/lib/qt4 /usr/lib/qt4/libQtGui.so -L/usr/lib /usr/lib/libpng12.so /usr/lib/qt4/libQtCore.so -lpthread /usr/lib/libXrandr.so /usr/lib/libXcursor.so /usr/lib/libXrender.so /usr/lib/libXfixes.so /usr/lib/libxcb-xlib.so /usr/lib/libxcb.so /usr/lib/libXinerama.so /usr/lib/libfontconfig.so /usr/lib/libfreetype.so /usr/lib/libxml2.so -lz /usr/lib/libXext.so /usr/lib/libpulse.so /usr/lib/libSM.so /usr/lib/libICE.so /usr/lib/libX11.so /usr/lib/libXau.so /usr/lib/libXdmcp.so -lcap -lrt -ldl -latomic_ops -L/usr/lib/gcc/i686-pc-linux-gnu/4.2.3 -L/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/../../../../i686-pc-linux-gnu/lib -L/usr/lib/gcc/i686-pc-linux-gnu/4.2.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/crtendS.o /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/../../../crtn.o -Wl,--as-needed -Wl,-soname -Wl,libqtpeer.so -o .libs/libqtpeer.so libtool: link: ( cd .libs rm -f libqtpeer.la ln -s ../libqtpeer.la libqtpeer.la ) make[1]: Leaving directory `/mnt/checkouts/classpath/native/jni/qt-peer' --as-needed needs to come before the object files and libs to be effective but libtool moves it to the end. This happens with both 1.5.26 and cvs head. Regards, Petteri
Re: why does libtool reorder -Wl, arguments to the end making -Wl, --as-needed unusable
On Sun, Mar 02, 2008 at 07:42:53PM -0600, Albert Chin wrote: On Mon, Mar 03, 2008 at 02:02:09AM +0200, Petteri Räty wrote: Albert Chin kirjoitti: On Thu, Feb 28, 2008 at 03:17:54PM +0200, Petteri Räty wrote: [EMAIL PROTECTED] /mnt/checkouts/classpath/native/jni/qt-peer $ make make all-am make[1]: Entering directory `/mnt/checkouts/classpath/native/jni/qt-peer' /bin/sh ../../../libtool --tag=CXX --mode=link g++ -DQT_SHARED -I/usr/include/qt4 -I/usr/include/qt4/QtCore -I/usr/include/qt4/QtGui -g -O2 -module -version-info 0:0:0 -no-undefined -avoid-version -Wl,--as-needed -o libqtpeer.la -rpath /usr/local/classpath/lib/classpath ... [snip snip] --as-needed needs to come before the object files and libs to be effective but libtool moves it to the end. This happens with both 1.5.26 and cvs head. The fact that libtool reorders _any_ of the command-line is a bug. I think Ralf has a fix for this but I don't think it'll happen until 2.1 or 2.2. Still there in libtool 2.2 I forgot we skipped 2.0. So, that means I don't think it'll happen until 2.3 or 2.4 http://lists.gnu.org/archive/html/libtool-patches/2006-06/msg00033.html http://lists.gnu.org/archive/html/libtool-patches/2006-01/msg00061.html http://wiki.azazil.net/GnuLibtoolProject/RoadMap: Preserve the order of the command-line and make changes in-place, if required. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Validity of fake convenience library
I'm trying to use an internal static library from one project as a convenience library in another project. The problem is that the first project does not use libtool and the second does. So, there's no .la file and libtool complains about the portability of linking the static archive into another convenience library in the second project. My workaround was to create a fake .la file for the static library indicating that it's a convenience library. I just altered the names from a .la file that libtool had generated. Here's the commit: http://cgit.freedesktop.org/~dbn/mesa/diff/?h=xserver-glxid=6cad64b3 Is this a valid thing to do? What are the requirements for building a valid convenience library? -fPIC? What are the requirements for a valid .la file for a convenience library? Is there another option (besides libtoolizing the first project) that is more robust? I realize this is a pretty insane thing to do, but the chances that mesa will become libtoolized are exceedingly low. And the current handling of this situation is at least equally fragile. Thanks, -- Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Validity of fake convenience library
On Mon, Mar 3, 2008 at 5:37 PM, Peter O'Gorman [EMAIL PROTECTED] wrote: Please make sure that this fake .la file is only used in the build tree where it is needed (only when building xserver? Why not commit these bits to xserver then?). I would not like to see such a thing in /usr/lib (or /usr/X11/lib or whereever). Yeah, it wouldn't be installed (the actual libmesa.a library isn't either). So, here's the real quick story: when building GLX support in xserver, a software only driver (GLcore) is created so there is a fallback when there is no DRI driver available (the DRI drivers are built and installed in mesa). This driver is created using the internal libmesa library and other sources from mesa. To pull that off, the xserver has a mirror of the mesa directory structure and a bunch on nodist_*_SOURCES defined. The source files are symlinked in from a user-supplied mesa tree at configure time and then true convenience libraries are created. It's pretty ugly and breaks frequently. I'm trying to change it so that the build will just descend into mesa and it will handle building the necessary bits. Currently, the xserver breaks whenever any of the files change names in mesa. So, I suppose I could put the .la file in the xserver tree, but the reason I put it in mesa is because that's where the actual library would be my scenario. The requirements for a convenience archive are that its objects be built pic. Libtool has a pretty good idea how to do this with a large variety of platforms and compilers. I have not looked at Mesa in quite a while but I imagine that it also has this information for a number of platforms and compilers. More or less it does. Currently, there are a bunch of platform-specific makefile stubs where these values are hardcoded. I've recently added an autoconf generated configure, but it's really light on platform specifics as I'm pretty much gcc on x86 Linux all the time. Please do not hardcode -fpic/-fPIC, as that would limit the build to gcc, instead try to ensure that you know the correct pic flag for the compiler and platform that the user has. You should probably refuse to build this library for platforms and compiler combinations where you do not know the compiler flag to generate position independent code (even though pic may be the default). I was just looking through the pic code evaluation in libtool.m4 and not getting real excited about recreating that. It really would be preferable to use libtool itself to generate this. If it were possible to build it as part of the xserver then, since that uses libtool, all would be well, wouldn't it? Currently, it is generated in the xserver at the sacrifice that the xserver tree needs to stay in lockstep with mesa. I definitely would agree that using libtool would be better for the generation of the .la file. I'm wondering if faking the .la file is the lesser of the two evils if it means that building GLX in xserver would break less. An alternative would be to keep a libtooled copy of the mesa tree in xserver until such a time comes where GLX can be untangled from the internals of both mesa and xserver. Thanks for your reply. -- Dan ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Validity of fake convenience library
Dan Nicholson wrote: I was just looking through the pic code evaluation in libtool.m4 and not getting real excited about recreating that. In xserver's configure.ac you can, somewhere after AC_PROG_LIBTOOL, put something like: CC_PIC_FLAG=$lt_prog_compiler_pic CXX_PIC_FLAG=$lt_prog_compiler_pic_CXX AC_SUBST([CC_PIC_FLAG]) AC_SUBST([CXX_PIC_FLAG]) Then in the Makefile.am that descends into the mesa build, you can set these vars as arguments to make (I guess you already set CC etc this way?), and use them to build the pic objects. I am pretty sure that you can similarly avoid the need for a fake convenience .la, but can not work it out without actually attempting a build :) Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Validity of fake convenience library
[EMAIL PROTECTED] wrote: On Mon, 3 Mar 2008, Peter O'Gorman - [EMAIL PROTECTED] wrote: I am pretty sure that you can similarly avoid the need for a fake convenience .la, but can not work it out without actually attempting a build :) On a related note, I'm working with a non-libtool library (we'll call it x) that ships libxz.a and libx.so. So a static build uses -lxz and a shared build uses -lx. To use this in an autotools project, I wrote a libmy_x.la.in with @variables@ to be determined by the configure script. Thus both flavors can now specify -lmy_x. Is there a better way to handle libs with different static/shared names, or is this another place where the fake convenience library is appropriate? Please do not respond to me directly, instead ask on the list. Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Validity of fake convenience library
On Mon, 3 Mar 2008, Peter O'Gorman - [EMAIL PROTECTED] wrote: I am pretty sure that you can similarly avoid the need for a fake convenience .la, but can not work it out without actually attempting a build :) On a related note, I'm working with a non-libtool library (we'll call it x) that ships libxz.a and libx.so. So a static build uses -lxz and a shared build uses -lx. To use this in an autotools project, I wrote a libmy_x.la.in with @variables@ to be determined by the configure script. Thus both flavors can now specify -lmy_x. Is there a better way to handle libs with different static/shared names, or is this another place where the fake convenience library is appropriate? Thanks, Daniel ___ http://lists.gnu.org/mailman/listinfo/libtool
