[patch #6442] Allow Microsoft lib to be used as the archiver.

URL: Summary: Allow Microsoft lib to be used as the archiver. Project: GNU Libtool Submitted by: pekberg Submitted on: Tuesday 03/04/2008 at 10:52 Category: None Prior

[patch #6443] [MSVC 2/7] On Windows, find potential libs regardless of file name case.

URL: 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: N

[patch #6444] [MSVC 3/7] The MSVC linker doesn't have a -L option

URL: Summary: [MSVC 3/7] The MSVC linker doesn't have a -L option Project: GNU Libtool Submitted by: pekberg Submitted on: Tuesday 03/04/2008 at 10:58 Category: None P

[patch #6445] [MSVC 4/7] MSVC needs a hint to force it to compile either as C or C++.

URL: Summary: [MSVC 4/7] MSVC needs a hint to force it to compile either as C or C++. Project: GNU Libtool Submitted by: pekberg Submitted on: Tuesday 03/04/2008 at 10:59 Category: No

[patch #6446] MSVC [5/7] MSVC doesn't support the -l option, instead it expects the exact library file name

URL: 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

[patch #6447] MSVC [6/7] Indicate if the archiver supports a listing file

URL: 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

[patch #6448] [MSVC 7/7] Add MSVC Support

URL: Summary: [MSVC 7/7] Add MSVC Support Project: GNU Libtool Submitted by: pekberg Submitted on: Tuesday 03/04/2008 at 11:04 Category: None Priority: 5 - Normal

[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 (_L

[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

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

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.

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.te

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 p

Re: git? branch-2-2?

On Tue, 4 Mar 2008, Ralf Wildenhues wrote: Hello libtoolers, 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. 3) If yes and yes, do you a

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 '/h

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

Re: git? branch-2-2?

On Tue, 4 Mar 2008, Ralf Wildenhues wrote: 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. So

Re: git? branch-2-2?

* Bob Friesenhahn wrote on Tue, Mar 04, 2008 at 11:04:39PM CET: > On Tue, 4 Mar 2008, Ralf Wildenhues wrote: > >> 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-pa

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

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

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

Re: git? branch-2-2?

Hallo Ralf, On 4 Mar 2008, at 15:56, Ralf Wildenhues wrote: 1) Can we move to use git now? Finally!! Yes, please. 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 C

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 st

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 some

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. |

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 20

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

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 targe