tag:old.nabble.com,2006:forum-1713Nabble - Gnu - Libtool2009-12-19T14:22:19ZGNU libtool is a generic library support script. Libtool hides the complexity of using shared libraries behind a consistent, portable interface. Gnu - Libtool home is <a href="http://www.gnu.org/software/libtool/libtool.html" target="_top" rel="nofollow">here</a>.tag:old.nabble.com,2006:post-26859429BUG: can't load DBI.so2009-12-19T14:22:19Z2009-12-19T14:22:19ZEugen Konkov-2Здравствуйте, Bug-libtool.
<br><br>>> radiusd -X
<br>>> Can't load '/usr/local/lib/perl5/5.10.1/mach/auto/Data/Dumper/Dumper.so' for module Data::Dumper: /usr/local/lib/perl5/5.10.1/mach/auto/Data/Dumper/Dumper.so: Undefined symbol "PL_sv_undef" at /usr/local/lib/perl5/5.10.1/mach/XSLoader.pm line 70.
<br>>> at /usr/local/lib/perl5/5.10.1/mach/Data/Dumper.pm line 36
<br><br>AD> It turns out this is largely a bug in libltl. (Of course).
<br><br>AD> We won't be able to address it directly in 2.1.8, but you should be
<br>AD> able to do minor modifications to 2.1.8 that will fix it.
<br>AD> Alan DeKok.
<br><br>How to fix that bug?
<br><br>--
<br>С уважением,
<br> Eugen mailto:<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26859429&i=0" target="_top" rel="nofollow">Eugen.Konkov@...</a>
<br><br><br><br>_______________________________________________
<br>Bug-libtool mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26859429&i=1" target="_top" rel="nofollow">Bug-libtool@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Bugs-f1715.html" embed="fixTarget[1715]" target="_top" rel="nofollow">Gnu - Libtool - Bugs</a></p>tag:old.nabble.com,2006:post-26851123Re: pthreads infection2009-12-18T15:23:44Z2009-12-18T15:23:44ZBob FriesenhahnOn Fri, 18 Dec 2009, Matěj Týč wrote:
<br><br>> Hello,
<br>> if I link to a library that uses pthreads (for example OpenEXR suggests
<br>> the -pthreads LDFLAG -- taken from OpenEXR.pc pkg-config file), I can
<br>> see that unlike library dependencies this dependency propagates further
<br>> like some disease. Even if my product is a library or a module, not only
<br><br>As I recall, considerable effort was expended to spread this disease.
<br><br>From reading your text I am a bit confused over exactly what the
<br>problem is, but I gather that you don't want your program to need to
<br>be built as a thread-safe application in order to link with a
<br>(possibly) multi-threaded library. You would rather that
<br>thread-safety be lost in the interest of convenience and expedience.
<br><br>What exactly is the bug?
<br><br>Bob
<br>--
<br>Bob Friesenhahn
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26851123&i=0" target="_top" rel="nofollow">bfriesen@...</a>, <a href="http://www.simplesystems.org/users/bfriesen/" target="_top" rel="nofollow">http://www.simplesystems.org/users/bfriesen/</a><br>GraphicsMagick Maintainer, <a href="http://www.GraphicsMagick.org/" target="_top" rel="nofollow">http://www.GraphicsMagick.org/</a><br />_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26849913pthreads infection2009-12-18T13:24:10Z2009-12-18T13:24:10ZMatěj TýčHello,
<br>if I link to a library that uses pthreads (for example OpenEXR suggests
<br>the -pthreads LDFLAG -- taken from OpenEXR.pc pkg-config file), I can
<br>see that unlike library dependencies this dependency propagates further
<br>like some disease. Even if my product is a library or a module, not only
<br>that I have to provide the -pthreads LDFLAG during (library / module)
<br>compilation, but the app (that uses the produced library / opens that
<br>module) also has to be linked with the -pthread LDFLAG.
<br>The problem is that libtool doesn't seem to discover this problematic
<br>dependency and forgets to add the appropriate flag to the app that is
<br>known to use the library (that uses the -pthreads flag) when the
<br>library's .la file is present. Is this a bug that can be fixed, or does
<br>it have some "normal solution"?
<br>However, in a case of a module, there is generally no way that I can
<br>determine whether my app will have to open such pthreads-infected
<br>module.
<br>Therefore I could add the -pthread flag as some "prevenive measure", but
<br>it is not quite portable, is it?
<br>I have took a look at gnulib and AFAIK it doesn't address this issue
<br>either. I think that I am supposed to use mthreads on Windows or
<br>something like that.
<br>Any suggestions?
<br>Regards,
<br>Matej
<br><br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26842412libtool changes argv[0]2009-12-18T03:32:44Z2009-12-18T03:32:44ZJoakim Tjernlund-2<br>Now that I am using libtool's .la objects when build our apps
<br>we notice that the executables in the build tree becomes
<br>a script that run the binary form the .libs subdir.
<br>This has the side effect that out apps notices a change in argv[0]
<br>when we run them from within the build tree.
<br>Previously argv[0] was x/y/z, now it becomes x/y/.libs/z and
<br>our apps does not like that.
<br>Is it possible to do something about the change of argv[0]?
<br><br>libtool version 2.2.6b, gentoo
<br><br> Jocke
<br><br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26841678Re: libtool 2.2.6 on HP-UX, with DESTDIR, installs lt wrapper instead of real binary2009-12-18T02:26:13Z2009-12-18T02:26:13ZRiver Tarnell-5River Tarnell:
<br>> > We've had proposed patches to get libtool with DESTDIR to work on
<br>> > HP-UX but they were problematic in some respect (see the archives of
<br>> > the libtool-patches list); I don't recall however if the issues were
<br>> > the same as what you are seeing.
<br>
<br>> Thanks. I'll have a look at these and see if any of them help.
<br><br>Okay, so I took libtool from git, and applied this patch:
<br> <<a href="http://lists.gnu.org/archive/html/libtool-patches/2009-07/msg00009.html" target="_top" rel="nofollow">http://lists.gnu.org/archive/html/libtool-patches/2009-07/msg00009.html</a>>
<br>libtool now seems to work correctly: the real binary is installed, and
<br>it's linked with the right library, which has the correct soname from
<br>the real installation path.
<br><br>It would be very nice to have this patch in the next libtool release.
<br>While it might not be complete, it's a lot better than the current
<br>situation on HP-UX (where I would say libtool is almost useless, since
<br>$DESTDIR is a pretty important feature for building packages).
<br><br> - river.
<br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26840349Re: relinking and finish warnings2009-12-17T23:45:55Z2009-12-17T23:45:55ZRalf Wildenhues* Joakim Tjernlund wrote on Thu, Dec 17, 2009 at 08:57:07AM CET:
<br>> Ralf Wildenhues wrote on 16/12/2009 22:56:44:
<br>> > > Also, how do i get rid of the "remember to run `libtool --finish" warning?
<br>> >
<br>> > You don't, that warning is not bogus. If you don't run libtool --finish
<br>> > yourself (when the libraries appear in their final location), it may be
<br>> > that the installed libraries are not usable before the next reboot (at
<br>> > which time systems typically run ldconfig).
<br>>
<br>> OK, then I will go back to using prefix=$(DESTDIR)/opt/appl/xxx instead.
<br><br>Huh? That's even more wrong, as it will put the wrong paths in the
<br>installed files (both the .la files, and in DT_RPATH entries for
<br>programs and libraries linking against your libraries)! You may just
<br>have to get used to the fact that after a DESTDIR installation, things
<br>are, _out of necessity_, not finished yet. There is no other way.
<br><br>> I have noticed though that one should be able to "hardcode" rpath but I haven't
<br>> figured out how to do that in configure/configure.ac, any pointers?
<br><br>Run paths are automatically hard-coded for libtool deplibs that are not
<br>in directories the runtime linker searches by default.
<br><br>You can add run paths by using -R DIR in the link flags.
<br><br>Cheers,
<br>Ralf
<br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26837802sys_lib_dlsearch_path_spec set incorrectly on 64bit linux with /usr/lib642009-12-17T13:44:36Z2009-12-17T13:44:36ZJohn Lightsey-3Hello,
<br><br>I found a thread on the libtool mailing list where this problem was
<br>discussed in Jan 2009.
<br><br><a href="http://lists.gnu.org/archive/html/libtool/2009-01/msg00039.html" target="_top" rel="nofollow">http://lists.gnu.org/archive/html/libtool/2009-01/msg00039.html</a><br><br>The thread ends with the puzzling comment "The dynamic linker's search
<br>path is not of much importance when linking" and it looks as if the
<br>problem was never corrected in libtool. From what I can tell, the
<br>dynamic linker on GNU/Linux does not skip entries in its own search path
<br>when it sees them listed in the RPATH.
<br><br>Having the wrong sys_lib_dlsearch_path_spec causes problems when
<br>different versions of the same library are installed with one in the
<br>system library path and one in a custom location.
<br><br>For example, I have different versions of libxml2 in /usr/lib64
<br>and /opt/newlibxml2/lib64 and want to link to the version
<br>in /opt/newlibxml2. Libtool doesn't consider /usr/lib64 to be in the
<br>default search path so I just have to hope that libtool doesn't
<br>add /usr/lib64 earlier than /opt/newlibxml2/lib64 in the RPATH for the
<br>benefit of some other library.
<br><br>I noticed this problem cropping up with the PHP 5.2.12 libtool.m4 update
<br>from serial 47 to serial 52. It looks like the problem remains in the
<br>latest daily snapshot that is available (2.2.7a from 3 Dec 2009, serial
<br>56.)
<br><br>I've seen the same issue in the past with FreeBSD systems
<br>since /usr/local/lib isn't added to sys_lib_dlsearch_path_spec there and
<br>it's the standard location for ports to install new libraries. That
<br>always seemed to be a reasonably understandable quirk of libtool though.
<br><br><br>Thanks for the terrific sotware.
<br><br><br><br><br>_______________________________________________
<br>Bug-libtool mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26837802&i=0" target="_top" rel="nofollow">Bug-libtool@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Bugs-f1715.html" embed="fixTarget[1715]" target="_top" rel="nofollow">Gnu - Libtool - Bugs</a></p>tag:old.nabble.com,2006:post-26826047Re: A problem with executable wrapper2009-12-17T02:32:06Z2009-12-17T02:32:06ZRafał Mużyło-2On Thu, Dec 17, 2009 at 07:24:51AM +0100, Ralf Wildenhues wrote:
<br>> > I'm not sure if I'm subscribed,
<br>> > so treat it as if I'm not (CC me).
<br>>
<br>> You are, as far as I can see.
<br>>
<br>Regardless, CC me, as mail delivery is off.
<br>> Can you show the link command line for this program/wrapper, and all of
<br>> its output with --debug added as first argument to ../libtool; also,
<br>> please show
<br>> ./libtool --config
<br>>
<br>> and whether you have set LD_LIBRARY_PATH in your environment.
<br>Seems it's coming from one of system la files' libdir line
<br>(one more argument for policy of forcing their removal).
<br><br>LD_LIBRARY_PATH is unset.
<br>/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o ghex2
<br>hex-document-ui.o preferences.o findreplace.o converter.o config.o
<br>main.o ui.o chartable.o session.o print.o ghex-window.o factory.o
<br>hex-dialog.o -pthread -lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2
<br>-lgnomecanvas-2 -lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation
<br>-lORBit-2 -lart_lgpl_2 -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0
<br>-lpangoft2-1.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0
<br>-lfreetype -lfontconfig -lgconf-2 -lgthread-2.0 -lrt -lgmodule-2.0
<br>-lgobject-2.0 -lglib-2.0 libgtkhex.la/bin/sh ../libtool --debug
<br>--tag=CC --mode=link gcc -g -O2 -o ghex2 hex-document-ui.o
<br>preferences.o findreplace.o converter.o config.o main.o ui.o chartable.o
<br>session.o print.o ghex-window.o factory.o hex-dialog.o -pthread
<br>-lgnomeui-2 -lSM -lICE -lbonoboui-2 -lgnomevfs-2 -lgnomecanvas-2
<br>-lgnome-2 -lpopt -lbonobo-2 -lbonobo-activation -lORBit-2 -lart_lgpl_2
<br>-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0
<br>-lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpango-1.0 -lfreetype
<br>-lfontconfig -lgconf-2 -lgthread-2.0 -lrt -lgmodule-2.0 -lgobject-2.0
<br>-lglib-2.0 libgtkhex.la
<br><br>Attached debug output is for the modified ltmain.sh
<br>script libtool - that change only affects the order.
<br><br><br /> <br />_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>ghex2.link.bz2</strong> (83K) <a href="http://old.nabble.com/attachment/26826047/0/ghex2.link.bz2" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26825387Re: Upgrading libtool failure on SLES 10 sp22009-12-17T01:34:15Z2009-12-17T01:34:15ZAlan2<br><blockquote class="quote light-black dark-border-color"><div class="quote light-border-color">
<div class="quote-author" style="font-weight: bold;">Ralf Wildenhues wrote:</div>
<div class="quote-message shrinkable-quote">Hello Alan,
<br><br>* Alan2 wrote on Wed, Dec 16, 2009 at 04:25:18PM CET:
<br>>
<br>> Hi, not sure of this is the right place to post, but I am having trouble
<br>> upgrading my libtool from version 1.5.26 to 2.2.6b. Here is a copy of the
<br>> configure and make attempt:
<br>[...]
<br>> config.status: executing libtool commands
<br>> /bin/rm: cannot remove `libtoolT': No such file or directory
<br><br>Do you have $RM set in your environment? Try to unset it, or set it to
<br>'rm -f' or so.
<br><br>Cheers,
<br>Ralf
<br><br><br>_______________________________________________
<br>Bug-libtool mailing list
<br>Bug-libtool@gnu.org
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-libtool</a></div>
</div></blockquote>
Thanks Ralf, that did the trick.
<br><br>Regards
<br>Alan<p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Bugs-f1715.html" embed="fixTarget[1715]" target="_top" rel="nofollow">Gnu - Libtool - Bugs</a></p>tag:old.nabble.com,2006:post-26824498Re: relinking and finish warnings2009-12-16T23:57:07Z2009-12-16T23:57:07ZJoakim Tjernlund-2Ralf Wildenhues <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26824498&i=0" target="_top" rel="nofollow">Ralf.Wildenhues@...</a>> wrote on 16/12/2009 22:56:44:
<br><div class='shrinkable-quote'><br>> From: Ralf Wildenhues <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26824498&i=1" target="_top" rel="nofollow">Ralf.Wildenhues@...</a>>
<br>> To: Joakim Tjernlund <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26824498&i=2" target="_top" rel="nofollow">joakim.tjernlund@...</a>>
<br>> Cc: <a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26824498&i=3" target="_top" rel="nofollow">libtool@...</a>
<br>> Date: 16/12/2009 22:56
<br>> Subject: Re: relinking and finish warnings
<br>>
<br>> Hello Joakim,
<br>>
<br>> * Joakim Tjernlund wrote on Wed, Dec 16, 2009 at 06:15:53PM CET:
<br>> >
<br>> > If I specify a dependency lib like this:
<br>> > libucsiif_la_LIBADD = $(top_builddir)/ne/upc_uci_if/libuciif.la
<br>> > I get a relink warning:
<br>>
<br>> The warning should be a note. The note is necessary because users are
<br>> otherwise likely surprised that the compiler/linker is run upon 'make
<br>> install'.
<br>>
<br>> > But I do like this instead:
<br>> > libucsiif_la_LIBADD = $(DESTDIR)$(libdir)/libuciif.so
<br>>
<br>> That's bogus, and will be wrong when you don't have a preinstalled
<br>> library there.
<br>>
<br>> > Also, how do i get rid of the "remember to run `libtool --finish" warning?
<br>>
<br>> You don't, that warning is not bogus. If you don't run libtool --finish
<br>> yourself (when the libraries appear in their final location), it may be
<br>> that the installed libraries are not usable before the next reboot (at
<br>> which time systems typically run ldconfig).
</div><br>OK, then I will go back to using prefix=$(DESTDIR)/opt/appl/xxx instead.
<br><br>I have noticed though that one should be able to "hardcode" rpath but I haven't
<br>figured out how to do that in configure/configure.ac, any pointers?
<br><br> Jocke
<br><br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26823942Re: libtool 2.2.6 on HP-UX, with DESTDIR, installs lt wrapper instead of real binary2009-12-16T22:45:03Z2009-12-16T22:45:03ZRiver Tarnell-5Ralf Wildenhues:
<br>> Please post a link to a tarball that shows this problem. Thanks.
<br>
<br><a href="http://switch.dl.sourceforge.net/project/expat/expat/2.0.1/expat-2.0.1.tar.gz" target="_top" rel="nofollow">http://switch.dl.sourceforge.net/project/expat/expat/2.0.1/expat-2.0.1.tar.gz</a><br><br>> Is this only a problem with DESTDIR?
<br><br>Yes. If I build like this:
<br><br>% ./configure --prefix=$HOME/expat
<br>% make
<br>% make install
<br><br>Then the resulting xmlwf is the real binary, not a wrapper script.
<br><br>> We've had proposed patches to get libtool with DESTDIR to work on
<br>> HP-UX but they were problematic in some respect (see the archives of
<br>> the libtool-patches list); I don't recall however if the issues were
<br>> the same as what you are seeing.
<br><br>Thanks. I'll have a look at these and see if any of them help.
<br><br> - river.
<br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26823822Re: libtool 2.2.6 on HP-UX, with DESTDIR, installs lt wrapper instead of real binary2009-12-16T22:33:05Z2009-12-16T22:33:05ZRalf WildenhuesHello River,
<br><br>* River Tarnell wrote on Thu, Dec 17, 2009 at 05:02:14AM CET:
<br>> I'm using libtool 2.2.6 on HP-UX 11.11 to build Expat (an XML parser).
<br>> Expat is a fairly simple project: it has one library (libexpat) and an
<br>> executable (xmlwf) that links to this library. I've already updated the
<br>> libtool that comes with Expat to 2.2.6 to fix this problem, but it
<br>> didn't help.
<br><br>Please post a link to a tarball that shows this problem. Thanks.
<br><br>Is this only a problem with DESTDIR? We've had proposed patches to get
<br>libtool with DESTDIR to work on HP-UX but they were problematic in some
<br>respect (see the archives of the libtool-patches list); I don't recall
<br>however if the issues were the same as what you are seeing.
<br><br>Cheers,
<br>Ralf
<br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26823785Re: A problem with executable wrapper2009-12-16T22:24:51Z2009-12-16T22:24:51ZRalf WildenhuesHello Rafał,
<br><br>* Rafał Mużyło wrote on Wed, Dec 16, 2009 at 11:19:01PM CET:
<br>> I'm not sure if I'm subscribed,
<br>> so treat it as if I'm not (CC me).
<br><br>You are, as far as I can see.
<br><br>> I was playing with ghex2 sources.
<br>> After 'autoreconf -fi;./configure', I've noticed
<br>> a small problem with the wrapper script generated for the executable.
<br>> One of generated blocks was:
<br>>
<br>> # Add our own library path to LD_LIBRARY_PATH
<br>> LD_LIBRARY_PATH="/usr/lib/:<top_builddir>/src/.libs:$LD_LIBRARY_PATH"
<br><br>Can you show the link command line for this program/wrapper, and all of
<br>its output with --debug added as first argument to ../libtool; also,
<br>please show
<br> ./libtool --config
<br><br>and whether you have set LD_LIBRARY_PATH in your environment.
<br><br>Thanks,
<br>Ralf
<br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26822774libtool 2.2.6 on HP-UX, with DESTDIR, installs lt wrapper instead of real binary2009-12-16T20:02:14Z2009-12-16T20:02:14ZRiver Tarnell-5Hi,
<br><br>I'm using libtool 2.2.6 on HP-UX 11.11 to build Expat (an XML parser).
<br>Expat is a fairly simple project: it has one library (libexpat) and an
<br>executable (xmlwf) that links to this library. I've already updated the
<br>libtool that comes with Expat to 2.2.6 to fix this problem, but it
<br>didn't help.
<br><br>I'm building a standard package, like this:
<br><br>% ./configure --prefix=/opt/rt
<br>% make
<br>% make install DESTDIR=$HOME/expat
<br><br>However, libtool refuses to install the real xmlwf binary into $DESTDIR, and
<br>instead installs the wrapper script:
<br><br> /bin/sh ./libtool --mode=install conftools/install-sh -c xmlwf/xmlwf /home/river/expat/opt/rt/bin/xmlwf
<br>libtool: install: warning: `libexpat.la' has not been installed in `/opt/rt/lib'
<br>libtool: install: warning: cannot relink `xmlwf/xmlwf'
<br>libtool: install: conftools/install-sh -c xmlwf/xmlwf /home/river/expat/opt/rt/bin/xmlwf
<br><br>% file ~/expat/opt/rt/bin/xmlwf
<br>/home/river/expat/opt/rt/bin/xmlwf: commands text
<br><br>I understand what libtool is trying to do here, but I don't *want* it to
<br>relink the binary; when I produce a package from the $DESTDIR staging
<br>area, the library will be installed in /opt/rt/lib as expected. The
<br>fact that the binary won't work when run from $DESTDIR is a non-issue.
<br><br>I'm about to just remove libtool entirely and put native commands to
<br>build the library in Expat's Makefile, but before I do that, is this a
<br>known issue, and if so, is there a fix or workaround?
<br><br>I've seen a few references to this issue on Google (mostly on HP-UX),
<br>but no actual solutions.
<br><br>Thanks,
<br>River.
<br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26819499A problem with executable wrapper2009-12-16T14:19:01Z2009-12-16T14:19:01ZRafał Mużyło-2I'm not sure if I'm subscribed,
<br>so treat it as if I'm not (CC me).
<br><br>Linux (x86), libtool 2.2.6b, autoconf 2.64, automake 1.11
<br><br>I was playing with ghex2 sources.
<br>After 'autoreconf -fi;./configure', I've noticed
<br>a small problem with the wrapper script generated for the executable.
<br>One of generated blocks was:
<br><br># Add our own library path to LD_LIBRARY_PATH
<br>LD_LIBRARY_PATH="/usr/lib/:<top_builddir>/src/.libs:$LD_LIBRARY_PATH"
<br><br>However, that created a problem, as ghex2 was already installed
<br>on the system, so executable was using system copy of its lib,
<br>instead of the one just built.
<br><br>To get around this, I've modified a line in ltmain.sh from:
<br>*) temp_rpath="$temp_rpath$absdir:"
<br>to
<br>*) temp_rpath="$absdir:$temp_rpath"
<br>but I wonder why it wasn't working properly in the first place.
<br><br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26819211Re: Upgrading libtool failure on SLES 10 sp22009-12-16T13:59:23Z2009-12-16T13:59:23ZRalf WildenhuesHello Alan,
<br><br>* Alan2 wrote on Wed, Dec 16, 2009 at 04:25:18PM CET:
<br>>
<br>> Hi, not sure of this is the right place to post, but I am having trouble
<br>> upgrading my libtool from version 1.5.26 to 2.2.6b. Here is a copy of the
<br>> configure and make attempt:
<br>[...]
<br>> config.status: executing libtool commands
<br>> /bin/rm: cannot remove `libtoolT': No such file or directory
<br><br>Do you have $RM set in your environment? Try to unset it, or set it to
<br>'rm -f' or so.
<br><br>Cheers,
<br>Ralf
<br><br><br>_______________________________________________
<br>Bug-libtool mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26819211&i=0" target="_top" rel="nofollow">Bug-libtool@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Bugs-f1715.html" embed="fixTarget[1715]" target="_top" rel="nofollow">Gnu - Libtool - Bugs</a></p>tag:old.nabble.com,2006:post-26819177Re: relinking and finish warnings2009-12-16T13:56:44Z2009-12-16T13:56:44ZRalf WildenhuesHello Joakim,
<br><br>* Joakim Tjernlund wrote on Wed, Dec 16, 2009 at 06:15:53PM CET:
<br>>
<br>> If I specify a dependency lib like this:
<br>> libucsiif_la_LIBADD = $(top_builddir)/ne/upc_uci_if/libuciif.la
<br>> I get a relink warning:
<br><br>The warning should be a note. The note is necessary because users are
<br>otherwise likely surprised that the compiler/linker is run upon 'make
<br>install'.
<br><br>> But I do like this instead:
<br>> libucsiif_la_LIBADD = $(DESTDIR)$(libdir)/libuciif.so
<br><br>That's bogus, and will be wrong when you don't have a preinstalled
<br>library there.
<br><br>> Also, how do i get rid of the "remember to run `libtool --finish" warning?
<br><br>You don't, that warning is not bogus. If you don't run libtool --finish
<br>yourself (when the libraries appear in their final location), it may be
<br>that the installed libraries are not usable before the next reboot (at
<br>which time systems typically run ldconfig).
<br><br>Cheers,
<br>Ralf
<br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26814931relinking and finish warnings2009-12-16T09:15:53Z2009-12-16T09:15:53ZJoakim Tjernlund-2<br>If I specify a dependency lib like this:
<br> libucsiif_la_LIBADD = $(top_builddir)/ne/upc_uci_if/libuciif.la
<br>I get a relink warning:
<br><br>make[1]: Entering directory `/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/ne/upc_ucsi_if'
<br>test -z "/opt/appl/tuappl02a-r15a-091216jt4/lib" || /bin/mkdir -p "/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/opt/appl/tuappl02a-r15a-091216jt4/lib"
<br> /usr/bin/install -c -m 644 'libucsiif.a' '/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/opt/appl/tuappl02a-r15a-091216jt4/lib/libucsiif.a'
<br> powerpc-softfloat-linux-gnu-ranlib '/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/opt/appl/tuappl02a-r15a-091216jt4/lib/libucsiif.a'
<br>test -z "/opt/appl/tuappl02a-r15a-091216jt4/lib" || /bin/mkdir -p "/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/opt/appl/tuappl02a-r15a-091216jt4/lib"
<br> /bin/sh ../../libtool --silent --mode=install /usr/bin/install -c 'libucsiif.la' '/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/opt/appl/tuappl02a-r15a-091216jt4/lib/libucsiif.la'
<br>libtool: install: warning: relinking `libucsiif.la'
<br>libtool: relink: powerpc-softfloat-linux-gnu-gcc -shared .libs/libucsiif_la-up_common_ucsi.o -Wl,-rpath -Wl,/opt/appl/tuappl02a-r15a-091216jt4/lib -L/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/opt/appl/tuappl02a-r15a-091216jt4/lib -L/opt/appl/tuappl02a-r15a-091216jt4/lib -luciif -mstring
<br>-mmultiple -msdata=none -Wl,-soname -Wl,libucsiif.so.1 -o .libs/libucsiif.so.1.0.0
<br>libtool: install: warning: remember to run `libtool --finish /opt/appl/tuappl02a-r15a-091216jt4/lib'
<br><br>But I do like this instead:
<br> libucsiif_la_LIBADD = $(DESTDIR)$(libdir)/libuciif.so
<br>I get:
<br><br>make[1]: Entering directory `/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/ne/upc_ucsi_if'
<br>test -z "/opt/appl/tuappl02a-r15a-091216jt4/lib" || /bin/mkdir -p "/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/opt/appl/tuappl02a-r15a-091216jt4/lib"
<br> /usr/bin/install -c -m 644 'libucsiif.a' '/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/opt/appl/tuappl02a-r15a-091216jt4/lib/libucsiif.a'
<br> powerpc-softfloat-linux-gnu-ranlib '/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/opt/appl/tuappl02a-r15a-091216jt4/lib/libucsiif.a'
<br>test -z "/opt/appl/tuappl02a-r15a-091216jt4/lib" || /bin/mkdir -p "/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/opt/appl/tuappl02a-r15a-091216jt4/lib"
<br> /bin/sh ../../libtool --silent --mode=install /usr/bin/install -c 'libucsiif.la' '/usr/local/src/TM-t2/BUILD/tuappl02a/powerpc-linux/opt/appl/tuappl02a-r15a-091216jt4/lib/libucsiif.la'
<br>libtool: install: warning: remember to run `libtool --finish /opt/appl/tuappl02a-r15a-091216jt4/lib'
<br><br>No relink warning. However I get the impression that I should use the first form
<br>so I guess I do something wrong, but what?
<br><br>Also, how do i get rid of the "remember to run `libtool --finish" warning?
<br><br>libtool 2.2.6b, gentoo.
<br><br> Jocke
<br><br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26812852Upgrading libtool failure on SLES 10 sp22009-12-16T07:25:17Z2009-12-16T07:25:17ZAlan2Hi, not sure of this is the right place to post, but I am having trouble upgrading my libtool from version 1.5.26 to 2.2.6b. Here is a copy of the configure and make attempt:
<br><br>alan@stratford:~/libtool/libtool-2.2.6b 63% libtool --version
<br>ltmain.sh (GNU libtool) 1.5.26 (1.1220.2.492 2008/01/30 06:40:56)
<br><br>Copyright (C) 2008 Free Software Foundation, Inc.
<br>This is free software; see the source for copying conditions. There is NO
<br>warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
<br>alan@stratford:~/libtool/libtool-2.2.6b 64% ./configure
<br>## -------------------------- ##
<br>## Configuring libtool 2.2.6b ##
<br>## -------------------------- ##
<br><br>checking for a BSD-compatible install... /usr/bin/install -c
<br>checking whether build environment is sane... yes
<br>checking for a thread-safe mkdir -p... /bin/mkdir -p
<br>checking for gawk... /usr/bin/awk
<br>checking whether make sets $(MAKE)... yes
<br>checking whether subdir libobjs are useable... yes
<br>checking for gcc... gcc
<br>checking for C compiler default output file name... a.out
<br>checking whether the C compiler works... yes
<br>checking whether we are cross compiling... no
<br>checking for suffix of executables...
<br>checking for suffix of object files... o
<br>checking whether we are using the GNU C compiler... yes
<br>checking whether gcc accepts -g... yes
<br>checking for gcc option to accept ISO C89... none needed
<br>checking for style of include used by make... GNU
<br>checking dependency style of gcc... gcc3
<br>checking whether gcc and cc understand -c and -o together... yes
<br>checking how to run the C preprocessor... gcc -E
<br>checking build system type... x86_64-unknown-linux-gnu
<br>checking host system type... x86_64-unknown-linux-gnu
<br>checking for a sed that does not truncate output... /usr/bin/sed
<br>checking for grep that handles long lines and -e... /usr/bin/grep
<br>checking for egrep... /usr/bin/grep -E
<br>checking for fgrep... /usr/bin/grep -F
<br>checking for ld used by gcc... /usr/x86_64-suse-linux/bin/ld
<br>checking if the linker (/usr/x86_64-suse-linux/bin/ld) is GNU ld... yes
<br>checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
<br>checking the name lister (/usr/bin/nm -B) interface... BSD nm
<br>checking whether ln -s works... yes
<br>checking the maximum length of command line arguments... 98304
<br>checking whether the shell understands some XSI constructs... yes
<br>checking whether the shell understands "+="... yes
<br>checking for /usr/x86_64-suse-linux/bin/ld option to reload object files... -r
<br>checking for objdump... objdump
<br>checking how to recognize dependent libraries... pass_all
<br>checking for ar... ar
<br>checking for strip... strip
<br>checking for ranlib... ranlib
<br>checking command to parse /usr/bin/nm -B output from gcc object... ok
<br>checking for ANSI C header files... yes
<br>checking for sys/types.h... yes
<br>checking for sys/stat.h... yes
<br>checking for stdlib.h... yes
<br>checking for string.h... yes
<br>checking for memory.h... yes
<br>checking for strings.h... yes
<br>checking for inttypes.h... yes
<br>checking for stdint.h... yes
<br>checking for unistd.h... yes
<br>checking for dlfcn.h... yes
<br>checking for objdir... .libs
<br>checking if gcc supports -fno-rtti -fno-exceptions... no
<br>checking for gcc option to produce PIC... -fPIC -DPIC
<br>checking if gcc PIC flag -fPIC -DPIC works... yes
<br>checking if gcc static flag -static works... yes
<br>checking if gcc supports -c -o file.o... /bin/rm: cannot remove `conftest*': No such file or directory
<br>yes
<br>checking if gcc supports -c -o file.o... (cached) yes
<br>checking whether the gcc linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
<br>checking whether -lc should be explicitly linked in... /bin/rm: cannot remove `conftest*': No such file or directory
<br>no
<br>checking dynamic linker characteristics... GNU/Linux ld.so
<br>checking how to hardcode library paths into programs... immediate
<br>checking for shl_load... no
<br>checking for shl_load in -ldld... no
<br>checking for dlopen... no
<br>checking for dlopen in -ldl... yes
<br>checking whether a program can dlopen itself... yes
<br>checking whether a statically linked program can dlopen itself... no
<br>checking whether stripping libraries is possible... yes
<br>checking if libtool supports shared libraries... yes
<br>checking whether to build shared libraries... yes
<br>checking whether to build static libraries... yes
<br>checking which extension is used for runtime loadable modules... .so
<br>checking which variable specifies run-time module search path... LD_LIBRARY_PATH
<br>checking for the default library search path... /lib /usr/lib /usr/X11R6/lib64/Xaw3d /usr/X11R6/lib64 /usr/X11R6/lib/Xaw3d /usr/X11R6/lib /usr/x86_64-suse-linux/lib /usr/local/lib /opt/kde3/lib /opt/gnome/lib /lib64 /lib /usr/lib64 /usr/lib /usr/local/lib64 /opt/kde3/lib64 /opt/gnome/lib64
<br>checking for library containing dlopen... -ldl
<br>checking for dlerror... yes
<br>checking for shl_load... (cached) no
<br>checking for shl_load in -ldld... (cached) no
<br>checking for dld_link in -ldld... no
<br>checking for _ prefix in compiled symbols... no
<br>checking whether deplibs are loaded by dlopen... yes
<br>checking for argz.h... yes
<br>checking for error_t... yes
<br>checking for argz_add... yes
<br>checking for argz_append... yes
<br>checking for argz_count... yes
<br>checking for argz_create_sep... yes
<br>checking for argz_insert... yes
<br>checking for argz_next... yes
<br>checking for argz_stringify... yes
<br>checking if argz actually works... yes
<br>checking whether libtool supports -dlopen/-dlpreopen... yes
<br>checking for unistd.h... (cached) yes
<br>checking for dl.h... no
<br>checking for sys/dl.h... no
<br>checking for dld.h... no
<br>checking for mach-o/dyld.h... no
<br>checking for dirent.h... yes
<br>checking for closedir... yes
<br>checking for opendir... yes
<br>checking for readdir... yes
<br>checking for strlcat... no
<br>checking for strlcpy... no
<br>checking for g++... g++
<br>checking whether we are using the GNU C++ compiler... yes
<br>checking whether g++ accepts -g... yes
<br>checking dependency style of g++... gcc3
<br>checking how to run the C++ preprocessor... g++ -E
<br>checking for ld used by g++... /usr/x86_64-suse-linux/bin/ld -m elf_x86_64
<br>checking if the linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) is GNU ld... yes
<br>checking whether the g++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
<br>checking for g++ option to produce PIC... -fPIC -DPIC
<br>checking if g++ PIC flag -fPIC -DPIC works... yes
<br>checking if g++ static flag -static works... yes
<br>checking if g++ supports -c -o file.o... /bin/rm: cannot remove `conftest*': No such file or directory
<br>yes
<br>checking if g++ supports -c -o file.o... (cached) yes
<br>checking whether the g++ linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
<br>checking dynamic linker characteristics... GNU/Linux ld.so
<br>checking how to hardcode library paths into programs... immediate
<br>checking for g77... no
<br>checking for xlf... no
<br>checking for f77... no
<br>checking for frt... no
<br>checking for pgf77... no
<br>checking for cf77... no
<br>checking for fort77... no
<br>checking for fl32... no
<br>checking for af77... no
<br>checking for xlf90... no
<br>checking for f90... no
<br>checking for pgf90... no
<br>checking for pghpf... no
<br>checking for epcf90... no
<br>checking for gfortran... gfortran
<br>checking whether we are using the GNU Fortran 77 compiler... yes
<br>checking whether gfortran accepts -g... yes
<br>checking if libtool supports shared libraries... yes
<br>checking whether to build shared libraries... yes
<br>checking whether to build static libraries... yes
<br>checking for gfortran option to produce PIC... -fPIC
<br>checking if gfortran PIC flag -fPIC works... yes
<br>checking if gfortran static flag -static works... yes
<br>checking if gfortran supports -c -o file.o... /bin/rm: cannot remove `conftest*': No such file or directory
<br>yes
<br>checking if gfortran supports -c -o file.o... (cached) yes
<br>checking whether the gfortran linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
<br>checking dynamic linker characteristics... GNU/Linux ld.so
<br>checking how to hardcode library paths into programs... immediate
<br>checking for gfortran... gfortran
<br>checking whether we are using the GNU Fortran compiler... yes
<br>checking whether gfortran accepts -g... yes
<br>checking if libtool supports shared libraries... yes
<br>checking whether to build shared libraries... yes
<br>checking whether to build static libraries... yes
<br>checking for gfortran option to produce PIC... -fPIC
<br>checking if gfortran PIC flag -fPIC works... yes
<br>checking if gfortran static flag -static works... yes
<br>checking if gfortran supports -c -o file.o... /bin/rm: cannot remove `conftest*': No such file or directory
<br>yes
<br>checking if gfortran supports -c -o file.o... (cached) yes
<br>checking whether the gfortran linker (/usr/x86_64-suse-linux/bin/ld -m elf_x86_64) supports shared libraries... yes
<br>checking dynamic linker characteristics... GNU/Linux ld.so
<br>checking how to hardcode library paths into programs... immediate
<br>checking for gcj... no
<br>checking for windres... no
<br>configure: creating ./config.status
<br>config.status: creating Makefile
<br>config.status: creating config.h
<br>config.status: executing tests/atconfig commands
<br>config.status: executing depfiles commands
<br>config.status: executing libtool commands
<br>/bin/rm: cannot remove `libtoolT': No such file or directory
<br>alan@stratford:~/libtool/libtool-2.2.6b 65%
<br>alan@stratford:~/libtool/libtool-2.2.6b 65%
<br>alan@stratford:~/libtool/libtool-2.2.6b 65% gmake
<br>gmake all-recursive
<br>gmake[1]: Entering directory `/nashome/alan/libtool/libtool-2.2.6b'
<br>gmake[2]: Entering directory `/nashome/alan/libtool/libtool-2.2.6b'
<br>/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl -DLT_CONFIG_H='<config.h>' -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/loaders/libltdl_libltdl_la-preopen.lo -MD -MP -MF libltdl/loaders/.deps/libltdl_libltdl_la-preopen.Tpo -c -o libltdl/loaders/libltdl_libltdl_la-preopen.lo `test -f 'libltdl/loaders/preopen.c' || echo './'`libltdl/loaders/preopen.c
<br>/bin/rm: cannot remove `libltdl/loaders/libltdl_libltdl_la-preopen.loT': No such file or directory
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/loaders/libltdl_libltdl_la-preopen.lo -MD -MP -MF libltdl/loaders/.deps/libltdl_libltdl_la-preopen.Tpo -c libltdl/loaders/preopen.c -fPIC -DPIC -o libltdl/loaders/.libs/libltdl_libltdl_la-preopen.o
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/loaders/libltdl_libltdl_la-preopen.lo -MD -MP -MF libltdl/loaders/.deps/libltdl_libltdl_la-preopen.Tpo -c libltdl/loaders/preopen.c -o libltdl/loaders/libltdl_libltdl_la-preopen.o >/dev/null 2>&1
<br>mv -f libltdl/loaders/.deps/libltdl_libltdl_la-preopen.Tpo libltdl/loaders/.deps/libltdl_libltdl_la-preopen.Plo
<br>/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl -DLT_CONFIG_H='<config.h>' -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-lt__alloc.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-lt__alloc.Tpo -c -o libltdl/libltdl_libltdl_la-lt__alloc.lo `test -f 'libltdl/lt__alloc.c' || echo './'`libltdl/lt__alloc.c
<br>/bin/rm: cannot remove `libltdl/libltdl_libltdl_la-lt__alloc.loT': No such file or directory
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-lt__alloc.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-lt__alloc.Tpo -c libltdl/lt__alloc.c -fPIC -DPIC -o libltdl/.libs/libltdl_libltdl_la-lt__alloc.o
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-lt__alloc.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-lt__alloc.Tpo -c libltdl/lt__alloc.c -o libltdl/libltdl_libltdl_la-lt__alloc.o >/dev/null 2>&1
<br>mv -f libltdl/.deps/libltdl_libltdl_la-lt__alloc.Tpo libltdl/.deps/libltdl_libltdl_la-lt__alloc.Plo
<br>/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl -DLT_CONFIG_H='<config.h>' -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-lt_dlloader.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-lt_dlloader.Tpo -c -o libltdl/libltdl_libltdl_la-lt_dlloader.lo `test -f 'libltdl/lt_dlloader.c' || echo './'`libltdl/lt_dlloader.c
<br>/bin/rm: cannot remove `libltdl/libltdl_libltdl_la-lt_dlloader.loT': No such file or directory
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-lt_dlloader.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-lt_dlloader.Tpo -c libltdl/lt_dlloader.c -fPIC -DPIC -o libltdl/.libs/libltdl_libltdl_la-lt_dlloader.o
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-lt_dlloader.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-lt_dlloader.Tpo -c libltdl/lt_dlloader.c -o libltdl/libltdl_libltdl_la-lt_dlloader.o >/dev/null 2>&1
<br>mv -f libltdl/.deps/libltdl_libltdl_la-lt_dlloader.Tpo libltdl/.deps/libltdl_libltdl_la-lt_dlloader.Plo
<br>/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl -DLT_CONFIG_H='<config.h>' -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-lt_error.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-lt_error.Tpo -c -o libltdl/libltdl_libltdl_la-lt_error.lo `test -f 'libltdl/lt_error.c' || echo './'`libltdl/lt_error.c
<br>/bin/rm: cannot remove `libltdl/libltdl_libltdl_la-lt_error.loT': No such file or directory
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-lt_error.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-lt_error.Tpo -c libltdl/lt_error.c -fPIC -DPIC -o libltdl/.libs/libltdl_libltdl_la-lt_error.o
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-lt_error.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-lt_error.Tpo -c libltdl/lt_error.c -o libltdl/libltdl_libltdl_la-lt_error.o >/dev/null 2>&1
<br>mv -f libltdl/.deps/libltdl_libltdl_la-lt_error.Tpo libltdl/.deps/libltdl_libltdl_la-lt_error.Plo
<br>/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl -DLT_CONFIG_H='<config.h>' -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-ltdl.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-ltdl.Tpo -c -o libltdl/libltdl_libltdl_la-ltdl.lo `test -f 'libltdl/ltdl.c' || echo './'`libltdl/ltdl.c
<br>/bin/rm: cannot remove `libltdl/libltdl_libltdl_la-ltdl.loT': No such file or directory
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-ltdl.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-ltdl.Tpo -c libltdl/ltdl.c -fPIC -DPIC -o libltdl/.libs/libltdl_libltdl_la-ltdl.o
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-ltdl.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-ltdl.Tpo -c libltdl/ltdl.c -o libltdl/libltdl_libltdl_la-ltdl.o >/dev/null 2>&1
<br>mv -f libltdl/.deps/libltdl_libltdl_la-ltdl.Tpo libltdl/.deps/libltdl_libltdl_la-ltdl.Plo
<br>/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl -DLT_CONFIG_H='<config.h>' -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-slist.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-slist.Tpo -c -o libltdl/libltdl_libltdl_la-slist.lo `test -f 'libltdl/slist.c' || echo './'`libltdl/slist.c
<br>/bin/rm: cannot remove `libltdl/libltdl_libltdl_la-slist.loT': No such file or directory
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-slist.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-slist.Tpo -c libltdl/slist.c -fPIC -DPIC -o libltdl/.libs/libltdl_libltdl_la-slist.o
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. -DLTDLOPEN=libltdl "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/libltdl_libltdl_la-slist.lo -MD -MP -MF libltdl/.deps/libltdl_libltdl_la-slist.Tpo -c libltdl/slist.c -o libltdl/libltdl_libltdl_la-slist.o >/dev/null 2>&1
<br>mv -f libltdl/.deps/libltdl_libltdl_la-slist.Tpo libltdl/.deps/libltdl_libltdl_la-slist.Plo
<br>depbase=`echo libltdl/loaders/dlopen.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
<br>/bin/sh ./libtool --tag=CC --mode=compile gcc -DHAVE_CONFIG_H -I. -DLT_CONFIG_H='<config.h>' -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/loaders/dlopen.lo -MD -MP -MF $depbase.Tpo -c -o libltdl/loaders/dlopen.lo libltdl/loaders/dlopen.c &&\
<br>mv -f $depbase.Tpo $depbase.Plo
<br>/bin/rm: cannot remove `libltdl/loaders/dlopen.loT': No such file or directory
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/loaders/dlopen.lo -MD -MP -MF libltdl/loaders/.deps/dlopen.Tpo -c libltdl/loaders/dlopen.c -fPIC -DPIC -o libltdl/loaders/.libs/dlopen.o
<br>libtool: compile: gcc -DHAVE_CONFIG_H -I. "-DLT_CONFIG_H=<config.h>" -DLTDL -I. -I. -Ilibltdl -I./libltdl -I./libltdl/libltdl -g -O2 -MT libltdl/loaders/dlopen.lo -MD -MP -MF libltdl/loaders/.deps/dlopen.Tpo -c libltdl/loaders/dlopen.c -o libltdl/loaders/dlopen.o >/dev/null 2>&1
<br>/bin/sh ./libtool --tag=CC --mode=link gcc -g -O2 -module -avoid-version -o libltdl/dlopen.la libltdl/loaders/dlopen.lo -ldl -ldl
<br>libtool: link: /bin/rmr libltdl/.libs/dlopen.a
<br>./libtool: line 964: /bin/rmr: No such file or directory
<br>libtool: link: ar cru libltdl/.libs/dlopen.a libltdl/loaders/.libs/dlopen.o
<br>libtool: link: ranlib libltdl/.libs/dlopen.a
<br>libtool: link: ( cd "libltdl/.libs" && /bin/rm "dlopen.la" && ln -s "../dlopen.la" "dlopen.la" )
<br>/bin/rm: cannot remove `dlopen.la': No such file or directory
<br>gmake[2]: *** [libltdl/dlopen.la] Error 1
<br>gmake[2]: Leaving directory `/nashome/alan/libtool/libtool-2.2.6b'
<br>gmake[1]: *** [all-recursive] Error 1
<br>gmake[1]: Leaving directory `/nashome/alan/libtool/libtool-2.2.6b'
<br>gmake: *** [all] Error 2
<br><br>Does anyone know what I am doing wrong?<p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Bugs-f1715.html" embed="fixTarget[1715]" target="_top" rel="nofollow">Gnu - Libtool - Bugs</a></p>tag:old.nabble.com,2006:post-26806774ltdl.m4 requires /usr/lib*/libltdl.la2009-12-15T13:46:26Z2009-12-15T13:46:26ZNathan Phillip Brink<a href="https://bugs.gentoo.org/293921" target="_top" rel="nofollow">https://bugs.gentoo.org/293921</a><br><br>When the target OS supports ELF-ish dynamic linking and libtool is being used to produce an executable (which doesn't use modules, etc.), it does not need to expand -l flags passed to gcc. This is because of the presence of .DT_NEEDED or something like that if I understand some things correctly. Thus, I can remove most (but not all) files matching the glob patter /usr/lib*/*.la from my system and will still be able to dynamically link executables even when using the libtool script to link.
<br><br>However, the libtool configure macros for linking to ltdl do not take this into account. In my copy of libtool-2.2.6a, the distributed ltdl.m4 has a block looking like the following:
<br>if test -n "$with_ltdl_lib"; then
<br> if test -f "$with_ltdl_lib/libltdl.la"; then :
<br> else
<br> AC_MSG_ERROR([invalid ltdl library directory: `$with_ltdl_lib'])
<br> fi
<br>else
<br> with_ltdl_lib=no
<br>fi
<br><br>This block prevents a program from linking against a system-installed ltdl when there is an installed and working shared object named /usr/lib*/libltdl.so but the associated libltdl.la file was removed because it is _unnecessary_. If libltdl.la is installed, it contains a ``shouldnotlink=no'' directive (see the linked bug) which indicates that a program may link directly against the associated .so file without libtool needing to open the .la file. libltdl.la does contain this directive before being installed for my system, so it isn't installed.
<br><br>I recognize that it is strange for people to run around deleting *.la files; but I am one of them. The original reason I deleted them was to solve problems when *.la files refer to nonexistent *.la files. The more recent reason is that I'm interested in using portage-multilib which removes the *.la files to facilitate building and linking to both 64-bit and 32-bit versions of libraries. For the most part, my system shouldn't need *.la files anyway because most programs are not statically linked and only a few packages I have installed use the module-loading feature of ltdl. I would much appreciate if the ltdl.m4 macros could be changed to recognize that libltdl.la doesn't have to exist :-).
<br><br>--
<br>ohnobinki
<br><br>Look out for missing apostrophes!
<br><br><br>_______________________________________________
<br>Bug-libtool mailing list
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26806774&i=0" target="_top" rel="nofollow">Bug-libtool@...</a>
<br><a href="http://lists.gnu.org/mailman/listinfo/bug-libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/bug-libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Bugs-f1715.html" embed="fixTarget[1715]" target="_top" rel="nofollow">Gnu - Libtool - Bugs</a></p>tag:old.nabble.com,2006:post-26802213Re: why relink on successive "make install"?2009-12-15T13:37:15Z2009-12-15T13:37:15ZKurt RoeckxOn Tue, Dec 15, 2009 at 02:52:39PM -0600, Bob Friesenhahn wrote:
<div class='shrinkable-quote'><br>> On Tue, 15 Dec 2009, Tom Vaughan wrote:
<br>>
<br>> >I have a pretty vanilla shared library on the latest Ubuntu Karmic
<br>> >Koala that is built with autoconf, automake, and libtool. I've noticed
<br>> >that if I "make install" I always see "libtool: install: warning:
<br>> >relinking `librestest.la'" even when I know nothing has changed. Why?
<br>>
<br>> One purpose for re-linking is to make sure that the installed
<br>> library depends on installed libraries of the correct version rather
<br>> than some library in a build tree, or an older version of an
<br>> installed library. Another purpose can be to formally register the
<br>> library with the system so that it will be used.
</div><br>An other reason for relinking is that it might have set up an
<br>rpath before to be able to link to an other non-installed library
<br>which it's needed now anymore.
<br><br><br>Kurt
<br><br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26802127Re: why relink on successive "make install"?2009-12-15T13:31:27Z2009-12-15T13:31:27ZMike FrysingerOn Tuesday 15 December 2009 15:52:39 Bob Friesenhahn wrote:
<div class='shrinkable-quote'><div class='shrinkable-quote'><br>> On Tue, 15 Dec 2009, Tom Vaughan wrote:
<br>> > I have a pretty vanilla shared library on the latest Ubuntu Karmic
<br>> > Koala that is built with autoconf, automake, and libtool. I've noticed
<br>> > that if I "make install" I always see "libtool: install: warning:
<br>> > relinking `librestest.la'" even when I know nothing has changed. Why?
<br>>
<br>> One purpose for re-linking is to make sure that the installed library
<br>> depends on installed libraries of the correct version rather than some
<br>> library in a build tree, or an older version of an installed library.
<br>> Another purpose can be to formally register the library with the
<br>> system so that it will be used.
</div></div>could ELF rpath DT's also be a factor ?
<br>-mike
<br><br /> <br />_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>signature.asc</strong> (853 bytes) <a href="http://old.nabble.com/attachment/26802127/0/signature.asc" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26801939Re: [PATCH] Enable runtime cwrapper debugging; add tests2009-12-15T13:18:19Z2009-12-15T13:18:19ZTim Rice<br>Hi Chuck,
<br><br>On Tue, 15 Dec 2009, Charles Wilson wrote:
<br><div class='shrinkable-quote'><br>> On Mon, 14 Dec 2009 15:06 -0800, "Tim Rice" wrote:
<br>> > I would strongly advocate testing at least one System V based system.
<br>> > Non bash shells sometimes have issues.
<br>>
<br>> During the release process, certainly testing on as many supported
<br>> platforms as possible is baked into the cake. *Perhaps*, by a reviewer
<br>> or other list denizen, before a particular patch is pushed. But it's
<br>> unreasonable to *require* every contributor to have access to multiple
<br>> platforms. Some folks who fix HP-UX might not have (or want to install)
<br>> cygwin on a win32 box. Or a mingw developer might not have any access to
<br>> a Solaris machine.
<br>>
<br>> I have access to cygwin, mingw, and linux. I don't have access to SysV,
<br>> and it would be setting WAY too high a bar for contributions to say "No,
<br>> thanks, we don't want your patches because you can't test them on System
<br>> Foo".
</div><br>I did not mean to imply that it should be required.
<br>It's just a whole lot easier to keep non portable shell/awk/sed code
<br>from slipping through if tested on SysV.
<br><br><br>--
<br>Tim Rice Multitalents (707) 887-1469
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26801939&i=0" target="_top" rel="nofollow">tim@...</a>
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Patches-f1716.html" embed="fixTarget[1716]" target="_top" rel="nofollow">Gnu - Libtool - Patches</a></p>tag:old.nabble.com,2006:post-26801580Re: why relink on successive "make install"?2009-12-15T12:52:39Z2009-12-15T12:52:39ZBob FriesenhahnOn Tue, 15 Dec 2009, Tom Vaughan wrote:
<br><br>> I have a pretty vanilla shared library on the latest Ubuntu Karmic
<br>> Koala that is built with autoconf, automake, and libtool. I've noticed
<br>> that if I "make install" I always see "libtool: install: warning:
<br>> relinking `librestest.la'" even when I know nothing has changed. Why?
<br><br>One purpose for re-linking is to make sure that the installed library
<br>depends on installed libraries of the correct version rather than some
<br>library in a build tree, or an older version of an installed library.
<br>Another purpose can be to formally register the library with the
<br>system so that it will be used.
<br><br>Bob
<br>--
<br>Bob Friesenhahn
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26801580&i=0" target="_top" rel="nofollow">bfriesen@...</a>, <a href="http://www.simplesystems.org/users/bfriesen/" target="_top" rel="nofollow">http://www.simplesystems.org/users/bfriesen/</a><br>GraphicsMagick Maintainer, <a href="http://www.GraphicsMagick.org/" target="_top" rel="nofollow">http://www.GraphicsMagick.org/</a><br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26801527why relink on successive "make install"?2009-12-15T12:48:19Z2009-12-15T12:48:19ZTom Vaughan-2Hi,
<br><br>I have a pretty vanilla shared library on the latest Ubuntu Karmic
<br>Koala that is built with autoconf, automake, and libtool. I've noticed
<br>that if I "make install" I always see "libtool: install: warning:
<br>relinking `librestest.la'" even when I know nothing has changed. Why?
<br>Is there a way I could prevent this?
<br><br>And I notice that it's only .libs/librestest.so.0.0.0T that is
<br>relinked (note the trailing 'T'), not .libs/librestest.so.0.0.0. Of
<br>course there is no need to relink .libs/librestest.so.0.0.0, because
<br>nothing has changed. But why would .libs/librestest.so.0.0.0T be
<br>relinked? What purpose does this duplicate (exactly the same size)
<br>library serve?
<br><br>Thanks. I've been a long time autotools user. Thank you very much for
<br>this extremely helpful suite of software.
<br><br>-Tom
<br><br>P.S. My search on the interwebs for answers turned up nil. If the
<br>answers are out there somewhere and I missed them, please direct me to
<br>them, and sorry about that.
<br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26800328Re: [PATCH] Enable runtime cwrapper debugging; add tests2009-12-15T11:29:16Z2009-12-15T11:29:16ZCharles Wilson-4On Mon, 14 Dec 2009 15:06 -0800, "Tim Rice" wrote:
<div class='shrinkable-quote'><br>> On Mon, 14 Dec 2009, Charles Wilson wrote:
<br>>
<br>> > Two related lines of inquiry:
<br>> > 1) Under *normal* development rules -- e.g not a pre-release
<br>> > bug-fix-only phase, nor a not-quite-pre-release code slush like (I
<br>> > think) we're in right now, for 2.2.8 -- surely you aren't suggesting
<br>> > that EVERY contribution must be validated on EVERY platform, prior to
<br>> > push? These were tested on cyg/ming and linux, so in general, during
<br>> > /normal/ development, that should be sufficient contra reveiwer
<br>> > comments, right?
<br>>
<br>> I would strongly advocate testing at least one System V based system.
<br>> Non bash shells sometimes have issues.
</div><br>During the release process, certainly testing on as many supported
<br>platforms as possible is baked into the cake. *Perhaps*, by a reviewer
<br>or other list denizen, before a particular patch is pushed. But it's
<br>unreasonable to *require* every contributor to have access to multiple
<br>platforms. Some folks who fix HP-UX might not have (or want to install)
<br>cygwin on a win32 box. Or a mingw developer might not have any access to
<br>a Solaris machine.
<br><br>I have access to cygwin, mingw, and linux. I don't have access to SysV,
<br>and it would be setting WAY too high a bar for contributions to say "No,
<br>thanks, we don't want your patches because you can't test them on System
<br>Foo".
<br><br>--
<br>Chuck
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Patches-f1716.html" embed="fixTarget[1716]" target="_top" rel="nofollow">Gnu - Libtool - Patches</a></p>tag:old.nabble.com,2006:post-26800314Re: lib seach path2009-12-15T11:27:37Z2009-12-15T11:27:37ZRalf Wildenhues* Joakim Tjernlund wrote on Tue, Dec 15, 2009 at 09:09:58AM CET:
<div class='shrinkable-quote'><br>> Ralf Wildenhues wrote on 14/12/2009 19:52:54:
<br>> >
<br>> > * Joakim Tjernlund wrote on Mon, Dec 14, 2009 at 09:42:51AM CET:
<br>> > > How do I add -static on a per lib basis?
<br>> >
<br>> > Currently there is no way to do so, but it is a TODO item and a proposed
<br>> > patch to add this functionality (search for 'per-deplib static'). For
<br>>
<br>> I see. Searched and found a msg that said you added this support in CVS
<br>> in 2006. Has there not been a libtool release since then?
</div><br>The patch never made it into the tree; there were still issues with it.
<br><br>Cheers,
<br>Ralf
<br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26795106Re: autoreconf always calling libtool with --copy option on Ubuntu 9.102009-12-15T05:50:11Z2009-12-15T05:50:11ZAdam MercerOn Tue, Dec 15, 2009 at 02:31, Paolo Bonzini <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26795106&i=0" target="_top" rel="nofollow">bonzini@...</a>> wrote:
<br><br>> It's an Ubuntu-specific (maybe Debian-specific) patch.
<br><br>Thanks I'll follow this up with them.
<br><br>Cheers
<br><br>Adam
<br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26791404Re: autoreconf always calling libtool with --copy option on Ubuntu 9.102009-12-15T00:31:16Z2009-12-15T00:31:16ZPaolo Bonzini-2On 12/14/2009 07:25 PM, Adam Mercer wrote:
<div class='shrinkable-quote'><br>> cd /us
<br>>
<br>> On Mon, Dec 14, 2009 at 12:13, Paolo Bonzini<<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26791404&i=0" target="_top" rel="nofollow">bonzini@...</a>> wrote:
<br>>>> I only have this problem with Ubuntu 9.10, does anyone know what could
<br>>>> be causing this?
<br>>>
<br>>> What is the output of autoreconf --version?
<br>>
<br>> It reports itself as 2.64
<br>>
<br>>> Can you attach your
<br>>> /usr/bin/autoreconf so that we can look for Canonical patches?
<br>>
<br>> Attached, the source package is available from the following location:
<br>>
<br>> <<a href="http://packages.ubuntu.com/source/karmic/autoconf" target="_top" rel="nofollow">http://packages.ubuntu.com/source/karmic/autoconf</a>>
</div><br>It's an Ubuntu-specific (maybe Debian-specific) patch.
<br><br>Paolo
<br><br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26791158Re: lib seach path2009-12-15T00:09:58Z2009-12-15T00:09:58ZJoakim Tjernlund-2Ralf Wildenhues <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26791158&i=0" target="_top" rel="nofollow">Ralf.Wildenhues@...</a>> wrote on 14/12/2009 19:52:54:
<br>>
<br>> * Joakim Tjernlund wrote on Mon, Dec 14, 2009 at 09:42:51AM CET:
<br>> > How do I add -static on a per lib basis?
<br>>
<br>> Currently there is no way to do so, but it is a TODO item and a proposed
<br>> patch to add this functionality (search for 'per-deplib static'). For
<br><br>I see. Searched and found a msg that said you added this support in CVS
<br>in 2006. Has there not been a libtool release since then?
<br><br>> in-tree libraries you could work around it by creating another variant
<br>> of the library, with --tag=disable-shared added to its *_LIBTOOLFLAGS.
<br><br>hmm, that will introduce some churn in the make files. Using the
<br>.a libs directly does not work at all? I am using GNU/Linux if that matters.
<br><br>>
<br>> Note that none of the other deplibs should depend upon the shared
<br>> version of the library you're linking statically.
<br>>
<br>> Cheers,
<br>> Ralf
<br>>
<br><br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26786651Re: [PATCH] Enable runtime cwrapper debugging; add tests2009-12-14T15:06:57Z2009-12-14T15:06:57ZTim RiceOn Mon, 14 Dec 2009, Charles Wilson wrote:
<br><br>> Two related lines of inquiry:
<br>> 1) Under *normal* development rules -- e.g not a pre-release
<br>> bug-fix-only phase, nor a not-quite-pre-release code slush like (I
<br>> think) we're in right now, for 2.2.8 -- surely you aren't suggesting
<br>> that EVERY contribution must be validated on EVERY platform, prior to
<br>> push? These were tested on cyg/ming and linux, so in general, during
<br>> /normal/ development, that should be sufficient contra reveiwer
<br>> comments, right?
<br>
<br>I would strongly advocate testing at least one System V based system.
<br>Non bash shells sometimes have issues.
<br><br><br>--
<br>Tim Rice Multitalents (707) 887-1469
<br><a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26786651&i=0" target="_top" rel="nofollow">tim@...</a>
<br><br><br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Patches-f1716.html" embed="fixTarget[1716]" target="_top" rel="nofollow">Gnu - Libtool - Patches</a></p>tag:old.nabble.com,2006:post-26782811Re: lib seach path2009-12-14T10:52:54Z2009-12-14T10:52:54ZRalf Wildenhues* Joakim Tjernlund wrote on Mon, Dec 14, 2009 at 09:42:51AM CET:
<br>> How do I add -static on a per lib basis?
<br><br>Currently there is no way to do so, but it is a TODO item and a proposed
<br>patch to add this functionality (search for 'per-deplib static'). For
<br>in-tree libraries you could work around it by creating another variant
<br>of the library, with --tag=disable-shared added to its *_LIBTOOLFLAGS.
<br><br>Note that none of the other deplibs should depend upon the shared
<br>version of the library you're linking statically.
<br><br>Cheers,
<br>Ralf
<br><br><br>_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>tag:old.nabble.com,2006:post-26782665Re: [PATCH] Enable runtime cwrapper debugging; add tests2009-12-14T10:43:55Z2009-12-14T10:43:55ZRalf Wildenhues* Ralf Wildenhues wrote on Mon, Dec 14, 2009 at 07:37:31PM CET:
<br>> * Charles Wilson wrote on Mon, Dec 14, 2009 at 06:47:10PM CET:
<br>> > Finally, it's not clear in your message: are you saying that *existing*
<br>> > win32 "changes" currently in master are causing problems on HP-UX, or
<br>> > just that some of the win32 changes /in this patch/ are causing them?
<br>>
<br>> Something causes lots of leftover shell temp files, [...]
<br><br>and that something is in current git master.
<br><br>(realizing I didn't really answer your question in the previous post)
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Patches-f1716.html" embed="fixTarget[1716]" target="_top" rel="nofollow">Gnu - Libtool - Patches</a></p>tag:old.nabble.com,2006:post-26782588Re: [PATCH] Enable runtime cwrapper debugging; add tests2009-12-14T10:37:31Z2009-12-14T10:37:31ZRalf Wildenhues* Charles Wilson wrote on Mon, Dec 14, 2009 at 06:47:10PM CET:
<br>>
<br>> Two related lines of inquiry:
<br>> 1) Under *normal* development rules -- e.g not a pre-release
<br>> bug-fix-only phase, nor a not-quite-pre-release code slush like (I
<br>> think) we're in right now, for 2.2.8 -- surely you aren't suggesting
<br>> that EVERY contribution must be validated on EVERY platform, prior to
<br>> push?
<br><br>No, I'm not. I didn't mean for it to come across that way.
<br><br>> These were tested on cyg/ming and linux, so in general, during
<br>> /normal/ development, that should be sufficient contra reveiwer
<br>> comments, right?
<br><br>Yes.
<br><br>> 2) in the current pre-release-ish situation, if you want to postpone
<br>> /all/ of the cygming patches until post-2.2.8 that's ok (I'd rather at
<br>> least get /some/ of them in, but it's not the end of the world
<br>> otherwise).
<br><br>I'm trying to get confidence for some of them to go in.
<br><br>> Finally, it's not clear in your message: are you saying that *existing*
<br>> win32 "changes" currently in master are causing problems on HP-UX, or
<br>> just that some of the win32 changes /in this patch/ are causing them?
<br><br>Something causes lots of leftover shell temp files, and they contain
<br>cwrapper contents. These leftover files cause later, unrelated
<br>processes with same PIDs to fail when needing shell temp files as well
<br>(yeah the temp file naming is really crappy). Bet it's merely some
<br>shell bug with here-documents in functions or so, but I haven't analyzed
<br>it yet.
<br><br>As to Bob's certainly right note on a high bar for patch entry: adding
<br>more testsuite coverage can only help confidence in changes. Yes, I am
<br>repeating myself. (And no, this isn't particularly directed at your w32
<br>changes, either.)
<br><br>Cheers,
<br>Ralf
<br><br><br><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Patches-f1716.html" embed="fixTarget[1716]" target="_top" rel="nofollow">Gnu - Libtool - Patches</a></p>tag:old.nabble.com,2006:post-26782412Re: autoreconf always calling libtool with --copy option on Ubuntu 9.102009-12-14T10:25:19Z2009-12-14T10:25:19ZAdam Mercercd /us
<br><br>On Mon, Dec 14, 2009 at 12:13, Paolo Bonzini <<a href="http://old.nabble.com/user/SendEmail.jtp?type=post&post=26782412&i=0" target="_top" rel="nofollow">bonzini@...</a>> wrote:
<br>>> I only have this problem with Ubuntu 9.10, does anyone know what could
<br>>> be causing this?
<br>>
<br>> What is the output of autoreconf --version?
<br><br>It reports itself as 2.64
<br><br>> Can you attach your
<br>> /usr/bin/autoreconf so that we can look for Canonical patches?
<br><br>Attached, the source package is available from the following location:
<br><br><<a href="http://packages.ubuntu.com/source/karmic/autoconf" target="_top" rel="nofollow">http://packages.ubuntu.com/source/karmic/autoconf</a>>
<br><br>Cheers
<br><br>Adam
<br><br /> <br />_______________________________________________
<br><a href="http://lists.gnu.org/mailman/listinfo/libtool" target="_top" rel="nofollow">http://lists.gnu.org/mailman/listinfo/libtool</a><br><div class="small"><br/><img src="http://old.nabble.com/images/icon_attachment.gif" > <strong>autoreconf.bz2</strong> (9K) <a href="http://old.nabble.com/attachment/26782412/0/autoreconf.bz2" target="_top">Download Attachment</a></div><p>From forum: <a href="http://old.nabble.com/Gnu---Libtool---Discuss-f1714.html" embed="fixTarget[1714]" target="_top" rel="nofollow">Gnu - Libtool - Discuss</a></p>