Re: libtool-2.0 release

Hi Gary, * Gary V. Vaughan wrote on Fri, Feb 03, 2006 at 01:06:40PM CET: > Ralf Wildenhues wrote: > > > > - Makefile.am rules somewhere use GNU make 3.80 features. I have > > encountered many difficulties preventing autotools reruns on other > > systems, and am quite fed up with hunting these

Re: libtool-2.0 release

a note to the extent that they are deprecated and are subject to eventual removal. The fact that these older macros still work is vital to the acceptance of libtool 2.0. Well, this comment of Bob completely mystifies me: http://article.gmane.org/gmane.comp.gnu.libtool.patches/6582 I believe in t

Re: libtool-2.0 release

* Gary V. Vaughan wrote on Fri, Feb 03, 2006 at 03:43:11PM CET: > > [Is the personal Cc: okay? The list lag is so long that I've gotten into > the habit of Cc:ing you back in so you don't have to wait half a day to > get this.] Yes, surely. There was one point in time where I fixed my gnu.org

Re: libtool-2.0 release

Hi Gary, * Gary V. Vaughan wrote on Fri, Feb 03, 2006 at 01:06:40PM CET: > Ralf Wildenhues wrote: > > > > However, I have absolutely no problem with delaying the application of > > the per-deplibs-flags patch to shortly after 2.0.0 or 2.0.2. Although > > we should still commit both the `-static'

Re: libtool-2.0 release

Ralf Wildenhues wrote: > Hi Gary, Hallo Ralf! > Gary V. Vaughan writes: >> Now is the time to branch! Either a feature branch for developing the >> per-deplib feature for merging after 2.0, or else a 2.0 branch that we >> can keep stable. > > No way, without me. I outright refuse to maintain a

Re: libtool-2.0 release

Ralf Wildenhues wrote: > Hi Gary, Hallo Ralf! [Is the personal Cc: okay? The list lag is so long that I've gotten into the habit of Cc:ing you back in so you don't have to wait half a day to get this.] > > > > * LT_WITH_LTDL should build libltdl by default; currently > > > >nothing

Re: libtool-2.0 release [WAS per-deplib static/dynamic flags]

ways run via a shell script wrapper (gcc-64) which always runs gcc with -m64 so I am not sure what libtool did to encourage gcc to undo the effect of that option. I have been re-libtoolizing various projects with libtool 2.0 and have encountered resounding success with MinGW

Re: libtool-2.0 release

Hi Gary, Gary V. Vaughan writes: > > Is this patch really necessary for 2.0? No. > I think that introducing so > much code churn in to libtool at this stage is going to bring yet more > release delays. Surely the feature is useful and desireable, but I > really *really* want to avoid more delay

libtool-2.0 release [WAS per-deplib static/dynamic flags]

. test like crazy. and fix any platform issues uncovered GVV 6. release libtool-2.0 already! GVV Once 2.0 is finally out, I will take a back seat with libtool for a while to work on m4-2.0 and my new book. Ralf Wildenhues wrote: > Hi Bob, Albert, > &

Re: TODO 2.x: Using libtool 2.0 in autoconf tests

* Sander Niemeijer wrote on Wed, Aug 24, 2005 at 10:54:53AM CEST: I would appreciate it if an item could be added to the TODO list for the new 2.x branch that solves the issue discussed in the following thread from about a year ago: http://lists.gnu.org/archive/html/libtool/2004-11/msg00372.html

Re: TODO 2.x: Using libtool 2.0 in autoconf tests

Hi Sander, On 24 Aug 2005, at 09:54, Sander Niemeijer wrote: I would appreciate it if an item could be added to the TODO list for the new 2.x branch that solves the issue discussed in the following thread from about a year ago: http://lists.gnu.org/archive/html/libtool/2004-11/msg00372.ht

Re: TODO 2.x: Using libtool 2.0 in autoconf tests

Hi Sander, * Sander Niemeijer wrote on Wed, Aug 24, 2005 at 10:54:53AM CEST: > I would appreciate it if an item could be added to the TODO list for > the new 2.x branch that solves the issue discussed in the following > thread from about a year ago: > > http://lists.gnu.org/archive/html/libtool

TODO 2.x: Using libtool 2.0 in autoconf tests

I would appreciate it if an item could be added to the TODO list for the new 2.x branch that solves the issue discussed in the following thread from about a year ago: http://lists.gnu.org/archive/html/libtool/2004-11/msg00372.html Best regards, Sander Niemeijer _

Re: Using libtool 2.0 in autoconf tests

Gary V. Vaughan wrote: So we need an LT_CHECK_LIB macro in libtool-2-0, which may be possible by looking in .la files and the results of the other libtool configure time tests to construct an ld based link line -- or may force us to go back to a non-config.status generated libtool. Either way, the

Re: Using libtool 2.0 in autoconf tests

soon as the LT_INIT macro is complete, though there will be issues with quoting, as things are quoted one extra time because of the intervening config.status. In my configure.ac file, which I have been updating for libtool-2.0, LT_LANG(C++) occurs after LT_INIT() so it seems that the above stat

Re: Using libtool 2.0 in autoconf tests

Oversimplifying, but: In a configure script, you can spell `libtool -[options] [objects]' as `LT_CHECK_LIB([options], [objects])'. Maybe we need LT_LINK_IFELSE instead/as well. What I need is a replacement for the LT_AC_LINK_SHLIB_IFELSE macro in:

Re: Using libtool 2.0 in autoconf tests

Hi Sander, Sander Niemeijer wrote: > If more people require this functionality then I am all for including it > in the libtool package. However, this doesn't answer the question > whether the macro should be based on a libtool script or not. > Furthermore, other users might have other macros that

Re: Using libtool 2.0 in autoconf tests

Agreed. I think that there are a small number of circumstances where the early-build of libtool was genuinely useful, and I think we should be able to wrap each of those cases is a shipped macro that leverages the knowledge already probed for libtool without needing to actually have a libtool scri

Re: Using libtool 2.0 in autoconf tests

using libtool > for library link testing _at configure time_ is really necessary, and > not having it makes our projects work less well than they should. Like > Sander, I have built some home-grown autoconf macros to use libtool for > link testing at configure time, and if libtool-2.0 will

Re: Using libtool 2.0 in autoconf tests

On maandag, nov 22, 2004, at 15:29 Europe/Amsterdam, Gary V. Vaughan wrote: Hallo Ralf, Ralf Wildenhues wrote: C'mon Gary, two questions: is it *possible* to provide the old behavior without too much pain? I can't think of a way to do it cleanly :-( But I have no objections in principle. How

Re: Using libtool 2.0 in autoconf tests

t; ltmain.sh)? If this is it, then so be it and I will try to rewrite my > autoconf test to use the lt_/ltmain.sh combination for libtool 2.0, > but libtool 2.0 surely won't get my vote for the > best-design-of-the-year-award. No no, I think that the post-1.5 interface is incomplete. A

Re: Using libtool 2.0 in autoconf tests

es our projects work less well than they should. Like Sander, I have built some home-grown autoconf macros to use libtool for link testing at configure time, and if libtool-2.0 will no longer support this activity I'll have a significant problem. ___

Re: Using libtool 2.0 in autoconf tests

Hallo Ralf, Ralf Wildenhues wrote: > C'mon Gary, two questions: is it *possible* to provide the old behavior > without too much pain? I can't think of a way to do it cleanly :-( But I have no objections in principle. How much machinery is there to make the config.status parts of AC_OUTPUT work?

Re: Using libtool 2.0 in autoconf tests

ppropriate libtool commands and call AC_CHECK_LIB). The issue is a real one, and should be addressed. I am not convinced that it need be addressed for libtool-2.0 though, nor that it requires reverting to libtool-1.5 behavior. Don't tell me you are saying that I won't be able to use l

Re: Using libtool 2.0 in autoconf tests

ssues with quoting, as things are quoted one extra time because of the intervening config.status. The issue is a real one, and should be addressed. I am not convinced that it need be addressed for libtool-2.0 though, nor that it requires reverting to libtool-1.5 behavior. Peter -- Peter O'Gor

Re: Using libtool 2.0 in autoconf tests

> variables and ltmain.sh)? If this is it, then so be it and I will try > to rewrite my autoconf test to use the lt_/ltmain.sh combination for > libtool 2.0, > but libtool 2.0 surely won't get my vote for the > best-design-of-the-year-award. C'mon Gary, two questions: is i

Re: Using libtool 2.0 in autoconf tests

d one to use from the configure script (some undocumented combination of lt_ variables and ltmain.sh)? If this is it, then so be it and I will try to rewrite my autoconf test to use the lt_/ltmain.sh combination for libtool 2.0, but libtool 2.0 surely won't get my vote for the best-design-o

RE: Using libtool 2.0 in autoconf tests

Gary V. Vaughan wrote: > Ralf Wildenhues wrote: >> * Sander Niemeijer wrote on Thu, Nov 18, 2004 at 01:54:12PM CET: >>> >>> I have some self written autoconf tests that check for linking >>> shared libraries against some specific other libraries (these other >>> libraries should be available as sh

Re: Using libtool 2.0 in autoconf tests

Ralf Wildenhues wrote: * Sander Niemeijer wrote on Thu, Nov 18, 2004 at 01:54:12PM CET: I have some self written autoconf tests that check for linking shared libraries against some specific other libraries (these other libraries should be available as shared libraries or we might have a PIC probl

Re: Using libtool 2.0 in autoconf tests

* Sander Niemeijer wrote on Thu, Nov 18, 2004 at 01:54:12PM CET: > > I have send this question to the list about a month ago, but > unfortunately, there hasn't been an answer yet, and the release of > libtool 2.0 is not that far away (right?). Hmm. We need to at least wait

RE: Using libtool 2.0 in autoconf tests

Sander Niemeijer wrote: > Hi, > > I have send this question to the list about a month ago, but > unfortunately, there hasn't been an answer yet, and the release of > libtool 2.0 is not that far away (right?). > > <http://lists.gnu.org/archive/html/libtool/2

Using libtool 2.0 in autoconf tests

Hi, I have send this question to the list about a month ago, but unfortunately, there hasn't been an answer yet, and the release of libtool 2.0 is not that far away (right?). <http://lists.gnu.org/archive/html/libtool/2004-10/msg00219.html> <http://lists.gnu.org/archive/html/l

Re: libtool-2.0

libtool. As discussed on the list already, the only (marginal) case where having a compiled translator as part of libtool would be when cross compiling from an environment with no host compiler -- and as Ezra rightly pointed out, we could foster a binary distribution model for the `u' interpreter to

Re: libtool-2.0

On Feb 26, 2000, "Gary V. Vaughan" <[EMAIL PROTECTED]> wrote: > making it relatively similar to bourne shell wouldn't hurt since that > is already a known quantity, and will be easier for maintainers to get > to grips with In fact, if we could keep it fully compatible with (a subset of) Bourne s

Re: libtool-2.0

On Sat, Feb 26, 2000 at 11:29:23AM -0500, Ezra Peisach wrote: > > > Ok - I'm game. Do you have any ground rules regarding the syntax of "u"? Well, the higher level we can make it, the better. On the other hand, making it relatively similar to bourne shell wouldn't hurt since that is already a

Re: libtool-2.0

Ok - I'm game. Do you have any ground rules regarding the syntax of "u"? For instance, will you support functions, cleanup handlers, and system builtins? I am assuming basic conditionals, loops, etc. In looking at the simple compile example, you need to be able to lock/unlock a file, create s

Re: libtool-2.0

at is probably a better solution in some cases, and much lighter than having to install a full host compiler suite. > There is the issue of making sure to use the host compiler to build > libtool and the cross compiler should be used by libtool. I think the > binutils package has alread