[SCM] GNU Libtool branch, master, updated. release-2-2-2-18-gd9a4d8f

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project GNU Libtool. The branch, master has been updated via d9a4d8f71ae415bb716dc8267a506a102bacf0b2 (commit) from

Re: [libtool-2.2.2] testsuite on NFS mount on AIX

On Mon, 2008-04-21 at 09:29 +0200, Michael Haubenwallner wrote: On Sat, 2008-04-19 at 18:40 +0200, Ralf Wildenhues wrote: Hello Michael, * Michael Haubenwallner wrote on Fri, Apr 18, 2008 at 04:59:43PM CEST: when doing the libtool testsuite in some NFS mounted directory on AIX,

Re: libtool performance status

On Mon, 21 Apr 2008, Ralf Wildenhues wrote: If they were lower in between, and since increased, there must have been at least one regression along the way. Can you use git bisect to identify one? Remember that you fixed an expr-related bug which was impacting FreeBSD and causing an error

FYI - Use AC_CHECK_TOOL for lipo too.

Hi, I just pushed this. Peter -- Peter O'Gorman http://pogma.com From 39903a5836fc563e83fe6aa614d75a2a3ebe04fe Mon Sep 17 00:00:00 2001 From: Peter O'Gorman [EMAIL PROTECTED] Date: Mon, 21 Apr 2008 10:21:27 -0500 Subject: [PATCH] Use AC_CHECK_TOOL for lipo too. * libltdl/m4/libtool.m4

Re: [PATCH 363] Allow better compile time type checking for lt_dladvise

On Mon, 21 Apr 2008, Ralf Wildenhues wrote: Does this work with C and C++ compilers? Does it change the ABI or API? If yes, no, then I like it. Otherwise, as nice as it is, it would be a bit inappropriate for a minor release number, no? I use this approach in GraphicsMagick C code without

Re: FYI - Use AC_CHECK_TOOL for lipo too.

On Mon, 21 Apr 2008, Peter O'Gorman wrote: Hi, I just pushed this. Since the full patch appears on the [EMAIL PROTECTED] list, perhaps it is not necessary to manually duplicate already committed patches on this list? What are the official rules regarding when the patch must be posted to

Re: FYI - Use AC_CHECK_TOOL for lipo too.

Hi Bob, * Bob Friesenhahn wrote on Mon, Apr 21, 2008 at 07:25:10PM CEST: Since the full patch appears on the [EMAIL PROTECTED] list, perhaps it is not necessary to manually duplicate already committed patches on this list? It's an idea. However, those commit messages - don't allow to add

Re: darwin fat binary support bugfix

Peter O'Gorman wrote: I will fix, and even apply the (non-failing) test tomorrow. Making the test fail is better. Ok? Peter -- Peter O'Gorman http://pogma.com From d9a4d8f71ae415bb716dc8267a506a102bacf0b2 Mon Sep 17 00:00:00 2001 From: Peter O'Gorman [EMAIL PROTECTED] Date: Mon, 21 Apr 2008

Re: darwin fat binary support bugfix

Hi Peter, On 21 Apr 2008, at 16:20, Peter O'Gorman wrote: Peter O'Gorman wrote: I will fix, and even apply the (non-failing) test tomorrow. Making the test fail is better. Ok? Looks good to me. Please apply. Peter -- Peter O'Gorman http://pogma.com From

Re: libtool performance status

* Bob Friesenhahn wrote on Mon, Apr 21, 2008 at 05:14:00PM CEST: On Mon, 21 Apr 2008, Ralf Wildenhues wrote: If they were lower in between, and since increased, there must have been at least one regression along the way. Can you use git bisect to identify one? Remember that you fixed an

Re: silencing libtool and automake

Hello Joachim, * Joachim Worringen wrote on Mon, Apr 21, 2008 at 11:16:05AM CEST: We use libtool/automake/configure for our builds, but autotools-builds are pretty verbose, which is not always desired. I checked that by adding the @ silencer in the Makefiles and calling libtool with

silencing libtool and automake

We use libtool/automake/configure for our builds, but autotools-builds are pretty verbose, which is not always desired. I checked that by adding the @ silencer in the Makefiles and calling libtool with --silent we get what we want. How can I create such Makefiles via autoreconf configure?

Re: move to git

On Sat, Apr 19, 2008 at 2:53 AM, Jim Meyering [EMAIL PROTECTED] wrote: Ralf Wildenhues [EMAIL PROTECTED] wrote: I don't quite understand what happened. With the repo converted from CVS, the tag SHAs were all different, but they already pointed to the same tree object. After the

Re: move to git

Dan Nicholson [EMAIL PROTECTED] wrote: On Sat, Apr 19, 2008 at 2:53 AM, Jim Meyering [EMAIL PROTECTED] wrote: Ralf Wildenhues [EMAIL PROTECTED] wrote: I don't quite understand what happened. With the repo converted from CVS, the tag SHAs were all different, but they already pointed to

Re: silencing libtool and automake

On Mon, 21 Apr 2008, Joachim Worringen wrote: We use libtool/automake/configure for our builds, but autotools-builds are pretty verbose, which is not always desired. I checked that by adding the @ silencer in the Makefiles and calling libtool with --silent we get what we want. Using

Problems with libtool 2.2.2 and /bin/sh pointing to dash

Hi, I've had reports of Poky breaking with libtool 2.2.2 and have isolated this to people using dash as their /bin/sh provider (Poky runs the configure script with /bin/sh). When used in this combination, the global_symbol_pipe expression becomes corrupted in the generated libtool file amongst

Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash

Hi Richard, On 21 Apr 2008, at 19:07, Richard Purdie wrote: gtk+ also has the issues that it tries to run libtool before its been generated and I've had to patch this to run a previously generated version of libtool poky has around to solve cases like this. I'm not sure if there is a neater way

Re: Problems with libtool 2.2.2 and /bin/sh pointing to dash

Hello Richard, * Richard Purdie wrote on Tue, Apr 22, 2008 at 01:07:48AM CEST: I've had reports of Poky breaking with libtool 2.2.2 and have isolated this to people using dash as their /bin/sh provider (Poky runs the configure script with /bin/sh). When used in this combination, the