fix this: either teach `depcomp' to stick
`-Wc,' or `-Xcompiler' before dependency tracking options when
running libtool (some depcomp modes such as aix already do that
properly), or teach `libtool' to ignore options (`-*') when
updating $srcfile. Which one seems more sensible? both?
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Ted> configure does a prior check of gcc with -c and -o, and
Ted> that passes.
Ted> I have no idea why the configure check is using CFLAGS instead of
Ted> CXXFLAGS. I changed the CXXFLAGS in ACX_CXXCOMPILE to
Ted> AM_CXXFLAGS, but that made no difference.
It
for a fix:
http://mail.gnu.org/pipermail/automake-patches/2001-September/000234.html
http://mail.gnu.org/pipermail/automake-patches/2001-October/000367.html
[...]
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
>>> "Bruno" == Bruno Haible <[EMAIL PROTECTED]> writes:
[...]
Bruno> all-local $(libfoo_la_OBJECTS): $(ARGZ_H)
Hmmm, why do you need this since $(ARGZ_H) is already in
$(BUILT_SOURCES), and "all" depends on $(BU
On Thu, Feb 16, 2006 at 04:22:24PM +1100, Brendon Costa wrote:
>
> The configure script exports the following two variables for use in
> automake that help with versioning:
>
> PACKAGE_VERSION 1.0.6
> PACKAGE_VERSION_UNDERSCORE 1_0_6
>
Sorry, that makes no sense : the substitutions a
On Thu, Feb 16, 2006 at 03:55:44PM +0100, Alexandre Duret-Lutz wrote:
> Take the string "[EMAIL PROTECTED]@.la" (that's what
> Automake reads). To canonize it, replace characters that are neither
I meant to write "canonicalize". The above mistake should not be
la
Unless `php-config --extension-dir` returns something like
$(prefix)/foo/bar, this setup will prevent non-root
installations and cause distcheck to fail.
See the "Hard-Coded Install Paths" of the Automake FAQ for
inspiration.
--
Alexandre Duret-Lutz
lls a "Hello World!" example package in $(docdir).
This example is used throughout the new "Autotools Introduction"
chapter of the manual.
--
Alexandre Duret-Lutz
pgpF7loYDj2zG.pgp
Description: PGP signature
___
http://lists.gnu.org/mailman/listinfo/libtool
times appends things like `-Wc,-M', but
I'm using the equivalent `-Xcompiler -M' here because it seems
your patch remove the support for this.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
[...]
adl> libtool --compile gcc -c foo.c -Xcompiler -M
Of course, I meant
libtool --mode=compile gcc -c foo.c -Xcompiler -M
[...]
--
Alexandre Duret-Lutz
.gnu.org/pipermail/libtool-patches/2002-March/001767.html
A similar fix is present in Alexander Bluhm's set of patches
against version 1.4.2:
http://mail.gnu.org/pipermail/libtool-patches/2002-March/001770.html
[...]
--
Alexandre Duret-Lutz
__
Can you try Automake 1.6.1? It should clean subdir libtool objects correctly.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
>>> "Patrick" == Patrick Guio <[EMAIL PROTECTED]> writes:
[...]
Patrick> am_libmudfas2d_la_OBJECTS = $(am__objects_1)
Patrick> am_libmudfas3d_la_OBJECTS = $(am__objects_1)
[...]
This will be fixed in Automake 1.6.2. It is already fixed in
Here is a snapshot of the current development version of Automake.
This should become Automake 1.7 *soon*. How soon will depends on
the feedback we get on this beta.
Please get it, install it, test it, torture it.
Please report any issue by mail to <[EMAIL PROTECTED]>,
or (preferred) using the
mail/libtool/2002-August/006640.html
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
lways distributed.
* Use Autoconf's --trace interface to inspect configure.ac and get
a more accurate view of it.
* Add support for extending aclocal's default macro search path
using a `dirlist' file within the aclocal directory.
* automake --ou
one as PR automake/350.
Harlan> Is there a workaround/bugfix?
Here is a workaround. Define FOO_AB as "FOO_A or FOO_B"":
AM_CONDITIONAL(FOO_AB, test x"$FOO" = xa || test x"$FOO" = xb)
then use FOO_AB to define lib_LTLIBRARIES in a single place.
--
Alexa
released version of libtool that
Ralf> is usable with autoconf-2.54 and automake-1.7
Not exactly: there is no release of Libtool that honors
AC_CONFIG_AUX_DIR in configure.*ac*.
Ralf> .. still nobody wanting to care to fix it?
AFAICT it&
We're pleased to announce the release of Automake 1.7. This release
contains many bug fixes and improvements. The NEWS entry is appended.
You can find the new release here:
ftp://sources.redhat.com/pub/automake/automake-1.7.tar.gz
ftp://sources.redhat.com/pub/automake/automake-1.7.tar.
We're pleased to announce the release of Automake 1.7.1
This is a bug fix release. The list of fixed bugs is appended below.
You can find the new release here:
ftp://sources.redhat.com/pub/automake/automake-1.7.1.tar.gz
ftp://sources.redhat.com/pub/automake/automake-1.7.1.tar.bz2
Soon
toconf 2.54c announcement entirely :)
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
mething like `*.o'; second, it should not output
`-L../autoopts/.libs -lopts' but `../autoopts/libopts.la'
since Bruce said `autogen_LDADD = $(top_builddir)/autoopts/libopts.la'.
I'm tempted to think that the link rule was hand-edited (either in the
Makefile(|.in|.am), or i
>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes:
Bruce> Alexandre Duret-Lutz wrote:
>> >> /bin/sh ../libtool --mode=link gcc -g -O2 -L/sw/lib -o autogen \
>> >> -export-dynamic -lguile *.o -L/sw/lib -lguile -lm \
>> >&
We're pleased to announce the release of Automake 1.7.2
This is a bug fix release. The list of bug fixes is appended.
You can find the new release here:
ftp://ftp.gnu.org/gnu/automake/automake-1.7.2.tar.bz2
ftp://ftp.gnu.org/gnu/automake/automake-1.7.2.tar.gz
ftp://sources.redhat.com
Would it make sense that Automake start using
`libtool --mode=clean rm -f ...' during `make clean',
or has there been any trouble with this feature recently?
Has it been tested in any way? A can't find any occurence of
`mode=clean' in the Libtool test suite.
--
ease do so! If not, your woes may have to wait for
Robert> 1.5.1.
Great news! How about making a test release (1.4f, say), and
announcing it to more that just [EMAIL PROTECTED] to get wider
testing?
The last snapshot of this branch (1.4d) is one year old, and not
everybody is able to test L
ng anybody listed in
ChangeLog entries since the last release (this is mainly to make
sure bug reporters have a chance to check that their bug is
fixed before the real release).
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
afford reading each tool's list, but still would like to
hear about new releases, or are willing to test pre-releases. If you
know such people, please tell them.
You can subscribe here:
http://mail.gnu.org/mailman/listinfo/autotools-announce
Cheers,
--
Alexandre Duret
ibltdl/configure.in, and replace the above code by
AC_CONFIG_AUX_DIR([../tools]) so that Automake find its files.
If you decide to start shipping auxiliary files with libltdl,
then this code can be changed to AC_CONFIG_AUX_DIR([.]). I
suppose some people will mind about the extra ki
_LT_AC_TAGCONFIG.)
As I see it, the only way to achieve what you want would be to
rewrite the `case $tagname' switch from _LT_AC_TAGCONFIG in
plain M4 (instead of shell). This way you can ensure that
AC_LIBTOOL_LANG_CXX_CONFIG is expanded only if AC_PROG_CXX has
been called first. Likewise fo
e other. E.g.,
# I only use Libtool with C programs, I don't need it for C++.
...
AC_PROG_CC
AC_PROG_LIBTOOL
AC_PROG_CXX
...
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
of
m4_case([_LT_TAG],
[C], ,
[CXX], [...],
[F77], [...],
[GCJ], [...],
[RC], [...],
[m4_fatal([unsupported tag name: ]"_LT_TAG")])
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECT
ress the "once for all" part would be to write a
test case.
[...]
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Thu, Sep 25, 2003 at 11:40:26PM +0900, Peter O'Gorman wrote:
> I kept getting crap like this:
> autoreconf: running: automake --add-missing --copy --force-missing
> Can't locate object method "TIEHASH" via package
> "Tie::RefHash::Nestable" at /usr/local/bin/automake line 517.
> autoreconf: fail
On Fri, Sep 26, 2003 at 12:27:42AM +0900, Peter O'Gorman wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Alexandre Duret-Lutz wrote:
> | This seems to be an old version of Automake. The last Nestable
> | use was removed on 2003-08-12.
>
> I just check
at would be counter
intuitive. IMHO any numbering scheme ought to work with `ls -v'.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
annot
mis-sort versions with letters with others. It could also gives
some feeling of sense to accustomed to the odd/even version
numbering scheme of Linux.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
IL PROTECTED]
http://mail.gnu.org/mailman/listinfo/autotools-announce
[...]
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Tue, Nov 25, 2003 at 01:39:10PM +, Gary V. Vaughan wrote:
>
> Good point. As long as we ship Makefile.in (and libtoolize --ltdl installs
> only Makefile.in if $configure_ac has no reference to AM_INIT_AUTOMAKE) that
> should satisfy the autoconf/libtool only audience...
Hmm... you can't use
On Tue, Nov 25, 2003 at 02:31:10PM +, Gary V. Vaughan wrote:
> | To support this you need to rewrite Makefile.in without Automake (as
> | Gettext does), or let these people AC_CONFIG_SUBDIRS the selfcontained
> | libltdl package.
>
> Okay. Since we are trying to get rid of AC_CONFIG_SUBDIRS, w
On Tue, Nov 25, 2003 at 03:07:53PM +, Gary V. Vaughan wrote:
>
> I thought you meant that Bruno had a macro that did AM_INIT_AUTOMAKE-a-like
> AC_SUBSTing for gettext's needs, and that another similar macro could do the
> necessary for libltdl. Would that it were so simple ;-)
Wait a minute, w
On Tue, Nov 25, 2003 at 03:35:25PM +, Gary V. Vaughan wrote:
> If so, all we need is to add a call to AM_INIT_AUTOMAKE to
> AC_LIB_LTDL. Hmmm, but then if a non-automake project calls
> AC_LIB_LTDL, when they run autoreconf, it will run automake -a :-(
Running automake in this case sounds sen
Hi people,
This is the third beta release of the next version of Automake (1.8).
Please try it and help us fixing as much bug as possible.
If no important bug are reported against this version, I think it is
ready to be called 1.8.
I've appended the changes since 1.7d, as well as the updated full
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
adl> This is the third beta release of the next version of Automake (1.8).
Sorry I messed with the URLs. The release is 1.7f, not 1.7e.
Here are the corrected URL.
ftp://alpha.gnu.org/gnu/autom
Hi people,
Due to two last minute new features, we have yet another weekly beta
of Automake 1.8. I sincerly hope this is the last one. If you are
not blasé, or if you have not had the occasion to test previous
versions, please give this one a try.
You can find this beta here:
ftp://alpha.g
erim.net/pub/libtool-CVSROOT.tar.bz2
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
We're pleased to announce the release of Automake 1.8.
Automake is a tool for automatically generating `Makefile.in's
suitable for use with Autoconf, compliant with the GNU Makefile
standards, and portable to various make implementations.
This release contains many bug fixes and improvements. Th
On Wed, Dec 31, 2003 at 02:11:34PM +, Scott James Remnant wrote:
> The script and everything under CVSROOT that logged our commits and sent
> them to [EMAIL PROTECTED] has been lost.
>
> Don't suppose anyone kept a copy of this around, and could re-add it to
> CVSROOT (possibly fixing the broke
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
[...about Automake passing --tag=XXX to libtool...]
Gary> Alexandre Duret-Lutz wrote:
>> >> How can automake determine whether the version of libtool used in
>> >> a package supports --
>>> "adl" == Alexandre Duret-Lutz <[EMAIL PROTECTED]> writes:
[...]
adl> 2004-01-02 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
adl> Fix for PR automake/289:
adl> * automake.in (Automake::Struct::libtool_tag): New attribute. Define
adl> it for
all libraries, and once it is done relink all
libraries. Would that work? If so, we need a way to tell
libtool to copy libraries without relinking.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
clocal replacement. As aclocal is slowly moving towards its
replacement (which cannot exist yet because it requires M4
support), a next aclocal version may even include a --copy or
--update option to try this behavior.
Anyway, the point is that you should
lem is, but the missing libtool.m4
problem seems to be quite popular already before the release).
Another way to ensure matching versions would be to turn
ltmain.sh into an m4 macro. (I wouldn't have dared suggesting
that if someone didn't already. I think it was Gary. Please
mov
eeking up-to-date information, I'd like to point out that the
keywords to grep the documentations for are "convenience library".
The Automake manual has a full section entitled `Libtool
Convenience Libraries', and the Libtool manual mentions
convenience
would make sense to document it because it might be
useful to other tools, and this will likely reduce the odds of
breakages, e.g., when renaming internal symbols.)
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gn
>>> "Scott" == Scott James Remnant <[EMAIL PROTECTED]> writes:
Scott> On Tue, 2004-04-13 at 22:39, Alexandre Duret-Lutz wrote:
>> Is it done or is there any obstacle to it? I'm dreaming about
>> Automake 1.9, and if possible I would like to in
>>> "Scott" == Scott James Remnant <[EMAIL PROTECTED]> writes:
Scott> On Wed, 2004-04-14 at 08:00, Alexandre Duret-Lutz wrote:
>> >>> "Scott" == Scott James Remnant <[EMAIL PROTECTED]> writes:
>>
Scott> On Tue, 2004-04-13
>>> "Scott" == Scott James Remnant <[EMAIL PROTECTED]> writes:
Scott> On Wed, 2004-04-14 at 18:45, Alexandre Duret-Lutz wrote:
>> Ah, thanks! Sorry for being dense, but since it takes
>> tag names as argument, why is it called _LT_LANG?
>&g
to install all the m4 files in the
top-level directory, although nothing will read them here.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
Hi people,
This is a release candidate for Automake 1.9.
If you have some time, please help us tracking down bugs by trying
this beta with your packages and reporting any issue you encounter.
Especially, please shout loud if your package works with 1.8.5 but
does not with 1.8d.
I plan to release
On Tue, Jul 27, 2004 at 05:15:17PM +0100, Patrick Welche wrote:
> Reminder of the miscreant line:
>
> output_verbose_link_cmd="`$echo \"X$output_verbose_link_cmd\" | $Xsed -e
> \"$no_glob_subst\"`"
>
Why not replacing it with
output_verbose_link_cmd=`$echo "X$output_verbose_link_cmd" | $Xsed
We're pleased to announce the release of Automake 1.9.
This release contains many bug fixes and improvements, but not as much
as in previous major releases. The NEWS entry is appended. Thanks to
all people who have been testing pre-release, reporting bugs,
contributing code, suggesting enhanceme
inutes on my high end Mac, and up
Gary> to an hour for some of our other developers :-(
Does it? Running ./bootstrap takes 8 minutes on my poor PC.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
We're pleased to announce the release of Automake 1.9.1.
This is a tiny bug-fix release motivated by (1) the Debian GNU/Linux
freeze, and (2) a three-week vacation starting in a couple of days :)
The list of bug fixes is appended; we have not yet heard about
regressions introduced by 1.9.
You can
on, Inc.
+# Copyright (C) 2003, 2004 Free Software Foundation, Inc.
#
# This file is part of GNU Automake.
#
@@ -33,8 +33,9 @@
END
cat > Makefile.am << 'END'
+AUTOMAKE_OPTIONS = subdir-objects
lib_LTLIBRARIES = libmod1.la mod2.la
-libmod1_la_SOURCES = mod1.c
+libmod1_la_SOURCES = sub/mod1.c
libmod1_la_LDFLAGS = -module
libmod1_la_LIBADD = -dlopen mod2.la
mod2_la_SOURCES = mod2.c
@@ -50,9 +51,9 @@
END
-mkdir liba
+mkdir sub liba
-cat > mod1.c << 'END'
+cat > sub/mod1.c << 'END'
int
mod1 ()
{
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
o files.
[...]
Gary> Meant to ask, why doesn't AM_INIT_AUTOMAKE (conditionally if
Gary> necessary) simply invoke AM_PROG_CC_C_O?
We know it's needed only after processing the Makefile.am files.
--
Alexandre Duret-Lutz
___
Libtool mai
We're pleased to announce the release of Automake 1.9.2.
This is a small bug-fix release (the list of bugs fixed is
appended), and this is also an anniversary release.
Automake was started on 1994-09-19 so it has 10 years today.
To celebrate this the manual has been augmented with a
"History"
but I haven't flushed all my mails yet.
I agree it would be better to set down a common lock scheme,
although that really should not hold any release.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
AC_PROG_RANLIB, etc.
I once thought that since Automake knew what extra macros where
required, it could generate a configure.ac fragment with these.
But that sounds too fragile and tricky.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
We're pleased to announce the release of Automake 1.9.3.
This is a bug-fix release, the list of bugs fixed is appended.
You can find the new release here:
ftp://ftp.gnu.org/gnu/automake/automake-1.9.3.tar.gz
ftp://ftp.gnu.org/gnu/automake/automake-1.9.3.tar.gz.sig
ftp://ftp.gnu.org/g
ng) are intermixed into aclocal.m4.
(Seems another good reason to prefer setups with m4_include).
(*) Amusingly, Automake's own aclocal.m4 is probably the only
aclocal.m4 where there is no such confusion.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
order)
2. relink everything (in random order)
Would this work? (I think I already asked and the answer was
no, but I cannot find that answer in the archive.)
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org
the file were m4_included (we don't do that for Automake
macros anyway, but is that a reason to disallow it?)
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes:
Bob> On Wed, 10 Nov 2004, Alexandre Duret-Lutz wrote:
[...]
>> 1. install all programs and libraries without relinking (in random order)
>> 2. relink everything (in random order)
[...]
Bob>
erms that
you use for the rest of the package.
"configuration script generated by Autoconf" is what the aux
scripts already use.
"or any derived output" is a lame attempt to allow tools such as
aclocal (without singling out aclocal)
>>> "Noah" == Noah Misch <[EMAIL PROTECTED]> writes:
Noah> On Wed, Nov 10, 2004 at 01:17:19AM +0100, Alexandre Duret-Lutz wrote:
>> - the relinking dependency debacle:
>>
>> For libtool to relink libraries when installing them, all
>> depe
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
Gary> Alexandre Duret-Lutz wrote:
[...]
>> I don't understand the intent of "as input to GNU Autoconf, GNU
>> Automake, or GNU Libtool". AFAICT Libtool does not input m4
>>
; script (and perhaps some associated intermediate files),
Paul> then you may distribute this file and the derived files
Paul> for that purpose, under the same terms that you use for
Paul> the rest of the package.
[...]
President Eggert, you have my vote!
--
Alexandre Duret-Lutz
_
IG_MACRO_DIR to way you thought. It certainly isn't the
Automake manual.
See also
http://lists.gnu.org/archive/html/libtool-patches/2004-11/msg00097.html
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
mply call the installed `libtool' as shown
in the manual. You do not need libtoolize in such a setup.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
$(AM_LIBTOOLFLAGS)' replaced by `libfoo_la_LIBTOOLFLAGS' if it exists.
I'm working on this right now.
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/libtool
On Tue, Jan 04, 2005 at 02:10:14PM +0100, Ralf Wildenhues wrote:
>
> As your build also shows (I've deleted that because I could've guessed
> it), the automatic rebuilding rules call `automake' again, which is
> likely much newer than the shipped ltmain.sh. Automake creates the
> rules that contai
I'm pleased to announce the release of Automake 1.9.5.
This is a bug-fix release, the list of bugs fixed is appended.
You can find the new release here:
ftp://ftp.gnu.org/gnu/automake/automake-1.9.5.tar.gz
ftp://ftp.gnu.org/gnu/automake/automake-1.9.5.tar.gz.sig
ftp://ftp.gnu.org/gnu
83 matches
Mail list logo
