1 From - Thu Jan 21 11:48:15 1999
2 Return-Path: <bug-libtool-request@gnu.org>
3 Received: from punt-2.mail.demon.net by mailstore
4 for gvaughan@oranda.demon.co.uk id 916916500:20:05273:1;
5 Thu, 21 Jan 99 11:01:40 GMT
6 Received: from mescaline.gnu.org ([158.121.106.21]) by punt-2.mail.demon.net
7 id aa2109043; 21 Jan 99 11:01 GMT
8 Received: (from slist@localhost)
9 by mescaline.gnu.org (8.9.1a/8.9.1) id GAA22496
10 for gvaughan@oranda.demon.co.uk; Thu, 21 Jan 1999 06:06:25 -0500
11 Resent-Date: Thu, 21 Jan 1999 06:06:25 -0500
12 Received: from hades.aethos.co.uk (router.aethos.co.uk [195.171.18.1] (may be forged))
13 by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id GAA22431;
14 Thu, 21 Jan 1999 06:04:57 -0500
15 Received: from [193.164.192.100] (helo=zeus.aethos.co.uk)
16 by hades.aethos.co.uk with esmtp (Exim 2.05 #1)
17 id 103HtW-000753-00; Thu, 21 Jan 1999 11:03:26 +0000
18 Received: from oranda.demon.co.uk (samhain.aethos.co.uk [193.164.192.38]) by zeus.aethos.co.uk with ESMTP (8.7.1/8.7.1) id LAA16759; Thu, 21 Jan 1999 11:00:22 GMT
19 Message-ID: <36A70897.32F60E81@oranda.demon.co.uk>
20 Date: Thu, 21 Jan 1999 10:59:35 +0000
21 From: "Gary V. Vaughan" <gvaughan@oranda.demon.co.uk>
22 Organization: Aethos Communication Systems Ltd.
23 X-Mailer: Mozilla 4.5 [en] (WinNT; I)
26 To: Akim Demaille <demaille@inf.enst.fr>
27 CC: Alexandre Oliva <oliva@dcc.unicamp.br>, Erez Zadok <ezk@cs.columbia.edu>,
28 bug-libtool@gnu.org, automake@gnu.org
29 Subject: Re: lazy question
30 References: <199901202104.QAA04372@shekel.mcl.cs.columbia.edu> <or1zkpr5tq.fsf@araguaia.dcc.unicamp.br> <qylu2xkq5l6.fsf@quasimodo.enst.fr>
31 Content-Type: text/plain; charset=us-ascii
32 Content-Transfer-Encoding: 7bit
33 Resent-Message-ID: <"420Yv3.0.qU5.Ydmfs"@mescaline.gnu.org>
34 Resent-From: bug-libtool@gnu.org
35 X-Mailing-List: <bug-libtool@gnu.org> archive/latest/413
36 X-Loop: bug-libtool@gnu.org
38 Resent-Sender: bug-libtool-request@gnu.org
39 X-Mozilla-Status: 8011
40 X-Mozilla-Status2: 00000000
41 X-UIDL: oranda.916916500:20:05273:1
45 > >>>>> "Alexandre" == Alexandre Oliva <oliva@dcc.unicamp.br> writes:
47 > Alexandre> On Jan 20, 1999, Erez Zadok <ezk@cs.columbia.edu> wrote:
48 > >> My application (am-utils) has this legacy stuff in my
49 > >> configure.in. I think I can safely take that out, now right?
51 > >> LTLIBOBJS=`echo "$LIBOBJS" | sed 's/\.o/.lo/g'` AC_SUBST(LTLIBOBJS)
52 > >> LTALLOCA=`echo "$ALLOCA" | sed 's/\.o/.lo/g'` AC_SUBST(LTALLOCA)
54 > Alexandre> Not really. It looks like automake provides LTLIBOBJS,
55 > Alexandre> but not LTALLOCA :-(
57 > Are you sure? I can't find the string LTLIBOBJS anywhere in the
60 It seems you are right. Nor can I find reference anywhere except in the
61 documentation of both libtool and automake. However, I stopped using
62 these variables a few months ago (just forgot to include them really),
63 and have suffered no ill effects.
65 > Alexandre> Unless it does but it's not documented.
67 > Another related issue is that Automake does not include the little
68 > needed magic that enables ansi2knr on LIBOBJS files. In addition to
69 > all this, people who want ansi2knr to be run should also include
72 > # This is necessary so that .o files in LIBOBJS are also built via
73 > # the ANSI2KNR-filtering rules.
74 > LIBOBJS=`echo $LIBOBJS|sed 's/\.o /\$U.o /g;s/\.o$/\$U.o/'`
76 > (Stolen from Jim Meyering's fileutils's configure.in).
78 Yes, that makes sense. Or rather, automake should do this for us if it
79 sees we are using ansi2knr.
81 > Also, it seems that now we should not append just
82 > replacement-function.o, but replacement-function.${ac_objext}[1].
84 > [1] What also mean that the above sed snippet should be adapted too.
88 > What is the real status of this? Since Automake reads these LIBOBJS
89 > extensions, if one solution is to be chosen, couldn't it issue
90 > warnings for non complying additions?
92 In my experience, Tom is very good about applying patches he receives.
93 =)O| Hopefully, I am too. =)O|
95 This probably needs to be fixed in all of auto{make,conf} and libtool
96 simultaneously. I don't have time to look at it right now, but I can
97 certainly add it to the libtool TODO if you are also busy.
102 From - Thu Jan 21 11:56:34 1999
103 Return-Path: <bug-libtool-request@gnu.org>
104 Received: from punt-2.mail.demon.net by mailstore
105 for gvaughan@oranda.demon.co.uk id 916919003:20:12487:14;
106 Thu, 21 Jan 99 11:43:23 GMT
107 Received: from mescaline.gnu.org ([158.121.106.21]) by punt-2.mail.demon.net
108 id aa2122944; 21 Jan 99 11:43 GMT
109 Received: (from slist@localhost)
110 by mescaline.gnu.org (8.9.1a/8.9.1) id GAA23386
111 for gvaughan@oranda.demon.co.uk; Thu, 21 Jan 1999 06:48:04 -0500
112 Resent-Date: Thu, 21 Jan 1999 06:48:04 -0500
113 Received: from ulysse.enst.fr (IDENT:1JXdBQbWjss9NS0/0RdVLAS9IgzJi29E@inf.enst.fr [137.194.2.81])
114 by mescaline.gnu.org (8.9.1a/8.9.1) with ESMTP id GAA23306;
115 Thu, 21 Jan 1999 06:46:02 -0500
116 Received: from quasimodo.enst.fr (quasimodo.enst.fr [137.194.160.2])
117 by ulysse.enst.fr (8.8.8/8.8.8) with ESMTP id MAA06955;
118 Thu, 21 Jan 1999 12:40:28 +0100 (MET)
119 Received: (from demaille@localhost)
120 by quasimodo.enst.fr (8.8.8/8.8.8) id MAA29306;
121 Thu, 21 Jan 1999 12:40:26 +0100 (MET)
122 Sender: demaille@inf.enst.fr
123 To: "Gary V. Vaughan" <gvaughan@oranda.demon.co.uk>
124 Cc: Alexandre Oliva <oliva@dcc.unicamp.br>, Erez Zadok <ezk@cs.columbia.edu>,
125 bug-libtool@gnu.org, automake@gnu.org, autoconf@gnu.org
126 Subject: Re: lazy question
127 References: <199901202104.QAA04372@shekel.mcl.cs.columbia.edu> <or1zkpr5tq.fsf@araguaia.dcc.unicamp.br> <qylu2xkq5l6.fsf@quasimodo.enst.fr> <36A70897.32F60E81@oranda.demon.co.uk>
128 Content-Type: text/plain; charset=US-ASCII
130 From: Akim Demaille <demaille@inf.enst.fr>
131 Date: 21 Jan 1999 12:40:25 +0100
132 In-Reply-To: "Gary V. Vaughan"'s message of "Thu, 21 Jan 1999 10:59:35 +0000"
133 Message-ID: <qylk8ygq2fq.fsf@quasimodo.enst.fr>
135 User-Agent: Gnus/5.070069 (Pterodactyl Gnus v0.69) XEmacs/21.2(beta8) (Artemis)
136 Resent-Message-ID: <"uGwfO1.0.gi5.2Enfs"@mescaline.gnu.org>
137 Resent-From: bug-libtool@gnu.org
138 X-Mailing-List: <bug-libtool@gnu.org> archive/latest/414
139 X-Loop: bug-libtool@gnu.org
141 Resent-Sender: bug-libtool-request@gnu.org
142 X-Mozilla-Status: 8011
143 X-Mozilla-Status2: 00000000
144 X-UIDL: oranda.916919003:20:12487:14
146 >>>>> "Gary" == Gary V Vaughan <gvaughan@oranda.demon.co.uk> writes:
148 >> What is the real status of this? Since Automake reads these
149 >> LIBOBJS extensions, if one solution is to be chosen, couldn't it
150 >> issue warnings for non complying additions?
152 Gary> In my experience, Tom is very good about applying patches he
153 Gary> receives. =)O| Hopefully, I am too. =)O|
157 Gary> This probably needs to be fixed in all of auto{make,conf} and
158 Gary> libtool simultaneously. I don't have time to look at it right
159 Gary> now, but I can certainly add it to the libtool TODO if you are
162 I might have a look, but it is sure safer to write it down somewhere :)
164 Also, since this is getting more and more tricky, and since I don't
165 find it's real fun to write down
167 LIBOBJS="$LIBOBJS blah.${ac_objext}"
169 we could introduce in Autoconf a macro taking care of this, no?
177 P-mail: Akim Demaille, 107 rue Bobillot, F-75013 Paris, France
178 E-mail: demaille@inf.enst.fr
179 V-mail: +33 1 45 81 78 81
181 Subject: Re: lazy question
182 Date: Mon, 25 Jan 1999 11:38:41 +0000
183 From: "Gary V. Vaughan" <gvaughan@oranda.demon.co.uk>
184 Organization: Aethos Communication Systems Ltd.
185 To: tromey@cygnus.com
186 CC: Akim Demaille <demaille@inf.enst.fr>,
187 Erez Zadok <ezk@cs.columbia.edu>, bug-libtool@gnu.org,
188 automake@gnu.org, autoconf@gnu.org
192 > >> AC_LIBOBJS(blah)
194 > Gary> Agreed. Also added to the archive.
196 > I'm suprised this isn't already there, since this subject has come up
197 > many times before. I'm sure I mentioned it to Gord more than once.
199 > Basically, I think the right solution is to add some new
200 > functionality to autoconf that would let a user defer a piece of code
201 > to be run just before AC_OUTPUT. Then the libtool macro would
202 > arrange to defer computation (and AC_SUBSTitution) of LTLIBOBJS and
203 > LTALLOCA until that time.
205 That sounds like a good, general, solution to me. I'm adding this mail
206 to the libtool mail archive too =)O|
208 > This probably isn't even that hard to do; I just haven't done it. I
209 > wonder if it is on Ben's to-do list? Or perhaps one of the libtool
210 > hackers could submit the patch?
212 We are teetering on the edge of a 1.3 release, which must be compatible
213 with autoconf-2.13 and automake-1.4. After that, I will try to submit a
214 patch to Ben (stop me if you have this in your pending queue!).
216 > In any case I don't think it is an automake problem per se.