[patch #6443] [MSVC 2/7] On Windows, find potential libs regardless of file name case.
URL: http://savannah.gnu.org/patch/?6443 Summary: [MSVC 2/7] On Windows, find potential libs regardless of file name case. Project: GNU Libtool Submitted by: pekberg Submitted on: Tuesday 03/04/2008 at 10:56 Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any ___ Details: * libltdl/m4/libtool.m4 (_LT_CHECK_MAGIC_METHOD), libltdl/config/ltmain.m4sh (func_mode_link): On Windows, find potential libs regardless of file name case. * tests/nocase.at: New test, to check for regressions of the above. * Makefile.am: Add above new test. ___ File Attachments: --- Date: Tuesday 03/04/2008 at 10:56 Name: file-magic-glob.patch Size: 6kB By: pekberg http://savannah.gnu.org/patch/download.php?file_id=15171 ___ Reply to this item at: http://savannah.gnu.org/patch/?6443 ___ Message sent via/by Savannah http://savannah.gnu.org/
[patch #6446] MSVC [5/7] MSVC doesn't support the -l option, instead it expects the exact library file name
URL: http://savannah.gnu.org/patch/?6446 Summary: MSVC [5/7] MSVC doesn't support the -l option, instead it expects the exact library file name Project: GNU Libtool Submitted by: pekberg Submitted on: Tuesday 03/04/2008 at 11:01 Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any ___ Details: MSVC doesn't support the -l option, instead it expects the exact library file name. Retain the -l option as long as possible as libtool recognizes -l internally. Then, as late as possible transform the -l option to an exact file name (-lfoo - foo.lib). This patch is against Libtool 2.2 * libltdl/m4/libtool.m4: Add tag variable dashl_xform which specifies how to transform -l options for the linker. * libltdl/config/ltmain.m4sh (func_mode_link): Transform -l options using dashl_xform right before creating the program or library. ___ File Attachments: --- Date: Tuesday 03/04/2008 at 11:01 Name: dashl-xform.patch Size: 2kB By: pekberg http://savannah.gnu.org/patch/download.php?file_id=15174 ___ Reply to this item at: http://savannah.gnu.org/patch/?6446 ___ Message sent via/by Savannah http://savannah.gnu.org/
[patch #6447] MSVC [6/7] Indicate if the archiver supports a listing file
URL: http://savannah.gnu.org/patch/?6447 Summary: MSVC [6/7] Indicate if the archiver supports a listing file Project: GNU Libtool Submitted by: pekberg Submitted on: Tuesday 03/04/2008 at 11:03 Category: None Priority: 5 - Normal Status: None Privacy: Public Assigned to: None Originator Email: Open/Closed: Open Discussion Lock: Any ___ Details: Allow the use of a file listing file if the archiver supports it. Add hint so that the Microsoft lib archiver uses the file listing feature. This patch is against Libtool 2.2 * libltdl/m4/libtool.m4 (_LT_PROG_AR): Indicate if the archiver supports a listing file with the new variable archiver_list_spec. * libltdl/config/ltmain.m4sh: If the archiver supports a listing file, use it when max_cmd_len is exceeded. ___ File Attachments: --- Date: Tuesday 03/04/2008 at 11:03 Name: archiver-list-spec.patch Size: 2kB By: pekberg http://savannah.gnu.org/patch/download.php?file_id=15175 ___ Reply to this item at: http://savannah.gnu.org/patch/?6447 ___ Message sent via/by Savannah http://savannah.gnu.org/
[patch #6442] [MSVC 1/7] Allow Microsoft lib to be used as the archiver.
Update of patch #6442 (project libtool): Summary: Allow Microsoft lib to be used as the archiver. = [MSVC 1/7] Allow Microsoft lib to be used as the archiver. ___ Follow-up Comment #1: * libltdl/m4/libtool.m4 (_LT_PROG_AR): New macro, detect the interface used by the archiver. In particullar, add the AR_SEP variable to allow archivers that does not allow a space between the options to create an archive and the archive name and the ar_extract_one_by_one variable which indicates if the archiver can extract all members in one go. * libltdl/m4/libtool.m4: Add $AR_SEP between $AR_FLAGS and the archive file name in all $AR commands. * libltdl/config/ltmain.m4sh (func_extract_an_archive): Add support for archivers that only supports extracting one member at a time and otherwise adjust to the above libtool.m4 changes. Also, add $AR_SEP to the $AR invocations. * Makefile.am: Pass AR, AR_FLAGS and AR_SEP through to the testsuite. * tests/archive-in-archive.at: Extract archive name from the .la file instead of hardcodeing the name, and allow different archivers. ___ Reply to this item at: http://savannah.gnu.org/patch/?6442 ___ Message sent via/by Savannah http://savannah.gnu.org/
[patch #6448] [MSVC 7/7] Add MSVC Support
Follow-up Comment #1, patch #6448 (project libtool): I have no problems with this patch series on either mingw, nor cygwin. I have not found a functioning cccl to test with. I have tried both cccl 0.03 as found on sf.net and cccl 0.05 as found on http://tsunanet.net/~tsuna/cccl Niether cccl can even build libtool. I have tried to patch around the first few problems in cccl, but I can't see why I should fix cccl in order to check if it these patches break cccl. cccl is seriously broken, or please point me to a version of cccl that I should use. (I used cygwin and ../configure CC=cccl CXX=cccl LD=cccl F77=no FC=no GCJ=no) Annotated testsuite with these patches: On MSYS and MSVC 12.00.8804 (MSVC 6) with: ../configure CC=cl CFLAGS=-MD CXX=cl CXXFLAGS=-MD LD=link NM=dumpbin -symbols AR=lib STRIP=: RANLIB=: F77=no FC=no The problems with the exported variables can be solved with the right amount of declspecs. I will not work on the other problems until basic MSVC support is commited. PASS: tests/link.test PASS: tests/link-2.test PASS: tests/nomode.test PASS: tests/objectlist.test PASS: tests/quote.test PASS: tests/sh.test PASS: tests/suffix.test SKIP: tests/tagtrace.test PASS: tests/cdemo-static.test PASS: tests/cdemo-make.test PASS: tests/cdemo-exec.test PASS: tests/demo-static.test PASS: tests/demo-make.test PASS: tests/demo-exec.test PASS: tests/demo-inst.test PASS: tests/demo-unst.test PASS: tests/depdemo-static.test PASS: tests/depdemo-make.test PASS: tests/depdemo-exec.test PASS: tests/depdemo-inst.test PASS: tests/depdemo-unst.test PASS: tests/mdemo-static.test PASS: tests/mdemo-make.test PASS: tests/mdemo-exec.test PASS: tests/mdemo-inst.test PASS: tests/mdemo-unst.test PASS: tests/cdemo-conf.test PASS: tests/cdemo-make.test PASS: tests/cdemo-exec.test PASS: tests/demo-conf.test FAIL: tests/demo-make.test (exported variable, remove it fixes it) SKIP: tests/demo-exec.test SKIP: tests/demo-inst.test SKIP: tests/demo-unst.test FAIL: tests/demo-deplibs.test (assumes oldlibs are named lib???.a) PASS: tests/depdemo-conf.test FAIL: tests/depdemo-make.test (exported variables, remove them fixes it) SKIP: tests/depdemo-exec.test SKIP: tests/depdemo-inst.test SKIP: tests/depdemo-unst.test PASS: tests/mdemo-conf.test PASS: tests/mdemo-make.test PASS: tests/mdemo-exec.test PASS: tests/mdemo-inst.test PASS: tests/mdemo-unst.test PASS: tests/mdemo-dryrun.test PASS: tests/mdemo2-conf.test PASS: tests/mdemo2-make.test PASS: tests/mdemo2-exec.test PASS: tests/pdemo-conf.test FAIL: tests/pdemo-make.test (link can't create reloadable object files (-r)) SKIP: tests/pdemo-exec.test SKIP: tests/pdemo-inst.test PASS: tests/demo-nofast.test FAIL: tests/demo-make.test (exported variable, remove it fixes it) SKIP: tests/demo-exec.test SKIP: tests/demo-inst.test SKIP: tests/demo-unst.test PASS: tests/depdemo-nofast.test FAIL: tests/depdemo-make.test (exported variables, remove them fixes it) SKIP: tests/depdemo-exec.test SKIP: tests/depdemo-inst.test SKIP: tests/depdemo-unst.test PASS: tests/demo-pic.test FAIL: tests/demo-make.test (exported variable, remove it fixes it) SKIP: tests/demo-exec.test PASS: tests/demo-nopic.test FAIL: tests/demo-make.test (exported variable, remove it fixes it) SKIP: tests/demo-exec.test PASS: tests/cdemo-shared.test PASS: tests/cdemo-make.test PASS: tests/cdemo-exec.test PASS: tests/demo-shared.test FAIL: tests/demo-make.test (exported variable, remove it fixes it...) SKIP: tests/demo-exec.test SKIP: tests/demo-inst.test SKIP: tests/demo-hardcode.test (...but fails here, using $CC w/o going through libtool) SKIP: tests/demo-relink.test SKIP: tests/demo-noinst-link.test SKIP: tests/demo-unst.test PASS: tests/depdemo-shared.test FAIL: tests/depdemo-make.test (exported variables, remove them fixes it) SKIP: tests/depdemo-exec.test SKIP: tests/depdemo-inst.test SKIP: tests/depdemo-relink.test SKIP: tests/depdemo-unst.test PASS: tests/mdemo-shared.test PASS: tests/mdemo-make.test PASS: tests/mdemo-exec.test PASS: tests/mdemo-inst.test PASS: tests/mdemo-unst.test PASS: tests/cdemo-undef.test PASS: tests/cdemo-make.test PASS: tests/cdemo-exec.test PASS: tests/tagdemo-static.test PASS: tests/tagdemo-make.test PASS: tests/tagdemo-exec.test PASS: tests/tagdemo-conf.test PASS: tests/tagdemo-make.test PASS: tests/tagdemo-exec.test PASS: tests/tagdemo-shared.test PASS: tests/tagdemo-make.test PASS: tests/tagdemo-exec.test PASS: tests/tagdemo-undef.test PASS: tests/tagdemo-make.test PASS: tests/tagdemo-exec.test 10 of 79 tests failed (27 tests were not run) Please report to [EMAIL PROTECTED] ___ Reply to this item at: http://savannah.gnu.org/patch/?6448 ___ Message sent via/by Savannah http://savannah.gnu.org/
git? branch-2-2?
Hello libtoolers, 1) Can we move to use git now? 2) Can we create a branch-2-2 and cherry-pick bugfixes from HEAD into it, aiming for a soonish 2.2.2 (let's say, in a few weeks; already a few important issues are known)? 3) If yes and yes, do you agree with the proposed git policy: master should usually not contain merges except for merges from public topic branches, should we have such in the future. Generally, master should be the first to receive a patch, and stable branches should cherry-pick from master. In your local trees, you should rebase private topic branches against the upstream tree before inclusion. If you agree, I just might look into doing the work. I'm a bit unsure whether 2.2.2 should come before the move to git. Comments appreciated. Thanks, Ralf
Re: libltdl memory corruption
Hi Peter, * Peter O'Gorman wrote on Tue, Mar 04, 2008 at 07:14:51AM CET: Ralf Wildenhues wrote: So I'd appreciate a review of this, and also test results on systems with loaders other than preopen and dlopen. (I haven't even tested successful compilation on those other systems.) I did not manage to try the shl_load loader, only tested dyld. This patch causes no regressions on Mac OS X 10.2. If that is also true for the loaders you get around to trying, this is ok. For the preopen, dlopen, shl_load loaders, I confirmed that the testsuite addition exposes the bug, and the loader changes fixes the testsuite failure. For loadlibrary, I only cross-compiled from GNU/Linux to ensure absense of typos. I visually inspected the BeOS and dld changes again for typos, and then applied the patch, after adding a NEWS entry. Thank you. Once again you sent a patch for a bug before I even got around to reading the list. My pleasure. :-) Kudos to Andreas for reporting the bug. Cheers, Ralf
FYI: fix doc typo
I applied this tiny fix. Cheers, Ralf 2008-03-04 Ralf Wildenhues [EMAIL PROTECTED] * doc/libtool.texi (Module loaders for libltdl): Fix typo. Index: doc/libtool.texi === RCS file: /cvsroot/libtool/libtool/doc/libtool.texi,v retrieving revision 1.238 diff -u -r1.238 libtool.texi --- doc/libtool.texi24 Jan 2008 04:08:37 - 1.238 +++ doc/libtool.texi4 Mar 2008 21:06:59 - @@ -4226,7 +4226,7 @@ dlloader.sym_prefix= NULL; dlloader.module_open = myloader_open; dlloader.module_close = myloader_close; - dlloader.find_sym = myloader_find_sym. + dlloader.find_sym = myloader_find_sym; dlloader.dlloader_exit = myloader_exit; dlloader.dlloader_data = (lt_user_data)myloader_function;
libtool generated by GNU $PACKAGE (was: [libtool 2.2] testsuite: 34 failed)
* Roberto Bagnara wrote on Mon, Mar 03, 2008 at 09:14:48PM CET: P.S. In ./libtool there is the line # Generated automatically by config.status (GNU ppl) 0.10pre16 `ppl' is indeed the short name of the project. I don't know why it is preceded by GNU. Fixed with the patch below. I don't care much that, in the Libtool package itself, the will result in a libtool script with the line # Generated automatically by config.status (libtool 1.2600 2008/03/02 02:19:16) 2.3a instead of GNU libtool. This has been reported several times, please speak up if I forgot to mention a reporter. The hard part with this patch was ensuring that none of the libtool code uses this bit in a sed pattern (in some parts script headers are checked, but not this one, apparently). Cheers, and thanks to both of you for the report (I put you in THANKS), Ralf 2008-03-04 Ralf Wildenhues [EMAIL PROTECTED] * libltdl/m4/libtool.m4 (_LT_CONFIG): Drop misleading `GNU' prefix before the host package name in the Generated by line for the libtool script. * THANKS: Update. Reports by Peter Rosin and Roberto Bagnara. Index: libltdl/m4/libtool.m4 === RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v retrieving revision 1.137 diff -u -r1.137 libtool.m4 --- libltdl/m4/libtool.m4 20 Feb 2008 20:11:39 - 1.137 +++ libltdl/m4/libtool.m4 4 Mar 2008 21:11:56 - @@ -685,7 +685,7 @@ #! $SHELL # `$ECHO $ofile | sed 's%^.*/%%'` - Provide generalized library-building support services. -# Generated automatically by $as_me (GNU $PACKAGE$TIMESTAMP) $VERSION +# Generated automatically by $as_me ($PACKAGE$TIMESTAMP) $VERSION # Libtool was configured on host `(hostname || uname -n) 2/dev/null | sed 1q`: # NOTE: Changes made to this file will be lost: look at ltmain.sh. #
mode=execute argument munging bug (was: [libtool 2.2] testsuite: 34 failed)
Hello Roberto, * Roberto Bagnara wrote on Mon, Mar 03, 2008 at 09:14:48PM CET: $ cat mycommand #!/bin/sh echo mycommand invoked with argument '$1' $ mycommand ciao mycommand invoked with argument 'ciao' $ ./libtool --mode=execute mycommand ciao mycommand invoked with argument '/home/roberto/tppl/' $ Note that /home/roberto/tppl/ is the directory where the libtool script is located. I can also do $ cd interfaces/ $ ../libtool --mode=execute ../mycommand ciao mycommand invoked with argument '/home/roberto/tppl/' Is this behavior normal? No. Thank you for the bug report. I've applied the fix below. FWIW, the ordering of the tests in execute-mode.at is such that the first set still passes for 1.5.26. ./libtool is what has been created at configure time and a bzipped version of it is attached to this file. It wasn't attached to the message, but that's not a problem. :-) Cheers, Ralf * libltdl/config/ltmain.m4sh (func_mode_execute): Replace only arguments we have identified as shell or C wrappers. (func_emit_wrapper): Output error message on stderr. * tests/execute-mode.at: New file, with --mode=execute tests. * Makefile.am: Adjust. * NEWS: Update. Fixes 2.2 regression. Report by Roberto Bagnara. Index: Makefile.am === RCS file: /cvsroot/libtool/libtool/Makefile.am,v retrieving revision 1.229 diff -u -r1.229 Makefile.am --- Makefile.am 18 Jan 2008 10:49:40 - 1.229 +++ Makefile.am 4 Mar 2008 21:16:26 - @@ -447,6 +447,7 @@ tests/search-path.at \ tests/indirect_deps.at \ tests/archive-in-archive.at \ + tests/execute-mode.at \ tests/destdir.at \ tests/old-m4-iface.at \ tests/am-subdir.at \ Index: NEWS === RCS file: /cvsroot/libtool/libtool/NEWS,v retrieving revision 1.220 diff -u -r1.220 NEWS --- NEWS4 Mar 2008 21:00:18 - 1.220 +++ NEWS4 Mar 2008 21:16:27 - @@ -6,6 +6,9 @@ - Fix 2.2 regression in libltdl that causes memory corruption upon repeated `lt_dlinit(); lt_dlexit()'. + - Fix 2.2 regression in that `libtool --mode=execute CMD ARGS' does not +transform ARGS that do not look like shell or C wrappers of libtool +programs. New in 2.2: 2008-03-01; CVS version 2.1c, Libtool team: Index: libltdl/config/ltmain.m4sh === RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v retrieving revision 1.97 diff -u -r1.97 ltmain.m4sh --- libltdl/config/ltmain.m4sh 28 Jan 2008 15:49:46 - 1.97 +++ libltdl/config/ltmain.m4sh 4 Mar 2008 21:16:29 - @@ -1694,12 +1694,14 @@ # Do a test to see if this is really a libtool program. if func_ltwrapper_script_p $file; then func_source $file + # Transform arg to wrapped name. + file=$progdir/$program elif func_ltwrapper_executable_p $file; then func_ltwrapper_scriptname $file func_source $func_ltwrapper_scriptname_result + # Transform arg to wrapped name. + file=$progdir/$program fi - # Transform arg to wrapped name. - file=$progdir/$program ;; esac # Quote arguments (to preserve shell metacharacters). @@ -2468,7 +2470,7 @@ ;; esac $ECHO \ - \$ECHO \\$0: cannot exec \$program \$*\ + \$ECHO \\$0: cannot exec \$program \$*\ 12 exit 1 fi else --- /dev/null 2008-03-02 10:33:19.200041011 +0100 +++ tests/execute-mode.at 2008-03-04 22:15:22.0 +0100 @@ -0,0 +1,92 @@ +# execute-mode.at -- libtool --mode=execute -*- Autotest -*- +# +# Copyright (C) 2008 Free Software Foundation, Inc. +# Written by Ralf Wildenhues, 2008 +# +# This file is part of GNU Libtool. +# +# GNU Libtool is free software; you can redistribute it and/or +# modify it under the terms of the GNU General Public License as +# published by the Free Software Foundation; either version 2 of +# the License, or (at your option) any later version. +# +# GNU Libtool is distributed in the hope that it will be useful, +# but WITHOUT ANY WARRANTY; without even the implied warranty of +# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +# GNU General Public License for more details. +# +# You should have received a copy of the GNU General Public License +# along with GNU Libtool; see the file COPYING. If not, a copy +# can be downloaded from http://www.gnu.org/licenses/gpl.html, +# or obtained by writing to the Free Software Foundation, Inc., +# 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. + + +AT_SETUP([execute mode]) +AT_KEYWORDS([libtool]) + +AT_DATA([foo], +[[#! /bin/sh +if test $# -gt 0; then + echo $@ +else
Re: git? branch-2-2?
Hi Bob, * Bob Friesenhahn wrote on Tue, Mar 04, 2008 at 10:23:57PM CET: I think that this topic should be discussed on [EMAIL PROTECTED] before the final decision because not only libtool maintainers retrieve sources and submit patches based on the version control system. Sure, why not. On Tue, 4 Mar 2008, Ralf Wildenhues wrote: 3) If yes and yes, do you agree with the proposed git policy: master should usually not contain merges except for merges from public topic branches, should we have such in the future. Generally, master should be the first to receive a patch, and stable branches should cherry-pick from master. In your local trees, you should rebase private topic branches against the upstream tree before inclusion. I would like to see more open discussion of this since git is a sort of toolkit which can be used in radically different ways. Git is capable of supporting both cooperation and total anarchy. Besides official maintainers, we have others to worry about. Yep, true. What I was thinking of was to use now-existing savannah infrastructure, namely a public git repo. In a first approach, that repository could just contain the active release branches (branch-1-5, branch-2-2, master). These branches should always strictly go forward, i.e., existing history may not be undone. A concern about basing changes to stable branches on the master version (new term for head?) Yes, git uses the word master; since the term HEAD also has meaning in git, it's better to not confuse this. is that it seems to keep master from flourishing like it could. Perhaps it might cramp Gary's style. If this is wrong, then please explain further for the git-impaired. I have no idea whether Gary's style may be impacted, but I would doubt it. All I meant to say with cherry-picking from master to stable was: patches should not flow from older branches to newer branches. And we should avoid merging between the branches: merging brings in not only the most recent change, but all changes missing from the merge target's history. Since git is distributed, I think developers will have much more freedom in organizing their work as appropriate. Gary can have several branches of his own in his repo. In fact, I do have several Autoconf branches in my private repo, each representing work on a different issue. I frequently rebase them against the public master on savannah. If patches are retrieved from local trees, I assume that this requires that the local trees have a git server running? No. You can push from a private repo to the public one on savannah, if you have write access to it. Otherwise patches would need to be emailed or the local tree needs to belong to a maintainer with ability to submit to the golden repository. The apparent flexibility of git is confusing to me. Yeah, I know. It's very confusing at first, and typically needs someone to walk one through the first few steps. Gets better though. And no, emailing of patches is not more often necessary than now, i.e., mostly for posting OK to apply mails. That can even be done more easily, since there is a git format-patch command which will create formatted message(s) for this purpose. Cheers, Ralf
Re: git? branch-2-2?
On Tue, 4 Mar 2008, Ralf Wildenhues wrote: As far as cramping Gary's style goes, Gary (only used as an example here) is prone to making large changes, and these changes may soon render 'master' useless as a good source of patches for stable branches. Ah, no, this problem is easily avoided. git cherry-pick allows you to pick individual patches from one branch into another. My point is that as the master version advances in time, the baseline for submitted patches will become more and more different. Eventually a patch from the master version can not reasonably be applied against a stable branch. One reason why I have not contributed all that much to libtool sources is that the level of effort to produce an emailable patch for peer approval on this list substantially raises the bar for contribution. While the patch is waiting to be approved, the local changes sit uncommitted in a working directory, hindering further work on the same files. Each developer needed to develop his own system for working around this limitation. I never did. It seems that git has much more to offer to meet these needs than CVS does. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
libltdl skips dlopen loader if there are others
Hello,
this fixes one of the most long-standing regressions of 2.2 over
branch-1-5. It causes issues on every system that has not only the
dlopen loader, but also another one. I bet this is the cause for
some long-standing issues on w32.
On HP-UX, the lt_dladvise test fails with
| ../../libtool-2.1c/tests/lt_dladvise.at:316: $LIBTOOL --mode=execute $modules
./main; lt_status=$?;
|if test $lt_status -eq 0; then :;
|elif test X$host != X$build \
| { test -x ./main || test -x ./main$EXEEXT; }
|then (exit 77); else (exit $lt_status); fi
| Not enabling shell tracing (command contains an embedded newline)
| 4c4
| depend: 5
| ---
| depend: 4
| 38. lt_dladvise.at:28: 38. lt_dlopenadvise library loading
(lt_dladvise.at:28): FAILED (lt_dladvise.at:316)
In this test, there are two modules, one to be loaded RTLD_LOCAL and
one RTLD_GLOBAL. Using the wrong of two symbols 'i' causes the above
failure.
What happens here? HP-UX 11.23 has both dlopen and shl_load interfaces.
Only the dlopen interface knows how to load with RTLD_LOCAL. We
actually use prepend priority for dlopen, and append priority for
shl_load. Compiling with -DLT_DEBUG_LOADERS shows the dlopen loader is
never even used, although dlopen.a has successfully been preopened.
Further, when I munge the config.cache file fooling libtool into
thinking that shl_load does not work, the tests suddenly passes,
which proves that the dlopen loader works here.
So, after lots of searching (I first noted this bugs sometime last year)
I found that our linked list implementation is b0rked. I feel like Gary
and I both should run around with a rather big brown bag for a while ...
:-/
Gary, could you take care of pushing this change to upstream slist users
if any?
Cheers, and thanks,
Ralf
Fix libltdl to not skip dlopen on systems with several loaders,
such as HP-UX, Cygwin.
* libltdl/slist.c (slist_concat): When appending to the tail
of a list, do not drop items off the beginning of the list.
* NEWS: Update.
Index: NEWS
===
RCS file: /cvsroot/libtool/libtool/NEWS,v
retrieving revision 1.221
diff -u -r1.221 NEWS
--- NEWS4 Mar 2008 21:25:48 - 1.221
+++ NEWS4 Mar 2008 22:30:36 -
@@ -6,6 +6,8 @@
- Fix 2.2 regression in libltdl that causes memory corruption upon
repeated `lt_dlinit(); lt_dlexit()'.
+ - Fix 2.2 regression in libltdl that skipped the dlopen loader if
+the system also supports other loaders (e.g., Cygwin, HP-UX).
- Fix 2.2 regression in that `libtool --mode=execute CMD ARGS' does not
transform ARGS that do not look like shell or C wrappers of libtool
programs.
Index: libltdl/slist.c
===
RCS file: /cvsroot/libtool/libtool/libltdl/slist.c,v
retrieving revision 1.10
diff -u -r1.10 slist.c
--- libltdl/slist.c 7 Sep 2007 02:44:57 - 1.10
+++ libltdl/slist.c 4 Mar 2008 22:30:36 -
@@ -1,6 +1,6 @@
/* slist.c -- generalised singly linked lists
- Copyright (C) 2000, 2004, 2007 Free Software Foundation, Inc.
+ Copyright (C) 2000, 2004, 2007, 2008 Free Software Foundation, Inc.
Written by Gary V. Vaughan, 2000
NOTE: The canonical source of this file is maintained with the
@@ -140,15 +140,18 @@
SList *
slist_concat (SList *head, SList *tail)
{
+ SList *last;
+
if (!head)
{
return tail;
}
- while (head-next)
-head = head-next;
+ last = head;
+ while (last-next)
+last = last-next;
- head-next = tail;
+ last-next = tail;
return head;
}
Re: git? branch-2-2?
On Tue, 4 Mar 2008, Gary V. Vaughan wrote: My point is that as the master version advances in time, the baseline for submitted patches will become more and more different. Eventually a patch from the master version can not reasonably be applied against a stable branch. That's no different to the effort involved in porting fixes on branch-1-5 forward to HEAD in CVS. Exactly. This was not an easy chore even though CVS could give you a nice diff. If major libtool releases can occur much more often, then there should be less pain from maintaining branches. Incidentally, I suppose we should set about defining a sensible set of goals for Libtool 2.4 reasonably soon... I'll raise that again when 2.2.2 is done. The only two big things I can think of are o Better Windows support (for non-GNU compilers). o Multi-lib/multi-arch support (including building the libs). We have contributed patches for some of this already. I would be happy if 2.4 popped out with just the Windows part since multi-lib/multi-arch may be a big project and requires more consensus. It would also be nice if autoconf and libtool could work with a DTrace-fortified shell (http://blogs.sun.com/tpenta/entry/psarc_2008_008_dtrace_provider) so that we can do some really good performance profiling on it and make it faster. There is likely some low-lying fruit that we are not aware of. I'm looking forward to your patches now :-D My motiviations toward libtool are mostly selfish in that libtool is vital to other software I develop and maintain. When libtool becomes a blocker, then my motiviation level becomes high. :-) The 2.2 release is the first libtool release which satisfies all of my requirements (except for non-GNU Windows) in the last eleven years. In other words, it is the first libtool release that I feel comfortable with not using a development version in my released software. That is quite an achievement. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/
Re: git? branch-2-2?
Howdy Bob, On 4 Mar 2008, at 17:29, Bob Friesenhahn wrote: On Tue, 4 Mar 2008, Ralf Wildenhues wrote: As far as cramping Gary's style goes, Gary (only used as an example here) is prone to making large changes, and these changes may soon render 'master' useless as a good source of patches for stable branches. Ah, no, this problem is easily avoided. git cherry-pick allows you to pick individual patches from one branch into another. I feel cramped by CVS! That's why I invested considerable effort into maintaining an Arch mirror for my own work on Libtool. I feel that my style is to hardly work on the tree at all for months on end, and then when a flash of inspiration to improve some part of Libtool strikes: to work frenetically on deep changes for a while, and then back off while the dust settles :-) With a better distributed system, I'd happily confine my source quake to a public topic branch rather than juggling a private quilt patch stack. I'd like to think that might encourage people to jump in and help out with the deep changes, since they won't have to wait for me to pull back the curtain at the very end of my process to see what I've been doing. (Arch helped a lot in that regard, but was too much work to maintain outside of the blessed repository.) Also, if maintaining patches outside of master and stable (but still in public) is easy enough for me, I might feel a lot more inclined to help out with the more mundane aspects of maintaining Libtool rather than working away behind the scenes towards my occasional source-quakes. My point is that as the master version advances in time, the baseline for submitted patches will become more and more different. Eventually a patch from the master version can not reasonably be applied against a stable branch. That's no different to the effort involved in porting fixes on branch-1-5 forward to HEAD in CVS. Ideally, we should be aiming to release frequently enough that there isn't 4 years of difference between master and stable, so this can be a much smaller problem for future releases. Incidentally, I suppose we should set about defining a sensible set of goals for Libtool 2.4 reasonably soon... I'll raise that again when 2.2.2 is done. One reason why I have not contributed all that much to libtool sources is that the level of effort to produce an emailable patch for peer approval on this list substantially raises the bar for contribution. While the patch is waiting to be approved, the local changes sit uncommitted in a working directory, hindering further work on the same files. Each developer needed to develop his own system for working around this limitation. I never did. It seems that git has much more to offer to meet these needs than CVS does. I had a half baked solution in cvs-utils (from which our commit script is taken), and then moved to quilt which handles the ugly parts of tracking a moving target underneath our patches. Git makes all of this at least as easy, but without all the extra glue. I'm looking forward to your patches now :-D Cheers, Gary -- ())_. Email me: [EMAIL PROTECTED] ( '/ Read my blog: http://blog.azazil.net / )= ...and my book: http://sources.redhat.com/autobook `(_~)_ PGP.sig Description: This is a digitally signed message part
Re: libltdl skips dlopen loader if there are others
Ouch :-( Nice catch. On 4 Mar 2008, at 17:31, Ralf Wildenhues wrote: Gary, could you take care of pushing this change to upstream slist users if any? No other active projects are using slist to my knowledge (excepting some non-GNU stuff of my own). I have got some slist unit tests somewhere on my hard disk backups. If I haven't lost them, I'll port them into libtool presently -- which effectively holds the master copy of slist nowadays. Cheers, Gary -- =. Email me: [EMAIL PROTECTED] / @ @ /| Read my blog: http://blog.azazil.net \ \\ ...and my book: http://sources.redhat.com/autobook \^^\\ PGP.sig Description: This is a digitally signed message part
Re: git? branch-2-2?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 3/4/2008 1:56 PM: | Hello libtoolers, | | 1) Can we move to use git now? I sure hope so! It appears to have worked out well for coreutils, autoconf, automake, m4, and gnulib, which are all closely related projects. | | 2) Can we create a branch-2-2 and cherry-pick bugfixes from HEAD | into it, aiming for a soonish 2.2.2 (let's say, in a few weeks; | already a few important issues are known)? Fine by me. | | 3) If yes and yes, do you agree with the proposed git policy: | master should usually not contain merges except for merges from public | topic branches, should we have such in the future. Generally, master | should be the first to receive a patch, and stable branches should | cherry-pick from master. In your local trees, you should rebase private | topic branches against the upstream tree before inclusion. FYI, this is the same policy on automake. Coreutils, autoconf, and gnulib don't really have stable branches at the moment, although that could change. M4 has a stable branch (for 1.4.x) and a development branch (the eventual 2.0), but they have diverged so far (even before conversion to git) that I have lately been doing the reverse (apply patches to the branch, then cherry-pick into master). But I can live with your proposed policy for libtool, particularly since it means the master branch should never have regressions merely because a patch was applied to the stable branch and not ported forward. | I'm a bit unsure whether 2.2.2 should come before the move to git. | Comments appreciated. Once you have a git repository, you can use 'git cvsimport' incrementally as long as we want to keep the CVS repository alive. However, I found with autoconf that the month that I was manually syncing CVS and git was a bit awkward, and things went more smoothly once we committed to the master savannah repository being git only. - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHzhIV84KuGfSFAYARAhk7AKDFOm7vCDdEPpdnTcQ27JNu6CPpmQCgnvwW O41MpqrXfN7URD1gk6fXEgA= =FM8f -END PGP SIGNATURE-
Re: libtool generated by GNU $PACKAGE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Ralf Wildenhues on 3/4/2008 2:14 PM: | Fixed with the patch below. I don't care much that, in the Libtool | package itself, the will result in a libtool script with the line | # Generated automatically by config.status (libtool 1.2600 2008/03/02 02:19:16) 2.3a | | instead of GNU libtool. Hmm. While this avoids the bug, I'm not sure if it was the best fix. | # `$ECHO $ofile | sed 's%^.*/%%'` - Provide generalized library-building support services. | -# Generated automatically by $as_me (GNU $PACKAGE$TIMESTAMP) $VERSION | +# Generated automatically by $as_me ($PACKAGE$TIMESTAMP) $VERSION TIMESTAMP is a libtool invention, and is not documented in autoconf or automake as a typical variable. At one point, M4 also tried using it, by parsing the CVS revision from ChangeLog, but ever since m4 switched to git, that aspect is broken (besides, I like what autoconf has achieved with intra-release versioning via the git-version-gen script). Can we expect reasonable semantics from TIMESTAMP in all other libtoolized packages, if we don't document it? Meanwhile, is there one of the Autoconf-provided variables, such as PACKAGE_NAME, which might fit better (and in the case of libtool, preserve the name 'GNU libtool')? - -- Don't work too hard, make some time for fun as well! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.5 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHzhNz84KuGfSFAYARAjXyAKCG0gUxWNp20+nzPnF4P4rlCxkPdwCeIQjg kcOLg6gqYcxkKnVDWqS3iU0= =m0KX -END PGP SIGNATURE-
Re: git? branch-2-2?
Hi Gary, * Gary V. Vaughan wrote on Wed, Mar 05, 2008 at 12:10:30AM CET: On 4 Mar 2008, at 15:56, Ralf Wildenhues wrote: 2) Can we create a branch-2-2 and cherry-pick bugfixes from HEAD into it, aiming for a soonish 2.2.2 (let's say, in a few weeks; already a few important issues are known)? Is CVS HEAD already the recipient of destabilising patches? I had anticipated applying fixes on CVS HEAD for a while and then branching to save time moving patches between branches during the interim... Good thinking. All patches so far should strictly be bug fixes. If all the patches that went in so far are fixes, then let's wait until the last possible moment before branching, and save on the number of simultaneous branches we have to maintain. It's true that maintaining branches is much easier with git, as long as the trees are similar enough that cherry-picking between them works well. We already discovered that maintaining branch-1-5, branch-2-0 and HEAD was too much work. I think we should mothball branch-1-5 now, and apply everything to CVS HEAD until such times as a destabilising patch forces us to create branch-2-2. Fine with me. I think we should wait until we are reasonably sure that we won't need a maintenance release for several weeks before cutting over to git. 2.2.2 in a few weeks is a worthy goal (2.1b and 2.2 were on the first of the month, so April 1st seems like a good target), so lets use our resources to make that happen before worrying about git. That's a plan! Cheers, Ralf
Re: git? branch-2-2?
Ralf Wildenhues wrote: I think we should wait until we are reasonably sure that we won't need a maintenance release for several weeks before cutting over to git. 2.2.2 in a few weeks is a worthy goal (2.1b and 2.2 were on the first of the month, so April 1st seems like a good target), so lets use our resources to make that happen before worrying about git. That's a plan! I have just been reading the git documentation (the only thing I knew how to do until today was 'git pull'), looks like I will make an error or two for the first little while, but will be able to work on multiple problems at once (I share Bob's problem of never having worked out a system to do that with cvs). The above plan works for me. Peter -- Peter O'Gorman http://pogma.com
