Re: [patch] 1.5.26 do echo=echo if necessary
Hi Thien-Thi, * Thien-Thi Nguyen wrote on Sun, Mar 09, 2008 at 10:29:13AM CET: () Peter O'Gorman [EMAIL PROTECTED] () Sat, 08 Mar 2008 17:33:47 -0600 It seems likely that you have a configure that was created with a different version of libtool than ltmain.sh was created with. Are you talking about the configure script in libtool-1.5.26.tar.gz? I don't see how that enters into the post-install problem of trying to install Automake 1.10.1. For matching versions of libtool.m4 and ltmain.sh from libtool-1.5.26, the generated libtool script should already have: # An echo program that does not interpret backslashes. echo=echo OK. Perhaps this is a problem w/ Automake, then. You probably have to let aclocal know where Libtool 2.2's macro files are. I do that with echo $libtool_prefix/share/aclocal \ $automake_prefix/share/aclocal/dirlist Cheers, Ralf ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: cross compilation to w32
Roumen Petrov wrote: Ralf Wildenhues wrote: * Roumen Petrov wrote on Sun, Mar 09, 2008 at 05:01:30PM CET: [SNIP] Hmm during the tests tests/demo/helldl.exe is compiled many times. First is ok, later don't produce output(exit code 127) and tests/demo/.libs/helldl.exe crash. Roumen ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
Re: [libtool 2.2] testsuite: 40 41 42 44 45 46 48 49 50 51 52 53 failed
snowcrash+libtool wrote: (hm. looks like a list 'scrip is needed for bug-libtool. 'take 2'.) 13: duplicate_deps.at:25 preserve duplicate convenience deps libtool 17: convenience.at:109 F77 convenience archives F77 libtool 18: convenience.at:169 FC convenience archives FC libtool 19: convenience.at:229 Java convenience archives GCJ libtool 21: link-order2.at:46 Link order of deplibs. libtool 55: template.at:126template test with subdirs CXX libtool I have tried and failed to reproduce your failures on powerpc Mac OS X 10.4, and i386 Mac OS X 10.4 and 10.5. What versions of autoconf and automake did you use? Peter -- Peter O'Gorman http://pogma.com ___ Bug-libtool mailing list Bug-libtool@gnu.org http://lists.gnu.org/mailman/listinfo/bug-libtool
w32 ports of Libtool
Hello Peter, Markus, in order to give some perspective for both of your w32 ports of Libtool: when we make the switch to git as primary repo, we intend to import your patch series in topic branches to allow for easier work and integration of them into the master tree (and to hopefully synchronize any issues of them with each other). Cheers, Ralf
[patch #6448] [MSVC 7/7] Add MSVC Support
Follow-up Comment #4, patch #6448 (project libtool): Peter, I've installed that patched libtool system-wide on gentoo/x86_64 laptop on which I'm doing my current gstreamer development, I'll be re-libtool everything with it and will report any issues. ___ Reply to this item at: http://savannah.gnu.org/patch/?6448 ___ Message sent via/by Savannah http://savannah.gnu.org/
Re: w32 ports of Libtool
On Sun, Mar 09, 2008 at 02:53:20PM +0100, Ralf Wildenhues wrote: Hello Peter, Markus, in order to give some perspective for both of your w32 ports of Libtool: when we make the switch to git as primary repo, we intend to import your patch series in topic branches to allow for easier work and integration of them into the master tree (and to hopefully synchronize any issues of them with each other). Ok, in preparation for this, I re-scanned the wgcc patch from last month and found no conflicts with my patch series. But that is hardly surprising since my patches only trigger stuff from inside mingw constructs (or is transparent) and the wgcc stuff is inside winnt*/__PARITY__ constructs. If I would have added my testsuite tweaks there would certainly be clashes, but from a cursory look the changes to the testsuite from Markus is probably helping my patches more that not so I'll just work from there. And the wgcc patch could perhaps(?) use the compile_tag variable from my patch series to add -xc++ for C++ compiles. (Oh, and Ralf, please use my @lysator address...) Cheers, Peter
git mirror of Libtool CVS repo
Hello libtool list readers, Jim Meyering has been kind enough to set up a read-only git mirror of the Libtool CVS repo at http://git.sv.gnu.org/gitweb/?p=libtool.git;a=summary. We expect to be switching toward git as primary hosting for the Libtool code sometime soon, but probably not before 2.2.2. We encourage you to try out the git repo, report any issues, conversion bugs, suggestions. For those of you with write access, please check that your attributions (name and email addresses) match your expectations. At this time, we do not guarantee that the git tree will not be rewound. We may do that in order to fix issues; Watch out for notifications on this list or libtool-patches. Cheers, and thanks Jim! Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool windows dll suffix revision
Hello, Please CC me as I am not subscribed. Was something in the following discussion progressed? http://www.cygwin.com/ml/cygwin/2000-09/msg00053.html From: Gary V. Vaughan gvv at techie dot com Libtool translates the 5:4:3 into a system specific version number for the soname to help the runtime loadee choose the best available library at runtime. As I said before, currently this mapping is wrong on Windows, and I think the correct mapping is to always use the oldest supported interface number -- in this case library2.dll -- when generating the soname. This is explained fully in the version node of the libtool manual link that was quoted earlier in the thread. For example, I have current interface 7 and age 7 i get dll-0.dll, and if I upgrade to current interface 8 and age 8 I also get dll-0.dll. It looks like generating the suffix version based on delta is incorrect, as you may have duplicate dll names. It also looks like Gary is right, having the version be the age solves the issue, since as long as the library is backward compatible to this age, the name is not change. Best Regards, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: v1.5.27a 'syntax error' in numerous packages
Since _LT_DECL does not appear in the stable branch, except for in a ChangeLog entry, I believe that aclocal is getting confused and bringing in bits of libtool-2.2 as well as bits of libtool-1.5. ltoptions.m4 from libtool-2.2 has this line. that would imply that i did not clean-house properly after downgrading from 22x to 1.5.27a. thought i'd done that sufficiently ... i'll back up to a clean reinstall of autofoo prior to libtool, which (per my notes) is a bit more complete at that, and report back ... thanks. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: v1.5.27a 'syntax error' in numerous packages
looks like you were correct about a straggler from other installs ... whereas my 'usual' cd /usr/local rm -rf include/ltdl.h lib/libltdl* share/libtool share/aclocal-1.10/ltdl.m4 lib/libdl* (rebuild libtool from src) was not sufficiently 'cleansing', a cd /usr/local rm -rf include/ltdl.h lib/libltdl* share/libtool share/aclocal-1.10/ltdl.m4 lib/libdl* rm -rf share/aclocal* rm -rf share/automake* rm -rf share/autoconf* (rebuild libtool from src) certainly was. downstream packages now glibtoolize build, using 1.5.27a, with no errors. i'm guessing the nomially required rm-ing is somewhere inbetween the two actions; likely at least (just?) the aforementioned 'ltoptions.m4'? but, i'm up-n-running again. thanks. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: v1.5.27a 'syntax error' in numerous packages
snowcrash+libtool wrote: i'm guessing the nomially required rm-ing is somewhere inbetween the two actions; likely at least (just?) the aforementioned 'ltoptions.m4'? If you keep your build dirs around you can do a much better job of surgically removing a package: make install DESTDIR=/tmp/deleteme \ find /tmp/deleteme \( -type f -o -type l \) -printf '/%P\0' | \ xargs -0 rm; rm -rf /tmp/deleteme This simply installs the package again in an empty throwaway dir and uses the resulting filelist to delete from the live system. Of course, you may want to fortify this in various ways: pick a more appropriately named temp dir, make sure it's empty at first, sanity check the list of files to delete, ensure the package supports DESTDIR (vs. prefix overriding) etc. But you get the general idea of the method. Some packages generalize this with a make uninstall rule. Brian ___ http://lists.gnu.org/mailman/listinfo/libtool
