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
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 libtoo
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-glx&id=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
Dan Nicholson wrote: > 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-glx&id=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. Hi Dan, 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). 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. 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). 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? Peter -- Peter O'Gorman http://pogma.com ___ 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
