Re: building same source with different flag
Ted Irons <[EMAIL PROTECTED]> writes:
[...]
| Am using autoconf-2.5.2, automake-1.5b, libtool-1.4b
| on an ix86 box run running Suse Linux with kernel-2.4.6.
[...]
| libohrnet_la_SOURCES = ascbin.cc
| libohrnet_la_CXXFLAGS = -DHIGHER_ORDER_NET ${HBP_CXXFLAGS}
| libohrnet_la_LDFLAGS = -version-info @PIPES_VERSION@
[...]
| source='ascbin.cc' object='libhrnet_la-ascbin.lo' libtool=yes \
| depfile='.deps/libhrnet_la-ascbin.Plo' tmpdepfile='.deps/libhrnet_la-ascbin.TPlo' \
| depmode=gcc /bin/sh ../../../pipes-1.0/config/depcomp \
| /bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H
| -I. -I../../../pipes-1.0/tma/hbp.lib -I../.. -fpermissive
|-I../../../pipes-1.0/tma/util.lib -I../../../pipes-1.0/tma/trff.lib -g -O2 -c -o
|libhrnet_la-ascbin.lo `test -f ascbin.cc || echo
|'../../../pipes-1.0/tma/hbp.lib/'`ascbin.cc
| g++ -DHAVE_CONFIG_H -I. -I../../../pipes-1.0/tma/hbp.lib -I../.. -fpermissive
|-I../../../pipes-1.0/tma/util.lib -I../../../pipes-1.0/tma/trff.lib -g -O2 -c
|../../../pipes-1.0/tma/hbp.lib/ascbin.cc -Wp,-MD,.deps/libhrnet_la-ascbin.TPlo -fPIC
|-DPIC
| mv -f libhrnet_la-ascbin.o .libs/libhrnet_la-ascbin.o
| mv: cannot stat `libhrnet_la-ascbin.o': No such file or directory
| make[3]: *** [libhrnet_la-ascbin.lo] Error 1
[...]
I can reproduce your problem by manually setting compiler_c_o and
compiler_o_lo to "no" in the libtool script generated for a
pet-project. So ...
1) Libtool has decided at configure-time that you compiler
cannot run with both `-c' and `-o'. No idea why. It seems
bogus to me if you are using GCC. You should probably dig
config.log for clues.
2) Therefore `libtool' strips `-o libhrnet_la-ascbin.lo' from the compilation
command and assumes that the compiler will build an object file
called after the source file. That source file is assumed
to be the last argument of the compilation command.
3) However `libtool' is not called directly. Actually, `make' calls `depcomp'
which in turn calls `libtool'. Since you have `gcc', `depcomp' is in
`gcc' mode and has appended `-Wp,-MD,.deps/libhrnet_la-ascbin.TPlo' to the
the compilation command in order to track dependencies.
4) This last argument is taken by `libtool' to be the source file :).
It just strips the dirname (`-Wp,-Md,.deps/' !) and the extension (`.Tplo'),
append `.o', and you get `libhrnet_la-ascbin.o', the object `libtool'
thinks `gcc' will create.
(It's funny to see that this behavior leads to a correct
result if you do not use per-target CXXFLAGS; because the
dependency option is then `-Wp,-MD,.deps/ascbin.TPlo' which
`libtool' maps to `ascbin.o'.)
5) Finally the compilation command is run, ascbin.o is created,
and libtool fail to move the resulting object because it looks for
`libhrnet_la-ascbin.o' instead.
As an immediate work-around, you can prevent `depcomp' to add this
"fatal" last argument by configuring your package with
--disable-dependency-tracking. However it would be better to find out
why `gcc -c -o' doesn't work on your host.
I can see two ways to 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
Re: building same source with different flag
>>> "Ted" == Ted Irons <[EMAIL PROTECTED]> writes:
[...]
Ted> if test "${lt_cv_prog_compiler_c_o_CXX+set}" = set; then
Ted> echo $ECHO_N "(cached) $ECHO_C" >&6
Ted> else
Ted> lt_cv_prog_compiler_c_o_CXX=no
[...]
Ted> save_CFLAGS="$CFLAGS"
Ted> CFLAGS="$CFLAGS -o out/conftest2.$ac_objext"
[...]
Ted> If I change the CFLAGS to CXXFLAGS in configure the
Ted> configure output gives "g++ supports -c -o file.o
Ted> ... yes"; otherwise the answer given is no. Incidentally,
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 seems this was fixed a few days after libtool 1.4b was
announced. Can you try CVS libtool?
[...]
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: libtool CVS permanently broken?
>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: [...] Bob> % ./bootstrap Bob> autoheader: config-h.in is unchanged Bob> Can't call method "close" on an undefined value at /usr/local/bin/automake line 7751. See these messages 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
Re: [bug-gnulib] Re: libtool 2.1a failed mdemo-make.test on Solaris
>>> "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 $(BUILT_SOURCES)? -- Alexandre Duret-Lutz ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool -release and static libraries.
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 are done at configure time, Automake is run earlier and will never know their values. > However in the automake files I am unable to use these variables for > substitution on the left side of the = sign. I.e: > > [EMAIL PROTECTED]@.la > > [EMAIL PROTECTED]@_la_CPPFLAGS=-I$(top_builddir)/src > ... > > > Fails to work. Take the string "[EMAIL PROTECTED]@.la" (that's what Automake reads). To canonize it, replace characters that are neither alphanumeric nor strudels by underscores. That gives "[EMAIL PROTECTED]@_la". So your second variable should be "[EMAIL PROTECTED]@_la_CPPFLAGS". ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Libtool -release and static libraries.
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 regarded as a caricature of any religon whatsoever :) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: overriding libdir?
Olly Betts: | On 2006-04-12, Tyler MacDonald <[EMAIL PROTECTED]> wrote: | > I'm trying to ion-diret automake/libtool to allow me to | > install a library into PHP's extension directory. | | phpextdir = `$(PHP_CONFIG) --extension-dir` | phpext_LTLIBRARIES = php_mod_bt.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 ___ http://lists.gnu.org/mailman/listinfo/libtool
GNU Automake 1.10 released
uot; AM_LDFLAGS rather than
"in addition to" breaks backward compatibility with older versions.
If your package used both variables, as in
AM_LDFLAGS = common flags
bin_PROGRAMS = a b c
a_LDFLAGS = more flags
...
and assumed *_LDFLAGS would sum up, you should rewrite it as
AM_LDFLAGS = common flags
bin_PROGRAMS = a b c
a_LDFLAGS = $(AM_LDFLAGS) more flags
...
This new behavior of *_LDFLAGS is more coherent with other
per-target variables, and the way *_LDFLAGS variables were
considered internally.
* New installation targets:
- New targets mandated by GNU Coding Standards:
install-dvi
install-html
install-ps
install-pdf
By default they will only install Texinfo manuals.
You can customize them with *-local variants:
install-dvi-local
install-html-local
install-ps-local
install-pdf-local
- The undocumented recursive target `uninstall-info' no longer exists.
(`uninstall' is in charge of removing all possible documentation
flavors, including optional formats such as dvi, ps, or info even
when `no-installinfo' is used.)
* Miscellaneous changes:
- Automake no longer complains if input files for AC_CONFIG_FILES
are specified using shell variables.
- clean, distribution, or rebuild rules are normally disabled for
inputs and outputs of AC_CONFIG_FILES, AC_CONFIG_HEADERS, and
AC_CONFIG_LINK specified using shell variables. However, if these
variables are used as ${VAR}, and AC_SUBSTed, then Automake will
be able to output rules anyway.
(See the Automake documentation for AC_CONFIG_FILES.)
- $(EXEEXT) is automatically appended to filenames of TESTS
that have been declared as programs in the same Makefile.
This is mostly useful when some check_PROGRAMS are listed in TESTS.
- `-Wportability' has finally been turned on by default for `gnu' and
`gnits' strictness. This means, automake will complain about %-rules
or $(GNU Make functions) unless you switch to `foreign' strictness or
use `-Wno-portability'.
- Automake now uses AC_PROG_MKDIR_P (new in Autoconf 2.60), and uses
$(MKDIR_P) instead of $(mkdir_p) to create directories. The
$(mkdir_p) variable is still defined (to the same value as
$(MKDIR_P)) but should be considered obsolete. If you are using
$(mkdir_p) in some of your rules, please plan to update them to
$(MKDIR_P) at some point.
- AM_C_PROTOTYPES and ansi2knr are now documented as being obsolete.
They still work in this release, but may be withdrawn in a future one.
- Inline compilation rules for gcc3-style dependency tracking are
more readable.
- Automake installs 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
Re: PATCH: pointless code removal
>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: Bruce> As far as I can tell, the removed code serves no purpose Bruce> (other than obfuscation ;-): [... removal of -Xcompiler support ...] Bruce> P.S., my head hurts Bruce> Also, anyone care to comment about the handling of "srcfile"? Bruce> Viz., what is really being accomplished that could not be Bruce> accomplished by: Bruce> eval srcfile=\"\$$#\" This wouldn't work with libtool --compile gcc -c foo.c -Xcompiler -M Automake's depcomp sometimes 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
Re: PATCH: pointless code removal
>>> "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 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Bug in libltdl?
>>> "Stephano" == Stephano Mariani <[EMAIL PROTECTED]> writes: Stephano> libltdl (current from CVS) seems not to return NULL Stephano> when lt_dlopen is passed the name of a non-existent Stephano> file. I got the same error and sent this patch: http://mail.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 ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: distcheck with libtool
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
Re: Bug in conditional library building
>>> "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 CVS. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.6d available (beta for Automake 1.7)
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 form at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake Please SHOUT LOUD if your package works with Automake 1.6.3 but doesn't with 1.6d. You can find this snapshot here: ftp://sources.redhat.com/pub/automake/automake-1.6d.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.6d.tar.bz2 Here are the news since 1.6. (The `|' on the left indicates a change since the last snapshot, 1.6b.) New in 1.6d: |* Autoconf 2.54 is required. * `aclocal' and `automake' will no longer warn about obsolete configure macros. This is done by `autoconf -Wobsolete'. * AM_CONFIG_HEADER, AM_SYS_POSIX_TERMIOS and AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL are obsolete (although still supported). You should use AC_CONFIG_HEADERS, AC_SYS_POSIX_TERMIOS, and AC_HEADER_TIOCGWINSZ instead. `autoupdate' can upgrade `configure.ac' for you. * Support for per-program and per-library `_CPPFLAGS'. * New `ctags' target (builds CTAGS files). * Support for -Wmumble and -Wno-mumble, where mumble is a warning category (see `automake --help' or the manual for a list of them). * Honor the WARNINGS environment variable. * Omit the call to depcomp when using gcc3: call the compiler directly. * A new option, std-options, tests that programs support --help and --version when `make installcheck' is run. This is enabled by --gnits. * Texinfo rules now support the `ps' and `pdf' targets. |* Info files are now created in the build directory, not the source directory. |* info_TEXINFOS supports files in subdirectories (this requires Texinfo 4.1 | or greater). * `make distcheck' will enforce DESTDIR support by attempting a DESTDIR install. * `+=' can be used in conditionals, even if the augmented variable was defined for another condition. |* Makefile fragments (inserted with `include') are always 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 --output-dir is deprecated. * Many bug fixes. - Akim, Alexandre, and Tom ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: autoreconf misses ltmain.sh
>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: Ralf> This bug has been present with previous versions of automake and Ralf> autoconf (IIRC, it also has been reported several times before). I think this is the same issue as http://mail.gnu.org/pipermail/libtool/2002-August/006640.html -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.6f available (beta for Automake 1.7)
Thanks to all people who have send patches and bug reports here is another beta for Automake 1.7. Again, please SHOUT LOUD if your package works with Automake 1.6.3 but doesn't with 1.6f. Incompatibilities are best fixed before the release. Please report any issue by mail to <[EMAIL PROTECTED]>, or (preferred) at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake You can find this snapshot here: ftp://sources.redhat.com/pub/automake/automake-1.6f.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.6f.tar.bz2 Here are the news since 1.6. (There have been only bug fixes since 1.6d.) New in 1.6f: * Autoconf 2.54 is required. * `aclocal' and `automake' will no longer warn about obsolete configure macros. This is done by `autoconf -Wobsolete'. * AM_CONFIG_HEADER, AM_SYS_POSIX_TERMIOS and AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL are obsolete (although still supported). You should use AC_CONFIG_HEADERS, AC_SYS_POSIX_TERMIOS, and AC_HEADER_TIOCGWINSZ instead. `autoupdate' can upgrade `configure.ac' for you. * Support for per-program and per-library `_CPPFLAGS'. * New `ctags' target (builds CTAGS files). * Support for -Wmumble and -Wno-mumble, where mumble is a warning category (see `automake --help' or the manual for a list of them). * Honor the WARNINGS environment variable. * Omit the call to depcomp when using gcc3: call the compiler directly. * A new option, std-options, tests that programs support --help and --version when `make installcheck' is run. This is enabled by --gnits. * Texinfo rules now support the `ps' and `pdf' targets. * Info files are now created in the build directory, not the source directory. * info_TEXINFOS supports files in subdirectories (this requires Texinfo 4.1 or greater). * `make distcheck' will enforce DESTDIR support by attempting a DESTDIR install. * `+=' can be used in conditionals, even if the augmented variable was defined for another condition. * Makefile fragments (inserted with `include') are always 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 --output-dir is deprecated. * Many bug fixes. - Akim, Alexandre, and Tom -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: libfoo.la is already going to be installed in lib.
>>> "Harlan" == Harlan Stenn <[EMAIL PROTECTED]> writes: Harlan> This appears to be aproblem with libtool+automake; if I Harlan> use a static library (no libtool) I don't see this Harlan> problem. Unless I'm mistaken, you already submitted this 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. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: autoreconf misses ltmain.sh
>>> "Ralf" == Ralf Corsepius <[EMAIL PROTECTED]> writes: [...] Ralf> http://mail.gnu.org/pipermail/libtool-patches/2002-January/001659.html Ralf> .. which seems to indicate that libtool is the culprit. Ralf> => There doesn't exist any officially 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's fixed in CVS Libtool. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.7 released
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.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.7.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.7.tar.bz2 (Note that the files might not be already available at ftp.gnu.org by the time you read this.) Soon it will also appear on the sources and GNU mirrors. Follow these links for a list of them: http://sources.redhat.com/mirrors.html http://www.gnu.org/order/ftp.html Please report bugs by mail to <[EMAIL PROTECTED]>, or (preferred) at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake - Akim, Alexandre, and Tom New in 1.7: * Autoconf 2.54 is required. * `aclocal' and `automake' will no longer warn about obsolete configure macros. This is done by `autoconf -Wobsolete'. * AM_CONFIG_HEADER, AM_SYS_POSIX_TERMIOS and AM_HEADER_TIOCGWINSZ_NEEDS_SYS_IOCTL are obsolete (although still supported). You should use AC_CONFIG_HEADERS, AC_SYS_POSIX_TERMIOS, and AC_HEADER_TIOCGWINSZ instead. `autoupdate' can upgrade `configure.ac' for you. * Support for per-program and per-library `_CPPFLAGS'. * New `ctags' target (builds CTAGS files). * Support for -Wmumble and -Wno-mumble, where mumble is a warning category (see `automake --help' or the manual for a list of them). * Honor the WARNINGS environment variable. * Omit the call to depcomp when using gcc3: call the compiler directly. * A new option, std-options, tests that programs support --help and --version when `make installcheck' is run. This is enabled by --gnits. * Texinfo rules now support the `ps' and `pdf' targets. * Info files are now created in the build directory, not the source directory. * info_TEXINFOS supports files in subdirectories (this requires Texinfo 4.1 or greater). * `make distcheck' will enforce DESTDIR support by attempting a DESTDIR install. * `+=' can be used in conditionals, even if the augmented variable was defined for another condition. * Makefile fragments (inserted with `include') are always 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 --output-dir is deprecated. * The part of the distcheck target that checks whether uninstall actually removes all installed files has been moved in a separate target, distuninstallcheck, so it can be overridden easily. * Many bug fixes. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.7.1 released
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 it will also appear at ftp://ftp.gnu.org/gnu/automake/automake-1.7.1.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.7.1.tar.bz2 as well as on sources and GNU mirrors: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Please report bugs to <[EMAIL PROTECTED]>. - Akim, Alexandre, and Tom Bugs fixed in 1.7.1: * Honor `ansi2knr' for files built in subdirectories, or using per-targets flags. * Aclocal should now recognize macro names containing parentheses, e.g. AC_DEFUN([AC_LANG_PREPROC(Fortran 90)], [...]). * Erase *.sum and *.log files created by DejaGnu, during `make distclean'. (Debian Bug#153697) * Install Python files even if they were built. (PR/369) * Have stamp-vti dependent upon configure instead of configure.ac, as the version might not be defined in the latter. (PR/358) * Reorder arguments passed to a couple of commands, so things works when POSIXLY_CORRECT=1. * Fix a regex that can cause Perl to segfault on large input. (Debian Bug#162583) * Fix distribution of packages that have some sources defined conditionally, as in the `Conditional compilation using Automake conditionals' example of the manual. * Fix spurious test suite failures on IRIX. * Don't report a required variable as undefined if it has been defined conditionally for the "right" conditions. * Fix cleaning of the /tmp subdirectory used by `make distcheck', in case `make distcheck' fails. * Fix distribution of included Makefile fragment, so we don't create spurious directories in the distribution. (PR/366) * Don't complain that a target lacks `.$(EXEEXT)' when it has it. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: [shell functions, was RE: solving of name conflicts in included.a]
>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: [...] Bruce> neither Autoconf nor Libtool want to be the first to say Bruce> that 20 year old shells are too old for continued Bruce> support. Ick. How completely disgusting. Cheer up and read the Autoconf 2.54c announcement entirely :) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: getting a locally built library
>>> "Bruce" == Bruce Korb <[EMAIL PROTECTED]> writes: Bruce> David Bacher wrote: [...] >> /bin/sh ../libtool --mode=link gcc -g -O2 -L/sw/lib -o autogen \ >> -export-dynamic -lguile *.o -L/sw/lib -lguile -lm \ >> -L../autoopts/.libs -lopts -ldl >> ld: Undefined symbols: >> _aopts_alloc >> _aopts_realloc >> _aopts_strdup >> make[1]: *** [autogen] Error 1 Where does this command comes from? This doesn't look like an Automake-generated call to libtool. First, Automake should not generate something 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 in the output). [...] -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: getting a locally built library
>>> "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 \ >> >> -L../autoopts/.libs -lopts -ldl >> >> ld: Undefined symbols: >> >> _aopts_alloc >> >> _aopts_realloc >> >> _aopts_strdup >> >> make[1]: *** [autogen] Error 1 [...] >> it should not output >> `-L../autoopts/.libs -lopts' but `../autoopts/libopts.la' >> since Bruce said `autogen_LDADD = $(top_builddir)/autoopts/libopts.la'. [...] Bruce> That part I did not change from David's email. David, could you explain where `-L../autoopts/.libs -lopts' comes from? [...] -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.7.2 released
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/pub/automake/automake-1.7.2.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7.2.tar.gz Soon it will also appear on the sources and GNU mirrors listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Here are the MD5 checksums: 8cfa661dca69271b862bee4f841fcd80 automake-1.7.2.tar.bz2 753647afe9db0ec52c69c6b9bb7dd106 automake-1.7.2.tar.gz Please report bugs to <[EMAIL PROTECTED]>. - Akim, Alexandre, and Tom Bugs fixed in 1.7.2: * Fix installation and uninstallation of Info files built in subdirectories. * Do not run `./configure --with-included-gettext' during `make distcheck' if AM_GNU_GETTEXT([external]) is used. * Correctly uninstall renamed man pages. * Do not strip escaped newline in variables defined in one condition and augmented in another condition. * Fix ansi2knr rules for LIBOBJS sources. * Clean all known Texinfo index files, not only those which appear to be used, because we cannot know wich indexes are used in included files. (PR/375, Debian Bug #168671) * Honor only the first @setfilename seen in a Texinfo file. * Treat "required file X not found" diagnostics as errors (exit status 1). * Don't complain that a required file is not found when it is a Makefile target. (PR/357) * Don't use single suffix inference rules when building `.info'-less Info files, for the sake of Solaris make. * The `check' target now depends on `$(BUILT_SOURCES)'. (PR/359) * Recognize multiple inference rules such as `.a.b .c.d:'. (PR/371) * Warn about multiple inference rules when -Wportability is used. (PR/372) * Fix building of deansified files from subdirectories. (PR/370) * Add missing `fi' in the .c->.obj rules. * Improve install-sh to work even when names contain spaces or certain (but not all) shell metachars. * Fix the following spurious failures in the test suite: depcomp2.test, gnits2.test, gnits3.test, python3.test, texinfo13.test * Noteworthy manual updates: - Augment the section about BUILT_SOURCES. - Mention that AM_PROG_CC_STDC is a relic that is beter avoided today. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake and `libtool --mode=clean'
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. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Pending release of 1.5
>>> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes: Robert> Hello, Robert> I'm just about to make the release of Libtool 1.5. If anyone would Robert> like to test the current CVS on their favorite platform and report Robert> any problems, please 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 Libtool off CVS. Cheerio, -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Pending release of 1.5
>>> "Robert" == Robert Boehne <[EMAIL PROTECTED]> writes:
Robert> Alexandre,
Robert> Snapshots of CVS are made daily and reside at
Robert> ftp://alpha.gnu.org/pub/gnu/cvs/libtool.tgz
CVS snapshots are differents from `make dist' tarballs. The
former still requires maintainer tools like Autoconf, Automake,
Texinfo... I don't think they are easier to test than a CVS
checkout. It is better to test a real candidate of what the
release will be, IMHO.
Besides, since generated files are not under CVS we don't know
what yours will look like. We should test the files that you
will distribute, not the files that we can build with our own
versions of the autotools.
Robert> I'm not sure where to announce a pending release other
Robert> than here, but I had just intended to re-release after
Robert> bugs were fixed & found in 1.5. If you have a suggestion
Robert> on where to announce the pre-release, let us know.
I sent you a private mail entitled `RFC: [EMAIL PROTECTED]' on
January 15. (Only Akim, Jim, Pavel, and Paul answered to this; I was
hopping comments from you and Bruno.) Since then I've asked for
the creation of this list, but haven't heard anything from the GNU
sysadmins yet (the ticket ID is [gnu.org #17673]).
Presently, Autoconf and Automake prereleases are announced to
{autoconf,automake,libtool,bug-gnu-utils}@gnu.org. Also for
Automake prereleases I have been spamming 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
ANN: new mailing list: autotools-announce@gnu.org
[Please repost and forward wherever it is appropriate.] We have setup a new mailing list, [EMAIL PROTECTED], that will carry announcements for releases *and* beta-releases of Autoconf, Automake, Gettext, and Libtool. This is intended to be a read-only and low-traffic list, for people that cannot 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-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Automake 1.7.2b uploaded (beta for 1.7.3)
anged to AC_CONFIG_AUX_DIR([.]). I suppose some people will mind about the extra kilobytes, though. [*] To be fair, I guess it's harmless if you don't rerun automake in the libltdl directory embeded in a package. However I think it's quite common to do so, for instance `autoreconf' will work recursively. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
>>> "Albert" == Albert Chin <[EMAIL PROTECTED]> writes: Albert> On Mon, Jun 02, 2003 at 05:06:42PM -0500, Bob Friesenhahn wrote: >> On Mon, 2 Jun 2003, Albert Chin wrote: >> >> > It's really annoying to have 1.5 automatically generate the C++ and >> > F77 tags. I'm trying to figure out why it does this. We have the >> > following in libtool.m4: >> > dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX >> > dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX. >> > AC_PROVIDE_IFELSE([AC_PROG_CXX], >> > [AC_LIBTOOL_CXX], >> > [define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX >> > ])]) [...] Albert> I'm trying to do it automatically. I want to run AC_LIBTOOL_CXX *only* Albert> if AC_PROG_CXX is called. Can autoconf do this? Automake setups its dependency tracking code for various languages with code similar to the above. Actually, the above would work if Libtool was not running expanding AC_PROG_CXX itself! (This happens when AC_LIBTOOL_LANG_CXX_CONFIG is expanded in _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 for other languages. However I don't think you can do this and still allow AC_PROC_CXX to be called after AC_PROG_LIBTOOL. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 1.5 automatically generating C++, F77 tags
>>> "Albert" == Albert Chin <[EMAIL PROTECTED]> writes: [...] Albert> I don't have a problem requiring AC_PROG_CXX, AC_PROG_F77, or Albert> AM_PROG_GCJ before AC_PROG_LIBTOOL. Anyone see this as a problem? As a user I wouldn't care about this little inconvenience if it allows Libtool not to bloat my configure with useless checks. However, requiring this will break thousands of configure.ac. I expect most of them to run AC_INIT, AM_INIT_AUTOMAKE, AC_PROG_LIBTOOL early, and then go on with other checks such as language checks. Maybe this could be changed as follows: - if any of AC_PROG_CC, AC_PROG_CXX, AC_PROG_F77, or AM_PROG_GCJ are called before AC_PROG_LIBTOOL, define the tags only for those which are called. (I think there is no tag for CC, but if only AC_PROG_CC is called that would just means that CXX, F77, and GCJ are not wanted.) - if none of these macros is called before AC_PROG_LIBTOOL, assume they might be called latter and define all tags, as in the current implementation. See this as backward compatibility. Also, this would allow one to configure Libtool to use some languages and ignore 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
Re: 1.5 automatically generating C++, F77 tags
Albert Chin <[EMAIL PROTECTED]> writes: [...] | --- libtool.m4.orig 2003-06-01 16:07:41.276467000 -0500 | +++ libtool.m42003-06-03 10:22:57.667598339 -0500 [...] | +AC_PROVIDE_IFELSE([AC_LIBTOOL_TAGS],, | + [AC_LIBTOOL_TAGS([C C++ F77])]) Since the tag for C++ is called CXX and there is no tag for C, it would seem more natural to read AC_LIBTOOL_TAGS([CXX F77]) I think Bob's suggestion of AC_LIBTOOL_LANGUAGES is better if you really want to pass language names as arguments. [...] | + [m4_if(_LT_TAG, C, , | + [m4_if(_LT_TAG, C++, [...] | + [m4_if(_LT_TAG, F77, [...] | + [m4_if(_LT_TAG, GCJ, [...] | + [m4_if(_LT_TAG, RC, [...] | + m4_errprintn(m4_location[: error: invalid tag name: ]"_LT_TAG") Maybe this can be simplified to something around the lines of m4_case([_LT_TAG], [C], , [CXX], [...], [F77], [...], [GCJ], [...], [RC], [...], [m4_fatal([unsupported tag name: ]"_LT_TAG")]) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: (With Patch) Re: DESTDIR trouble
>>> "R" == R I P Deaddog <[EMAIL PROTECTED]> writes: [...] R> For several _YEARS_, packagers for software were very troubled because R> of not-completely-working staging install. I really hope this issue can R> be sorted out, once and for all. One way to address 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
Re: 9-gary-reduce-dist-size.patch
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: failed to run automake: No such file or directory This seems to be an old version of Automake. The last Nestable use was removed on 2003-08-12. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: 9-gary-reduce-dist-size.patch
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 checked out cvs HEAD via anonymous cvs from savannah.gnu.org, but > looking at it the last ChangeLog entry was more than 6 months ago. > > I guess I did something wrong, care to enlighten me? :) Savannah used to be a mirror, I don't know why it stopped. CVS instructions are on the Automake home page at http://sources.redhat.com/automake/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Version numbering
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: [...] Gary> And that's why people find our version scheme confusing. I'm not sure Gary> how we ended up working in this way, I think we copied it from Gary> Automake? Tsk tsk tsk. Libtool used that scheme first. Automake copied it when we started to have branches. Gary> Anyhow, I'm fed up of having to explain it, when we could Gary> just make it intuitive :-) I didn't understand your proposal, but I hope you are not planning to make 2.2 < 2.3a < 2.3. That 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
Re: Version numbering
>>> "Daniel" == Daniel Reed <[EMAIL PROTECTED]> writes: [...] Daniel> Several GNU projects (including GCC) do leave off .0's Daniel> for anything past the minor number, so it seems ls -v Daniel> can't be the final authority :/ Sorry I meant to compare only the version numbers not the full filename. Comparing version number is what automatic installation tools has to do in order to know which version is newer than the other. Such tools can deal with 1.2 being older than 1.10, but they have trouble realizing that 1.3pre2 before 1.3 is know to break them, because 1.3pre2 is lexically after 1.3. Debian at least has a special workaround (the maintainer of a package add a extra digit in front of the version number) to cope with such unsortable numbering scheme. Hence the suggestion of supporting at least `ls -v'. % ls -v1 1.5 1.5.0a 1.5.0b 1.5.1 1.5a 1.5b 1.6 1.10 Obviously, as long as characters are reserved for beta releases, we may not care about such installation tools. After all the real releases are easy to sort since they use only digit. As far as explaining the new scheme is concerned, I claim that it's easier to do if it works with `ls -v'. In the past, people have also argued that using characters was making it more difficult for tools to sort the versions. If you agree you might as well switch to the blessed FSF way of making beta releases (using .90, .91, .92, etc.). Texinfo and Coreutils switched to it recently. I don't really like it because I think it's horrible with branches and is less obvious than characters (I really like these extra characters). A scheme which I think would be compatible with Gary's will (maybe this is what he proposed, I simply did not understand whether he wanted to jump from 1.7d down to 1.7 or up to 1.8). 1.6 (release) 1.7a (CVS), 1.7b (beta), 1.7c (CVS), 1.7d (beta), 1.8 (release) on the branch: 1.8.1a (CVS) 1.8.1b (beta) 1.8.2 (release) etc. Keeping odd version for development ensure people cannot 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
Re: bootstrapping CVS libtool
>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: [...] Bob> I retrieved a package called automake-1.7d from Bob> alpha.gnu.org but it is not clear what it really is (the Bob> NEWS file is extended over the one from 1.7.9). You might want to join [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/autotools-announce [...] -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: configuring libltdl
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 an Automake-generated Makefile.in without AM_INIT_AUTOMAKE. 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. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: configuring libltdl
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, we > should try and build on gettext's work I think. Maybe we can > collaborate with Bruno to generalize the rewriting and get it into > the next automake? I'm afraid I have no idea what you talk about. By "rewriting Makefile.in as in Gettext" I was referring to the hand-written intl/Makefile.in that Bruno has to maintain because this directory is also used in non-automake projects. I don't know what you want to generalize here. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: configuring libltdl
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, we have such a macro: it's called AM_INIT_AUTOMAKE. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: configuring libltdl
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 sensible to me. 1) You need to have libltdl/Makefile.in regenerated with the automake version that matches the aclocal version used to rebuild aclocal.m4 2) automake should only rebuild the Makefile.in which have a matching Makefile.am. So this is a no-op for the rest of the project. Unfortunately I think it won't work, because autoreconf probes for a Makefile.am in the top-level directory to decide whether automake must be run. (BTW, assuming the file is named Makefile.am is not always correct.) It should be easy to fix autoreconf, though. What is likely to fail with such a scheme are the automatic rebuild rules for libltdl/Makefile.in. They assume the top-level Makefile contains some special rules to rebuilds things. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.7f uploaded (third beta for Automake 1.8)
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 NEWS since 1.7.9 below. You can find this beta here: ftp://alpha.gnu.org/gnu/automake/automake-1.7e.tar.gz ftp://alpha.gnu.org/gnu/automake/automake-1.7e.tar.gz.sig ftp://alpha.gnu.org/gnu/automake/automake-1.7e.tar.bz2 ftp://alpha.gnu.org/gnu/automake/automake-1.7e.tar.bz2.sig or here: ftp://sources.redhat.com/pub/automake/automake-1.7e.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7e.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.7e.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7e.tar.bz2.sig Here are the MD5 checksums: 1c10b661adfc549be6fd868045727335 automake-1.7f.tar.bz2 88c4296fea4f4b543fc3c2970838f5d6 automake-1.7f.tar.gz Please report bugs to <[EMAIL PROTECTED]>. Changes between 1.7d and 1.7f: - More documentation about overriding automake targets (in manual and NEWS). - Work around a Texinfo 4.1 bug in html rules. - Make sure variables whose definitions have been wrapped by Automake on multiple lines such as in foo = ... \ @subst@ will not confuse HP-UX Make if @subst@ is replaced by an empty string. - Account for Makefile inputs being possibly AC_CONFIG_FILES output. - Do not append $(EXEEXT) do @substitutions@ when rewritting _PROGRAMS variables. - Never disable rebuild rules for Makefile, even with AM_MAINTAINER_MODE. New in 1.7f (since 1.7.9): * Meta-News - The NEWS file is more verbose. * Requirements - Autoconf 2.58 or greater is required. * New features - AR's `cru' flags are now set in a global ARFLAGS variable instead of being hard-coded in each $(AR) invocation, so they can be substituted from configure.ac. This has been requested by people dealing with non-POSIX ar implementations. - New warning option: -Woverride. This will warn about any user target or variable definitions which override Automake definitions. - Texinfo rules back up and restore info files when makeinfo fails. - Texinfo rules now support the `html' target. Running this requires Texinfo 4.0 or greater. `html' is a new recursive target, so if your package mixes hand-crafted `Makefile.in's with Automake-generated `Makefile.in's, you should adjust the former to support (or ignore) this target so that `make html' recurses successfully. If you had a custom `html' rule in your `Makefile.am', it's better to rename it as `html-local', otherwise your rule will override Automake's new rule (you can check that by running `automake -Woverride') and that will stop the recursion to subdirectories. Last but not least, this `html' rule is declared PHONY, even when overridden. Fortunately, it appears that few packages use a non-PHONY `html' rule. - Any file which is m4_included from configure.ac will appear as a configure and Makefile.in dependency, and will be automatically distributed. - The rules for rebuilding Makefiles and Makefile.ins will now rebuild all Makefiles and all Makefile.ins at once when one of configure's dependencies has changed. This is considerably faster than previous implementations, where config.status and automake were run separately in each directory (this still happens when you change a Makefile.am locally, without touching configure.ac or friends). Doing this also solves a longstanding issue: these rebuild rules failed to work when adding new directories to the tree, forcing you to run automake manually. - For similar reasons, the rules to rebuild configure, config.status, and aclocal.m4 are now defined in all directories. Note that if you were using the CONFIG_STATUS_DEPENDENCIES and CONFIGURE_DEPENDENCIES (undocumented) variables, you should better define them in all directories. This is easily done using an AC_SUBST (make sure you prefix these dependencies with $(abs_top_srcdir) since this variable will appear at different levels of the build tree). - aclocal will now use `m4_include' instead of copying local m4 files into aclocal.m4. (Local m4 files are those you ship with your project, other files will be copied as usual.) Because m4_included files are automatically distributed, it means for most projects there is no point in EXTRA_DISTing the list of m4 files which are used. (You can probably get rid of m4/Makefile.am if you had one.) - aclocal will avoid touching aclocal.m4 when possible, so that Autom4te's cache isn't needlessly invalidated. This behavior can be switched off with the new `--force' option. - aclocal now uses Autoconf's --trace to detect macros which are
Re: Automake 1.7f uploaded (third beta for Automake 1.8)
>>> "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/automake/automake-1.7f.tar.gz ftp://alpha.gnu.org/gnu/automake/automake-1.7f.tar.gz.sig ftp://alpha.gnu.org/gnu/automake/automake-1.7ftar.bz2 ftp://alpha.gnu.org/gnu/automake/automake-1.7f.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.7f.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7f.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.7f.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7f.tar.bz2.sig /ME makes mental note not to write announcements with one hand under the pillow. Sorry for the confusion. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Automake 1.7h uploaded (fourth beta for Automake 1.8)
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.gnu.org/gnu/automake/automake-1.7h.tar.gz ftp://alpha.gnu.org/gnu/automake/automake-1.7h.tar.gz.sig ftp://alpha.gnu.org/gnu/automake/automake-1.7h.tar.bz2 ftp://alpha.gnu.org/gnu/automake/automake-1.7h.tar.bz2.sig or here: ftp://sources.redhat.com/pub/automake/automake-1.7h.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.7h.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.7h.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.7h.tar.bz2.sig Here are the MD5 checksums: 2ed0df2dc0ba74d0cc55fc8689f1ec22 automake-1.7h.tar.bz2 a8b9311d183345d8c2336a135d270c63 automake-1.7h.tar.gz Please report bugs to <[EMAIL PROTECTED]>. Changes between 1.7f and 1.7h: * New computation of default filenames (see the first "New feature" in the full NEWS below). * Ignore trailing comments in variable definitions (automake was confused by `bin_PROGRAMS = foo#bar'). * New machinery that allows Automake to expand variables which are part of filenames (as in `CLEANFILES = $(PROJ).info') when it processes a list of filenames. This is currently disabled everywhere except in CLEANFILES, because it improves backward compatibility in an undocumented hack to support non-distributed info files. However it is nice to have this feature handy, and we might turn on this expansion in more places later. New in 1.7h, since 1.7.9: * Meta-News - The NEWS file is more verbose. * Requirements - Autoconf 2.58 or greater is required. * New features - Default source file names in the absence of a _SOURCES declaration are made by removing any target extension before appending `.c', so to make the libtool module `foo.la' from `foo.c', you only need to do this: lib_LTLIBRARIES = foo.la foo_la_LDFLAGS = -module For backward compatibility, foo_la.c will be used instead of foo.c if this file exists or is the explicit target of a rule. However -Wobsolete will warn about this deprecated naming. - AR's `cru' flags are now set in a global ARFLAGS variable instead of being hard-coded in each $(AR) invocation, so they can be substituted from configure.ac. This has been requested by people dealing with non-POSIX ar implementations. - New warning option: -Woverride. This will warn about any user target or variable definitions which override Automake definitions. - Texinfo rules back up and restore info files when makeinfo fails. - Texinfo rules now support the `html' target. Running this requires Texinfo 4.0 or greater. `html' is a new recursive target, so if your package mixes hand-crafted `Makefile.in's with Automake-generated `Makefile.in's, you should adjust the former to support (or ignore) this target so that `make html' recurses successfully. If you had a custom `html' rule in your `Makefile.am', it's better to rename it as `html-local', otherwise your rule will override Automake's new rule (you can check that by running `automake -Woverride') and that will stop the recursion to subdirectories. Last but not least, this `html' rule is declared PHONY, even when overridden. Fortunately, it appears that few packages use a non-PHONY `html' rule. - Any file which is m4_included from configure.ac will appear as a configure and Makefile.in dependency, and will be automatically distributed. - The rules for rebuilding Makefiles and Makefile.ins will now rebuild all Makefiles and all Makefile.ins at once when one of configure's dependencies has changed. This is considerably faster than previous implementations, where config.status and automake were run separately in each directory (this still happens when you change a Makefile.am locally, without touching configure.ac or friends). Doing this also solves a longstanding issue: these rebuild rules failed to work when adding new directories to the tree, forcing you to run automake manually. - For similar reasons, the rules to rebuild configure, config.status, and aclocal.m4 are now defined in all directories. Note that if you were using the CONFIG_STATUS_DEPENDENCIES and CONFIGURE_DEPENDENCIES (undocumented) variables, you should better define them in all directories. This is easily done using an AC_SUBST (make sure you prefix these dependencies with $(abs_top_srcdir) since this variable will appear at different levels of the build tree). - aclocal will now use `m4_include' instead of copying local m4 files into aclocal.m4. (Local m4 files are those you ship with your project, other files will be copied as usual.)
Re: libtool 1.5a download broken
>>> "Rich" == Richard Dawe <[EMAIL PROTECTED]> writes: Rich> Hello. Rich> David Favor wrote: Rich> [snip] >> Is there an alternative way to access libtool 1.5a? Rich> [snip] Rich> I don't know. Maybe one of the GNU libtool maintainers can help? I have an entire duplicate of the CVSROOT of libtool, last synchronized in the night preceding the shutdown, in case someone want to work from it locally (make sure you comment out or update the LockDir option in CVSROOT/config before trying to use this tree). Here it is: http://gadl.nerim.net/pub/libtool-CVSROOT.tar.bz2 -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
GNU Automake 1.8 released
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. The NEWS entry is appended. Thanks to all people who have reported bugs, contributed code, suggested enhancements, or answered user questions on the mailing lists. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.8.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.8.tar.gz.sig ftp://ftp.gnu.org/gnu/automake/automake-1.8.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.8.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.8.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.8.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.8.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.8.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors which are listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: 0a83fd4a2a32dc966b83ca3be86f884b automake-1.8.tar.bz2 d1001db5ab96be087817e7b7b4ba3621 automake-1.8.tar.gz Please report bugs by mail to <[EMAIL PROTECTED]>, or (preferred) at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake New in 1.8: * Meta-News - The NEWS file is more verbose. * Requirements - Autoconf 2.58 or greater is required. * New features - Default source file names in the absence of a _SOURCES declaration are made by removing any target extension before appending `.c', so to make the libtool module `foo.la' from `foo.c', you only need to do this: lib_LTLIBRARIES = foo.la foo_la_LDFLAGS = -module For backward compatibility, foo_la.c will be used instead of foo.c if this file exists or is the explicit target of a rule. However -Wobsolete will warn about this deprecated naming. - AR's `cru' flags are now set in a global ARFLAGS variable instead of being hard-coded in each $(AR) invocation, so they can be substituted from configure.ac. This has been requested by people dealing with non-POSIX ar implementations. - New warning option: -Woverride. This will warn about any user target or variable definitions which override Automake definitions. - Texinfo rules back up and restore info files when makeinfo fails. - Texinfo rules now support the `html' target. Running this requires Texinfo 4.0 or greater. `html' is a new recursive target, so if your package mixes hand-crafted `Makefile.in's with Automake-generated `Makefile.in's, you should adjust the former to support (or ignore) this target so that `make html' recurses successfully. If you had a custom `html' rule in your `Makefile.am', it's better to rename it as `html-local', otherwise your rule will override Automake's new rule (you can check that by running `automake -Woverride') and that will stop the recursion to subdirectories. Last but not least, this `html' rule is declared PHONY, even when overridden. Fortunately, it appears that few packages use a non-PHONY `html' rule. - Any file which is m4_included from configure.ac will appear as a configure and Makefile.in dependency, and will be automatically distributed. - The rules for rebuilding Makefiles and Makefile.ins will now rebuild all Makefiles and all Makefile.ins at once when one of configure's dependencies has changed. This is considerably faster than previous implementations, where config.status and automake were run separately in each directory (this still happens when you change a Makefile.am locally, without touching configure.ac or friends). Doing this also solves a longstanding issue: these rebuild rules failed to work when adding new directories to the tree, forcing you to run automake manually. - For similar reasons, the rules to rebuild configure, config.status, and aclocal.m4 are now defined in all directories. Note that if you were using the CONFIG_STATUS_DEPENDENCIES and CONFIGURE_DEPENDENCIES (formerly undocumented) variables, you should better define them in all directories. This is easily done using an AC_SUBST (make sure you prefix these dependencies with $(top_srcdir) since this variable will appear at different levels of the build tree). - aclocal will now use `m4_include' instead of copying local m4 files into aclocal.m4. (Local m4 files are those you ship with your project, other files will be copied as usual.) Because m4_included files are automatically distributed, it means for most projects there is no point in EXTRA_DISTing the list of m4 files which are used. (You can probably get rid of m4/Makefile.am if you had one.) - acl
Re: Missing, presumed Dead! Libtool CVS logging via e-mail
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 broken CVSweb URLs along the way). I have a copy of these files. But the problem is that you can't commit anything under CVSROOT/ with the current setup of savannah. A few people have already complened about this on [EMAIL PROTECTED], but I have not seen any answer. I guess it's because loginfo and friends allow you to run arbitrary commands on the CVS server. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
using --tag=XXX in automake-generated rules (Was: Re: 'ccache gcc' as compiler with libtool)
>>> "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 --tag ? [...] Gary> _LT_AC_TAGCONFIG exists in branch-1-5 and HEAD. Not quite. branch-1-5 has _LT_AC_TAGCONFIG but HEAD has _LT_AC_TAG_CONFIG. I prefer to rely on AC_LIBTOOL_TAGS, because this macro supplies a list of supported tags (either the tags supplied by the users, or the default list of tags). Is this OK with you? Below is the implementation I propose, it traces both _LT_AC_TAG_CONFIG for Libtool 1.5 and AC_LIBTOOL_TAGS for newer versions. BTW currently the --tag option and the AC_LIBTOOL_TAGS macro are not documented in the Libtool manual. 2004-01-02 Alexandre Duret-Lutz <[EMAIL PROTECTED]> Fix for PR automake/289: * automake.in (Automake::Struct::libtool_tag): New attribute. Define it for the language that have a Libtool tag. (%libtool_tags): New variable. (handle_languages, define_compiler_variable) (define_linker_variable): Pass --tag=XXX to libtool if supported. (scan_autoconf_traces): Scan for _LT_AC_TAGCONFIG and AC_LIBTOOL_TAGS. * tests/libtool3.test, tests/subobj9.test: Check that --tag=XXX are output. Index: NEWS === RCS file: /cvs/automake/automake/NEWS,v retrieving revision 1.260 diff -u -r1.260 NEWS --- NEWS1 Jan 2004 18:54:20 - 1.260 +++ NEWS2 Jan 2004 18:37:17 - @@ -1,5 +1,8 @@ New in 1.8a: +* Libtool tags are used with libtool versions that support it. + (I.e., with Libtool 1.5 or greater.) + * Makefile.in bloat reduction. - Inference rules are used to compile sources in subdirectories when Index: automake.in === RCS file: /cvs/automake/automake/automake.in,v retrieving revision 1.1533 diff -u -r1.1533 automake.in --- automake.in 1 Jan 2004 21:57:23 - 1.1533 +++ automake.in 2 Jan 2004 18:37:21 - @@ -76,6 +76,9 @@ # (defaults to []) 'flags' => "@", + # Any tag to pass to libtool while compiling. + 'libtool_tag' => "\$", + # The file to use when generating rules for this language. # The default is 'depend2'. 'rule_file' => "\$", @@ -332,6 +335,9 @@ # Where AM_GNU_GETTEXT appears. my $ac_gettext_location; +# Lists of tags supported by Libtool. +my %libtool_tags = (); + # TRUE if we've seen AC_CANONICAL_(HOST|SYSTEM). my $seen_canonical = 0; my $canonical_location; @@ -663,6 +669,7 @@ 'linker' => 'LINK', 'link' => '$(CCLD) $(AM_CFLAGS) $(CFLAGS) $(AM_LDFLAGS) $(LDFLAGS) -o $@', 'compile_flag' => '-c', + 'libtool_tag' => 'CC', 'extensions' => ['.c'], '_finish' => \&lang_c_finish); @@ -678,6 +685,7 @@ 'compiler' => 'CXXCOMPILE', 'compile_flag' => '-c', 'output_flag' => '-o', + 'libtool_tag' => 'CXX', 'lder' => 'CXXLD', 'ld' => '$(CXX)', 'pure' => 1, @@ -788,6 +796,7 @@ 'compiler' => 'F77COMPILE', 'compile_flag' => '-c', 'output_flag' => '-o', + 'libtool_tag' => 'F77', 'lder' => 'F77LD', 'ld' => '$(F77)', 'pure' => 1, @@ -820,6 +829,7 @@ 'compile' => '$(F77) $(DEFS) $(DEFAULT_INCLUDES) $(INCLUDES) $(AM_CPPFLAGS) $(CPPFLAGS) $(AM_FFLAGS) $(FFLAGS)', 'compile_flag' => '-c', 'output_flag' => '-o', + 'libtool_tag' => 'F77', 'pure' => 1, 'extensions' => ['.F']); @@ -837,6 +847,7 @@ 'compiler' => 'RCOMPILE', 'compile_flag' => '-c', 'output_flag' => '-o', + 'libtool_tag' => 'F77',
Re: using --tag=XXX in automake-generated rules
>>> "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 the language that have a Libtool tag. adl> (%libtool_tags): New variable. adl> (handle_languages, define_compiler_variable) adl> (define_linker_variable): Pass --tag=XXX to libtool if supported. adl> (scan_autoconf_traces): Scan for _LT_AC_TAGCONFIG and AC_LIBTOOL_TAGS. adl> * tests/libtool3.test, tests/subobj9.test: Check that --tag=XXX is adl> output. I'm installing this. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Library dependencies & make install
>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: [...] Bob> libraries are installed in the same order as specified by Bob> lib_LTLIBRARIES. If the ordering of lib_LTLIBRARIES does Bob> not jive with the library dependency order, then libtool Bob> fails to re-link the library because some libraries it Bob> depends are not installed yet. Even worse, it may appear Bob> that installation is successful, but some of the libraries Bob> are accidentally linked with older versions of the Bob> libraries which were already installed. Bob> It seems to me that Automake should compute an optimum library Bob> installation order based on the specified libtool library (.la) Bob> dependencies. This would help ensure that installation errors do not Bob> occur due to some hap-hazard lib_LTLIBRARIES list order (e.g. they Bob> could be in alphabetical order). It's not clear to me how circular dependencies would be handled. Also, I don't know how this order can be computed when all these libraries are built into many directories. Another idea is to split the installation procedure in two steps: copy 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
Re: libtool macros installed in pkgdatadir?
>>> "Braden" == Braden McDaniel <[EMAIL PROTECTED]> writes: [...] Braden> Right... But aclocal pulls them from a standard location on the Braden> system. While this means the distribution may be colored by Braden> characteristics of the system where it's built, it does mean that in Braden> general package maintainers aren't responsible for maintaining the Braden> macros they're using. Yes. The maintenance argument applies better to custom macros (e.g., maintaining acinclude.m4 is a pain). However lumping everything in aclocal.m4, also means users or developers cannot rebuild aclocal.m4 unless they have the macro installed. It don't happen if the macro is separately distributed. The `Local Macros' node of the Automake 1.8 manual discusses both issues. [...] Braden> What I *am* concerned with is the prospect of having manually to copy Braden> the file with PKG_CHECK_MODULES (for instance) to my project's Braden> directories each time the system pkg-config is upgraded in order to Braden> ensure parity. I'm also concerned that other users of my project's CVS Braden> repository would have to do the same. Pushing "my" PKG_CHECK_MODULES Braden> into my CVS repository is not a solution, as there may be a version Braden> mismatch with the version of pkg-config on another user's system. The plan is to have this copy performed automatically by the aclocal 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 not fear this. Installing third-party macros in /usr/share/aclocal will continue to work. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Why doesn't ...
>>> "Scott" == Scott James Remnant <[EMAIL PROTECTED]> writes:
Scott> On Thu, 2004-02-05 at 03:40, name wrote:
>> Why doesn't installation copy libtool.m4 to aclocal?
>>
Scott> Assuming you are talking about CVS HEAD (libtool 1.5a, future 1.6
Scott> release) this is because libtoolize now copies libtool.m4 from its own
Scott> data directory into your macro directory.
[...]
Scott> This is consistent with "The Future of `aclocal'" as outlined in the
Scott> Automake manual chapter of the same title.
I know you are just explaining the libtoolize behavior with
this sentence, but I fear that some people might read it as a
justification for not putting things into /usr/share/aclocal/.
I'm installing the following patch on automake HEAD and
branch-1-8 to make things clearer.
Changing libtoolize to install libtool.m4 locally is a great
step, but it seems it would work as well if libtool.m4 was taken
from /usr/share/aclocal/. Moving it away might be too harsh for
users. AFAICT the real advantage with putting libtool.m4 out of
the way, is that it helps ./bootstrap to cope with the
shortcomings of the current aclocal implementation...
BTW, the conditionally defined AC_PROG_EGREP debacle (replace
AC_PROG_EGREP by any Autoconf macro) should not exist with the
replacement machinery Akim plotted, since AC_DEFUNs would be
traced instead of being hastily grepped. Actually I think this
part of the plot could be implemented now (i.e., in am-1.9)
easily. I'll try to look at it.
Scott> The great advantage of this is that it ensures that
Scott> libtool.m4 and ltmain.sh are matched versions, running
Scott> libtoolize and forgetting to run aclocal, or the
Scott> reverse, used to be the source of many developer's woes
Scott> in the past.
Good point. I wonder if you'll have more complaints about
mismatched versions or about missing libtool.m4 (not meaning to
be flip, I don't read bug-libtool so I don't know how frequent
the version mismatch problem 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
move the bazooka over him :))
2004-02-03 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* doc/automake.texi (Future of aclocal): Make clearer that
it's ok to install macros into /usr/share/aclocal/.
Index: doc/automake.texi
===
RCS file: /cvs/automake/automake/doc/automake.texi,v
retrieving revision 1.27
diff -u -r1.27 automake.texi
--- doc/automake.texi 1 Feb 2004 16:28:50 - 1.27
+++ doc/automake.texi 3 Feb 2004 22:05:44 -
@@ -2088,8 +2088,9 @@
The new implementation will probably be done slightly differently.
For instance it could enforce the @file{m4/}-style layout discussed in
[EMAIL PROTECTED] Macros}, and take care of copying (or even updating)
-third-party macro into this directory.
[EMAIL PROTECTED] Macros}, and take care of copying (and even updating)
+third-party macros from @file{/usr/share/aclocal/} into the local
[EMAIL PROTECTED]/} directory.
We have no idea when and how this will happen. This has been
discussed several times in the past, but someone still has to commit
@@ -2115,6 +2116,13 @@
should simplify its logic a lot (less things to maintain, yum!), it's
even likely you will not need the script anymore, and more to the point
you will not call @command{aclocal} directly anymore.
+
+For the time being, third-party packages should continue to install
+public macros into @code{/usr/share/aclocal/}. If @command{aclocal}
+is replaced by another tool it might make sense to rename the
+directory, but supporting @code{/usr/share/aclocal/} for backward
+compatibility should be really easy provided all macros are properly
+written (@pxref{Extending aclocal}).
@node Top level
--
Alexandre Duret-Lutz
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: multi part library?
>>> "Ralph" == Ralph Schleicher <[EMAIL PROTECTED]> writes: Ralph> I've sent Andreas an example project by email Ralph> demonstrating the proper use of Automake and Libtool for Ralph> his case. For future people reaching this thread in the archive and seeking 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 libraries in a few paragraphs too. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
about libtool's trace interface for tags
Is it done or is there any obstacle to it? I'm dreaming about Automake 1.9, and if possible I would like to include support for this. All we need is a (preferably documented) way to --trace for the list of tags that will be understood by the configure-generated libtool script. (I think it 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.gnu.org/mailman/listinfo/libtool
Re: about libtool's trace interface for tags
>>> "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 include support >> for this. >> Scott> The current interface should be pretty good, trace for Scott> invocations of _LT_TAG and the first argument will be a Scott> tag name that maps equally to a language name (CC, CXX, Scott> F77, etc.) Huh? ~/projs/cvs/libtool % autoconf --trace _LT_TAG configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: configure.ac:199:_LT_TAG: -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: about libtool's trace interface for tags
>>> "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 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 include support >> >> for this. >> >> >> Scott> The current interface should be pretty good, trace for Scott> invocations of _LT_TAG and the first argument will be a Scott> tag name that maps equally to a language name (CC, CXX, Scott> F77, etc.) >> >> Huh? >> Scott> Sorry, I'll put my brain on this time ... :o) Scott> * _LT_LANG * Scott> descent libtool-bootstrap% autoconf --trace=_LT_LANG Scott> configure.ac:178:_LT_LANG:CXX Scott> configure.ac:178:_LT_LANG:GCJ Scott> configure.ac:178:_LT_LANG:F77 Scott> configure.ac:178:_LT_LANG:RC Ah, thanks! Sorry for being dense, but since it takes tag names as argument, why is it called _LT_LANG? How about calling it `LT_SUPPORTED_TAG' or something similar? I can supply a patch to rename and document this macro in the manual, if that sounds OK. I really think that this interface should be public, like every other traced macros (at least all those registered in autom4te.cfg). -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: about libtool's trace interface for tags
>>> "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? >> Scott> Because it actually takes language configuration names, which just Scott> happen to be the same as the tags that get generated. (There's a patch Scott> floating around by me that breaks that assumption.) Sorry for the delay. Sorry also if this mail look uselessly long and finicky, but I am really confused and worried by your last comment. I must also precise I'm not reading everything on libtool@ and libtool-patches@, so I'm not aware of all the latest developments and patches floating around. Obviously my vocabulary is also out of date :) What is the difference between a tag name a language configuration name a language name an internal name ? So far I had been assuming that there was only to sort of names: language names (passed as argument to LT_LANG), and tag names (passed as arguments to --tag=). What exactly is the assumption that you'll break? The arguments passed to _LT_LANG will not always be tag names? If so I'm afraid Automake cannot use this macro. (See below.) >> How about calling it `LT_SUPPORTED_TAG' or something similar? I >> can supply a patch to rename and document this macro in the >> manual, if that sounds OK. I really think that this interface >> should be public, like every other traced macros (at least all >> those registered in autom4te.cfg). >> Scott> Because it isn't public ... Call it a storm-resistant interface for third-party tools :) Scott> LT_LANG is the public-facing version of this macro, Scott> which takes "friendly" names like 'C++' and 'Fortran Scott> 77'. It then calls _LT_LANG with the internal name, Scott> which is the most convenient trace point for you. I don't want Automake to rely on anything internal to Libtool. This is not a safe road. If Libtool use some *internal* names, Automake should not rely on them. I couldn't find the documentation for libtool's --tag=TAG option, by I'm assuming it's a public option. It's list of allowed argument is therefore something public too. I will call these arguments "tags". In order to generate Makefiles, Automake needs to know what language libtool has been configured for, and the corresponding tags to pass to the --tag option. So far I have been assuming that there would be a macro to trace that would return a list of enabled tags. I have also been assuming that the set of possible tags returned by this macro was constant (more precisely adding tags for new language is OK, but renaming the tag of an existing language is not). Automake knows these tags (these are public so it's ok) and can make the correspondence with the languages it supports. In other words, automake traces tags and uses these both as arguments to --tag and as unique identifier for languages. I your first statement implies that the tags will be renamed into language configuration names, then we must work out a more complex interface. Something that return pairs of (unique-language-id, tags) for instance. I hope we won't have to do this, though. Scott> The trouble with making public macros is people will Scott> tend to put them in their configure.ac, no matter how Scott> large the instruction telling them not to. But you don't need to describe it as a macro if you prefer. For instance in the documentation for the --tag=TAG option there will likely be a list of allowed tags, and it would sound appropriate to state something like: It is sometimes helpful to query the list of tags configured in a package from a script or some automated tool. This can be done using `autoconf --trace LT_SUPPORTED_TAG=\$1'. Or something along these lines. Personally I would find more natural to have a `Tracing Interface' node listing all such macros of interest. Even if there is only one macro for now, this will make room for future additions, and clearly state what macro it is OK to trace (so that you don't have to care about people that abusively trace the inner guts of Libtool). I don't think people will monkeyly copy random documented macros to their configure.ac to see how they help breaking their package; but if they do, it's really their problem. Monkeys should not hinder the development of useful features :) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Why doesn't ...
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: [...] Gary> FYI: I've made CVS libtoolize take its files from $aclocaldir again. Great! Thanks for doing this. Does it also handle the case where AC_CONFIG_MACRO_DIR isn't used? libtoolize used 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
Automake 1.8d uploaded (release candidate for Automake 1.9)
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 1.9 before the end of the month if no important regression is reported. ** Please report bugs to <[EMAIL PROTECTED]>. ** You can find this beta here: ftp://alpha.gnu.org/gnu/automake/automake-1.8d.tar.gz ftp://alpha.gnu.org/gnu/automake/automake-1.8d.tar.gz.sig ftp://alpha.gnu.org/gnu/automake/automake-1.8d.tar.bz2 ftp://alpha.gnu.org/gnu/automake/automake-1.8d.tar.bz2.sig Here are the MD5 sums: e1ce2805bbe4338b9e2a7107a51af7c4 automake-1.8d.tar.bz2 dd98fe7c2ea013d0ffc29ebb94086b4c automake-1.8d.tar.gz New between 1.8.5 and 1.8d: * Makefile.in bloat reduction: - Inference rules are used to compile sources in subdirectories when the `subdir-objects' option is used and no per-target flags are used. This should reduce the size of some projects a lot, because Automake used to output an explicit rule for each such object in the past. - Automake no longer outputs three rules (.o, .obj, .lo) for each object that must be built with explicit rules. It just outputs the rules required to build the kind of object considered: either the two .o and .obj rules for usual objects, or the .lo rule for libtool objects. * Change to Libtool support: - Libtool tags are used with libtool versions that support them. (I.e., with Libtool 1.5 or greater.) - Automake is now able to handle setups where a libtool library is conditionally installed in different directories, as in if COND lib_LTLIBRARIES = liba.la else pkglib_LTLIBRARIES = liba.la endif liba_la_SOURCES = ... * Changes to aclocal: - aclocal now ensures that AC_DEFUNs and AU_DEFUNs it discovers are really evaluated, before it decides to include them in aclocal.m4. This solves nasty problems with conditional redefinitions of Autoconf macros in /usr/share/aclocal/*.m4 files causing extraneous *.m4 files to be included in any project using these macros. (Calls to AC_PROG_EGREP causing libtool.m4 to be included is the most famous instance of this bug.) - Do not complain about missing conditionally AC_REQUIREd macros that are not actually used. In 1.8.x aclocal would correctly determine which of these macros were really needed (and include only these in the package); unfortunately it would also require all of them to be present in order to run. This created situations were aclocal would not work on a tarball distributing all the macros it uses. For instance running aclocal on a project containing only the subset of the Gettext macros in use by the project did not work, because gettext conditionally requires other macros. * Portability improvements: - Tar format can be chosen with the new options tar-v7, tar-ustar, and tar-pax. The new option filename-length-max=99 helps diagnosing filenames that are too long for tar-v7. (PR/414) - Variables aumented with `+=' are now automatically flattened (i.e., trailing backslashes removed) and then wrapped around 80 colummns (adding trailing backslashes). In previous versions, a long series of VAR += value1 VAR += value2 VAR += value3 ... would result in a single-line definition of VAR that could possibly exceed the maximum line length of some make implementations. Non-augmented variables are still output as they are defined in the Makefile.am. * Miscellaneous: - Support Fortran 90/95 with the new "fc" and "ppfc" languages. Works the same as the old Fortran 77 implementation; just replace F77 with FC everywhere (exception: FFLAGS becomes FCFLAGS). Requires a version of autoconf which provides AC_PROG_FC (>=2.59). - Support for conditional _LISP. - Support for conditional -hook and -local rules (PR/428). - Diagnose AC_CONFIG_AUX_DIR calls following AM_INIT_AUTOMAKE. (PR/49) - Automake will not write any Makefile.ins after the first error it encounters. The previous Makefile.ins (if any) will be left in place. (Warnings will not prevent output, but remember they can be turned into errors with -Werror.) - The restriction that SUBDIRS must contain direct children is gone. Do not abuse. - The manual tells more about SUBDIRS vs. DIST_SUBDIRS. It also gives an example of nested packages using AC_CONFIG_SUBDIRS. pgpnHd7zYUu4d.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: cvs build prob
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 "$no_glob_subst"` ? The right-hand side of `=' is never IFS-splitted, so the outermost double quotes are superfluous. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
GNU Automake 1.9 released
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 enhancements, and answering user questions on the mailing lists. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.9.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.9.tar.gz.sig ftp://ftp.gnu.org/gnu/automake/automake-1.9.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.9.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.9.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.9.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.9.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.9.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors which are listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: c0b6434087e3be0606ef9d172238f26c automake-1.9.tar.bz2 8398de9b2100d3cb1c94f5cd29166b5d automake-1.9.tar.gz Please report bugs by mail to <[EMAIL PROTECTED]>, or at http://sources.redhat.com/cgi-bin/gnatsweb.pl?database=automake New in 1.9: * Makefile.in bloat reduction: - Inference rules are used to compile sources in subdirectories when the `subdir-objects' option is used and no per-target flags are used. This should reduce the size of some projects a lot, because Automake used to output an explicit rule for each such object in the past. - Automake no longer outputs three rules (.o, .obj, .lo) for each object that must be built with explicit rules. It just outputs the rules required to build the kind of object considered: either the two .o and .obj rules for usual objects, or the .lo rule for libtool objects. * Change to Libtool support: - Libtool tags are used with libtool versions that support them. (I.e., with Libtool 1.5 or greater.) - Automake is now able to handle setups where a libtool library is conditionally installed in different directories, as in if COND lib_LTLIBRARIES = liba.la else pkglib_LTLIBRARIES = liba.la endif liba_la_SOURCES = ... * Changes to aclocal: - aclocal now ensures that AC_DEFUNs and AU_DEFUNs it discovers are really evaluated, before it decides to include them in aclocal.m4. This solves nasty problems with conditional redefinitions of Autoconf macros in /usr/share/aclocal/*.m4 files causing extraneous *.m4 files to be included in any project using these macros. (Calls to AC_PROG_EGREP causing libtool.m4 to be included is the most famous instance of this bug.) - Do not complain about missing conditionally AC_REQUIREd macros that are not actually used. In 1.8.x aclocal would correctly determine which of these macros were really needed (and include only these in the package); unfortunately it would also require all of them to be present in order to run. This created situations were aclocal would not work on a tarball distributing all the macros it uses. For instance running aclocal on a project containing only the subset of the Gettext macros in use by the project did not work, because gettext conditionally requires other macros. * Portability improvements: - Tar format can be chosen with the new options tar-v7, tar-ustar, and tar-pax. The new option filename-length-max=99 helps diagnosing filenames that are too long for tar-v7. (PR/414) - Variables aumented with `+=' are now automatically flattened (i.e., trailing backslashes removed) and then wrapped around 80 colummns (adding trailing backslashes). In previous versions, a long series of VAR += value1 VAR += value2 VAR += value3 ... would result in a single-line definition of VAR that could possibly exceed the maximum line length of some make implementations. Non-augmented variables are still output as they are defined in the Makefile.am. * Miscellaneous: - Support Fortran 90/95 with the new "fc" and "ppfc" languages. Works the same as the old Fortran 77 implementation; just replace F77 with FC everywhere (exception: FFLAGS becomes FCFLAGS). Requires a version of autoconf which provides AC_PROG_FC (>=2.59). - Support for conditional _LISP. - Support for conditional -hook and -local rules (PR/428). - Diagnose AC_CONFIG_AUX_DIR calls following AM_INIT_AUTOMAKE. (PR/49) - Automake will not write any Makefile.ins after the first error it encounters. The previous Makefile.ins (if any) will be left in place. (Warnings will not prevent output, but remember they can be turned into errors with -Werror.) - The restriction that SUBDIRS must contain direct children is gone. Do not ab
Re: ltmain.sh
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: [...] Gary> I think that what we *really* need is for automake to not Gary> assume ltmain.sh is in the source tree, and some way for Gary> the libtool Makefile.am to declare that config/ltmain.sh Gary> is a built file so that automake doesn't keep stopping Gary> before it is built without the horrible bootstrap $fakes Gary> hack. Two answers: short-term, and long-term. short-term: IMHO you are swimming against the stream, that's why it looks hard. Consider the following: Automake wants to distribute that file? So let's distribute it. The file is distributed? So let's update it in the source tree. The file is expected to be identical for all users installing the same revision of libtool? So let's not build it from ./configure (you should not do this for a distributed file anyway): have it created by bootstrap and write a custom Makefile rule that updates the file whenever configure.ac changes. This way you meet Automake expectations and never have to lie to it, so things should work as expected. The drawback is that you'll waste a few kilobytes, but I don't think the economy is worth the irritation one gets debugging clumsy hacks. Automake has a similar issue with its m4/amversion.m4 file. It must be generated from m4/amversion.in, but it's also a prerequisite to run autoconf. The setup is similar to the one I suggest above (except the rebuild rule does not depend on configure.ac because a bootstrap is needed anyway). long-term: To reduce the amount of hard-coded knowledge in Automake, I'd like to introduce a macro, say AM_REQUIRE_AUX_FILE, so that third-party Autoconf macros can instruct automake to 1. check that the files they need are present, 2. distribute them. Libtool could be equipped with m4_ifdef([A][M_REQUIRE_AUX_FILE], [A][M_REQUIRE_AUX_FILE([ltmain.sh])]) and the hard coded test removed from Automake. Then it seems it would not be too difficult to disable the above line in libtool itself, so that Automake never bothers about ltmain.sh. [...] Gary> Rerunning autoreconf -fvi on all 8 test/*demo* trees and Gary> the libtool source tree proper after every cvs update and Gary> commit takes about 30 minutes 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
GNU Automake 1.9.1 released
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 find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.9.1.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.9.1.tar.gz.sig ftp://ftp.gnu.org/gnu/automake/automake-1.9.1.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.9.1.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.9.1.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.9.1.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.9.1.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.9.1.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: eb65202d00d498c8b0729110ee2d4d51 automake-1.9.1.tar.gz 65143af82931c2c4d703d3a17c1c9d15 automake-1.9.1.tar.bz2 Please report bugs to <[EMAIL PROTECTED]>. Bugs fixed in 1.9.1: This release fixes three longstanding bugs. * Adjust #line directives in `parser.h' (when ylwrap is not used). (PR/432) * Fix definition of YLWRAP when ylwrap is installed in a default aux directory found in a parent package. * Properly recognize AC_CANONICAL_BUILD and AC_CANONICAL_TARGET. pgpBkuBFB6Z4W.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: compile problem
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes:
[...]
>>> On Mon, Aug 23, 2004 at 08:29:07PM +0100, Patrick Welche wrote:
>>>
>>>> I just tried to build cvs libtool with cvs auto* all from today, and get:
>>>>
>>>> make all-recursive
>>>> Making all in .
>>> cd . && /bin/ksh /usr/src/local/libtool/config/missing --run automake-1.9a --gnits
>>>> libltdl/Makefile.am: C objects with per-target flags but `AM_PROG_CC_C_O' not in
>>>> `configure.ac'
[...]
Gary> Libtool has a non compiler specific version of that macro called
Gary> _LT_COMPILER_C_O which is automatically called by LT_INIT.
Gary> Do we need to patch automake to accept LT_INIT for
Gary> subdir-objects projects, or do you think AC_PROG_CC_C_O
Gary> should be merged with _LT_COMPILER_C_O?
It's AM_PROG_CC_C_O Automake needs, not AC_PROG_CC_C_O.
I'm installing the following.
2004-09-07 Alexandre Duret-Lutz <[EMAIL PROTECTED]>
* automake.in (lang_c_rewrite): Do not require AM_PROG_CC_C_O for
libtool objects.
(handle_single_transform): Pass nonansi_obj to &$subr so
lang_c_rewrite can distinguish libtool objects.
* tests/libtool7.test: Use subdir-objects without using AM_PROG_CC_C_O.
Report from Gary V. Vaughan and Patrick Welche.
Index: automake.in
===
RCS file: /cvs/automake/automake/automake.in,v
retrieving revision 1.1578
diff -u -r1.1578 automake.in
--- automake.in 7 Sep 2004 19:52:47 - 1.1578
+++ automake.in 7 Sep 2004 21:00:34 -
@@ -1576,7 +1576,8 @@
# further.
my $subr = \&{'lang_' . $lang->name . '_rewrite'};
my ($r, $source_extension)
- = &$subr ($directory, $base, $extension, $have_per_exec_flags);
+ = &$subr ($directory, $base, $extension,
+ $nonansi_obj, $have_per_exec_flags);
# Skip this entry if we were asked not to process it.
next if $r == LANG_IGNORE;
@@ -5079,7 +5080,7 @@
# Rewrite a single C source file.
sub lang_c_rewrite
{
- my ($directory, $base, $ext, $have_per_exec_flags) = @_;
+ my ($directory, $base, $ext, $nonansi_obj, $have_per_exec_flags) = @_;
if (option 'ansi2knr' && $base =~ /_$/)
{
@@ -5091,13 +5092,17 @@
if (option 'subdir-objects')
{
$r = LANG_SUBDIR;
- $base = $directory . '/' . $base
- unless $directory eq '.' || $directory eq '';
+ if ($directory && $directory ne '.')
+ {
+ $base = $directory . '/' . $base;
- err_am ("C objects in subdir but `AM_PROG_CC_C_O' "
- . "not in `$configure_ac'",
- uniq_scope => US_GLOBAL)
- unless $seen_cc_c_o;
+ # libtool is always able to put the object at the proper place,
+ # so we do not have to require AM_PROG_CC_C_O when building .lo files.
+ err_am ("C objects in subdir but `AM_PROG_CC_C_O' "
+ . "not in `$configure_ac'",
+ uniq_scope => US_GLOBAL)
+ unless $seen_cc_c_o || $nonansi_obj eq '.lo';
+ }
# In this case we already have the directory information, so
# don't add it again.
@@ -5110,7 +5115,10 @@
: "$directory/");
}
- if (! $seen_cc_c_o && $have_per_exec_flags && ! option 'subdir-objects')
+ if (! $seen_cc_c_o
+ && $have_per_exec_flags
+ && ! option 'subdir-objects'
+ && $nonansi_obj ne '.lo')
{
err_am ("C objects with per-target flags but `AM_PROG_CC_C_O' "
. "not in `$configure_ac'",
Index: tests/libtool7.test
===
RCS file: /cvs/automake/automake/tests/libtool7.test,v
retrieving revision 1.1
diff -u -r1.1 libtool7.test
--- tests/libtool7.test 31 Jan 2003 23:40:58 - 1.1
+++ tests/libtool7.test 7 Sep 2004 21:00:34 -
@@ -1,5 +1,5 @@
#! /bin/sh
-# Copyright (C) 2003 Free Software Foundation, 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
Re: compile problem
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: [...] Gary> So does that simply mean that libtool objects can be correctly built Gary> as subdir-objects without AM_PROG_CC_C_O? Sorry to bug you, just Gary> making sure I understand why you made the patch the way you did... The purpose of AM_PROG_CC_C_O is to replace CC by the `compile' script which emulates a compiler that supports `-c -o' when the real CC does not. As you pointed out, libtool already supplies such emulation, so `compile' is never needed when compiling lo 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 mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
GNU Automake 1.9.2 released (10th anniversary release)
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" chapter that tries to go through these 10 years. You can find the new release here: ftp://ftp.gnu.org/gnu/automake/automake-1.9.2.tar.gz ftp://ftp.gnu.org/gnu/automake/automake-1.9.2.tar.gz.sig ftp://ftp.gnu.org/gnu/automake/automake-1.9.2.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.9.2.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.9.2.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.9.2.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.9.2.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.9.2.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: b5799f983d0a062ec59810f6b289cd27 automake-1.9.2.tar.bz2 6f874b649fc3bbe8c54e7592f6fb2d10 automake-1.9.2.tar.gz Please report bugs to <[EMAIL PROTECTED]>. Bugs fixed in 1.9.2: * Sort rm commands output for mostlyclean-generic, clean-generic, distclean-generic and maintainer-clean-generic, so that the produced Makefile is not sensible to the way Perl sorts its hashes. * Support `+' in the name of directories given to `include'. * Preserve spaces in the arguments of `compile'. * `missing' will no longer try to emulate a tool that is run with `--version' or `--help' as argument. * Noteworthy manual update: - There is a new chapter about the history of Automake. pgpffXTDNhc6x.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: compile problem
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: Gary> But for a project built with `make -j', we still need AM_PROG_CC_C_O Gary> and _LT_COMPILER_C_O to understand each others' locks :-( Seems so. I thought it was not needed because when AM_PROG_CC_C_O decides `compile' is required, it is also used when compiling libtool objects. However perhaps I was wrong, because `compile' does something only for *.o and *.obj files, it is a no-op for *.lo files. Maybe we need to tell AM_PROG_CC_C_O about *.lo files. To makes matter worse, because AM_PROG_CC_C_O horribly overwrites CC, it's not clear to me whether AM_PROG_CC_C_O LT_INIT is equivalent to LT_INIT AM_PROG_CC_C_O It looks like Libtool's `-c -o' check would not give the same answer. I haven't dug all this; I think Ralf W sent some mail about it, 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
Re: compile problem
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: [...] Gary> I'm not saying that the compile script should be used, Gary> just that the tests to determine whether it might be Gary> needed are run as a matter of course. Looking at the Gary> implementation of AM_PROG_CC_C_O, I see that it would Gary> need a bit of refactoring to make that happen... Yeah. Presently you need `compile' if you use the macro, and people mind about extra useless scripts. Gary> My feeling at the moment is that it would be a small price to pay for Gary> simplifying the interface to automake (i.e. _not_ being sometimes told, Gary> partway through the automake run, that you must change your configure.ac Gary> and start again at the aclocal stage). I agree that being told to update configure.ac can be annoying, even if it only occur once, but I'm not convinced that we should call such macros unconditionally. By this argument it looks like we should also always run AC_INIT_LIBTOOL so that Automake does not demand it once you introduce the first variable _LTLIBRARIES variable in a Makfile.am. Likewise for AC_PROG_YACC, 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
GNU Automake 1.9.3 released
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/gnu/automake/automake-1.9.3.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.9.3.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.9.3.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.9.3.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.9.3.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.9.3.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: 0ee08fb0ee48d20a4f8da99137340efd automake-1.9.3.tar.bz2 32d6ed7d94e3364bff23d1f80e8af2a6 automake-1.9.3.tar.gz Please report bugs to <[EMAIL PROTECTED]>. Bugs fixed in 1.9.3: * Bug introduced by 1.9: - Dependency tracking using mode "dashmstdout" or "dashXmstdout" did not work for libtool objects compiled with --tag (i.e., compiled with Libtool 1.5 or later). The compilation would succeed, but `depcomp' would emit a warning and not output any dependency information. * Long standing bugs: - Ignore comments from augmented variables, so that FOO = foo # bar FOO += baz no longer results in `FOO = foo # bar baz'. - `install-sh -d a/b/' failed to create `a/b/' because of the trailing `/'. - _PROGRAMS now always create programs. Before 1.9 it would mistakenly create a libtool library if the name of the program ended in `.la'. Between 1.9 and 1.9.2 a program with such a name would fail to build because half the code was assuming a program was being built, while the other half was considering a library... - `compile' now handles `*.obj' objects. - `aclocal' recognizes AC_DEFUN_ONCE. * Noteworthy manual updates: - LIBOBJS: more documentation and an example setup. - Libtool Convenience Libraries: show how to force the linker selection. - Extending: more comments about install-data-hook vs install-exec-hook. - Clean: document -local targets. pgprUIvIqtUn5.pgp Description: PGP signature ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
>>> "Gary" == Gary V Vaughan <[EMAIL PROTECTED]> writes: Gary> Hi Ralf, Gary> Ralf Wildenhues wrote: >> Hi Peter, >> >> * Peter Ekberg wrote on Tue, Nov 09, 2004 at 01:33:29PM CET: >> >>> Hello! >>> >>> There is no exception from the GPL in m4/ltoptions.m4, like >>> there is in the other lt*.m4 files in that directory. Is >>> that an oversight or is this file only needed for backwards >>> compatibility or something like that? Gary> I based this file on m4/options.m4 in automake and copied the Gary> license from there :-( The lack of exception is troubling, The copyright notices of Automake's m4/*.m4 files were added by Paul on 2001-09-22 (that was after the 1.5 release). It looks like the missing exception to the GPL is an omission nobody noticed so far. Before this change there was no boilerplate, and when the files were concatenated to form aclocal.m4, it was prepended with: | # aclocal.m4 generated automatically by aclocal 1.5 | | # Copyright 1996, 1997, 1998, 1999, 2000, 2001 | # Free Software Foundation, Inc. | # This file is free software; the Free Software Foundation | # gives unlimited permission to copy and/or distribute it, | # with or without modifications, as long as this notice is preserved. | | # This program is distributed in the hope that it will be useful, | # but WITHOUT ANY WARRANTY, to the extent permitted by law; without | # even the implied warranty of MERCHANTABILITY or FITNESS FOR A | # PARTICULAR PURPOSE. Today this copyright notice is still output in aclocal.m4, but it is followed by the copyright notices of all the files included. This sounds confusing since the top says "unlimited permission to copy and distribute with or without modifications" while the concatenated parts also include each a notice that state "GPL". (*) I don't really know what to think about this. Some ideas: 1. prefix all the m4/*.m4 licenses with `##' so aclocal omit them from aclocal.m4 (leaving only the "unlimited permission to ..." license added by aclocal) 2. add an exception to all the m4/*.m4 files similar to that used in the aux scripts 3. both Now you may also consider what happens when third-party m4 macros (with custom licensing) 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
Re: TODO
There are also at least two hot points at the interface between automake and libtool that may need work on both sides. - unifying locks between libtool and compile - the relinking dependency debacle: For libtool to relink libraries when installing them, all dependencies must have been installed. However automake cannot pre-compute this installation order when it is run, and computing it at compile-time look overly complicated and error prone. Instead, would it make sense to support a two-stage install as follows: 1. install all programs and libraries without relinking (in random 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/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: [...] Paul> Would you use the exact same wording in #2 that you Paul> already uses in the aux scripts? Does that wording still Paul> apply? I think so. Another idea would be to use a bison-like exception just to match the license of aclocal.m4: As a special exception to the GNU General Public License, when this file is copied by aclocal into an aclocal output file, you may use that output file without restriction. However this seems quite restrictive too me, as it wouldn't work if 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
Re: TODO
>>> "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> I don't believe that this would work since dependencies are inherited Bob> at link time based on existing registered library dependencies. This Bob> means that a library may link against a wrong library version, and the Bob> error would propagate. Bob> Automake can at least keep its part of the house in order by ensuring Bob> the correct library install order within the same Makefile. It does Bob> build the libraries in the correct order, assuming that LDADD has been Bob> used properly. I'm afraid I'm lost. I understand these two paragraphs as 1. dependencies are inherited at link time 2. libraries are already built (hence linked) in the correct order So when are the incorrect dependencies registered? At relink-time? Can't those of link-time be used? Bob> One approach which could be used is for libtool to support a mode Bob> where it is provided with a list of all the .la files for libraries to Bob> be installed, and libtool returns a re-ordered list which is ordered Bob> by increasing dependency. Automake would then use this to order its Bob> installation of libtool libraries. Efficient implementation of this Bob> capability in bourne shell sounds quite challenging. Not only that, but also supporting a arbitrary installation order of libraries in multi-Makefile projects. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: [...] Paul> As a special exception to the GNU General Public License, if you Paul> distribute this file as part of a package that uses the file as input Paul> to GNU Autoconf, GNU Automake, or GNU Libtool, then you may distribute Paul> the resulting output files under the same terms that you use for the Paul> rest of the package. I don't understand the intent of "as input to GNU Autoconf, GNU Automake, or GNU Libtool". AFAICT Libtool does not input m4 files, only the Autoconf tools and aclocal do. I assume "input to GNU Automake" means read by "aclocal to produce aclocal.m4". If so this text seems to imply that you can distribute aclocal.m4 (with an embedded copy of python.m4) under your licensing term only if you also distribute python.m4 (which is under GPL). But there is another case which I'd like to support: the case where python.m4 is distributed aside to aclocal.m4, and aclocal.m4 simply does m4_include([m4/python.m4]). Then python.m4 is not a resulting output file of aclocal. And still we'd like to relax the GPL. As a special exception to the GNU General Public License, if you distribute this file as part of a package that uses the file (or any derived output) as input to generate its configuration script with Autoconf, then you may distribute the file and resulting output files under the same terms 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) to preprocess the file, as long as the intent is to build a configure script. -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: TODO
>>> "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 >> dependencies must have been installed. However automake cannot >> pre-compute this installation order when it is run, and >> computing it at compile-time look overly complicated and error >> prone. Instead, would it make sense to support a two-stage Noah> The core problem appears to be that an Automake-generated Noah> Makefile.in uses dependencies when building installable Noah> products but then installs them in destination_PRIMARY Noah> batches without observing the dependencies it already Noah> knows. Indeed, if Automake did not know the dependency Noah> graph of each object, it could not build them reliably. Strictly speaking automake does not know these dependencies. It knows some dependencies, but because of the possibility to AC_SUBST variables for conditional linking, and doest not know exactly all of them (think libfoo_la_DEPENDENCIES = @SOME_LA@). However these dependencies are indeed known later at make time. In other word Makefile.in and Makefile.am do not have the necessary information to compute an installation order, but Makefile does. So yes, this order could be recorded during the build. Libtool already does that, doesn't it? If so it seems easier to get the dependencies from it. Noah> If Automake generated an install target for installable Noah> product, just as it generated a build target, would that Noah> not solve this problem? This sounds appealing, but wouldn't this imply that if two libraries depends on another one, the later will be installed twice? -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
>>> "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 >> files, only the Autoconf tools and aclocal do. Gary> Just trying to cover all bases to avoid more pain for future autotools Gary> versions. Note that libtoolize does actually read through aclocal.m4 Gary> and any files it m4_includes to find a few directory paths and decide Gary> whether to copy particular files. But none of the path you are looking for are specified in user files, not those we are considering. Also that argument would apply to Gettext as well, and maybe several other tools. We cannot list all of them and should not discriminate some of them. Gary> The use of GNU Autoconf is to prevent someone creating their Gary> own tool and calling that Autoconf to circumvent the license. I don't have a problem with GNU Autoconf, only GNU Libtool :) (And to some extent with GNU Automake too, but I can understand it in some way.) -- Alexandre Duret-Lutz ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: License of m4/ltoptions.m4
>>> "Paul" == Paul Eggert <[EMAIL PROTECTED]> writes: [...] Paul> As a special exception to the GNU General Public License, Paul> if you distribute this file as part of a package that Paul> automatically derives from this file a configuration Paul> 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 ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Convincing Automake to support libtool
>>> "Bob" == Bob Friesenhahn <[EMAIL PROTECTED]> writes: Bob> What I have now learned the hard way is that aclocal ignores the Bob> AC_CONFIG_MACRO_DIR([m4]) definition in configure.ac. IMHO it's a bug in whatever let you think aclocal would honor AC_CONFIG_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
Re: libtoolize: `configure.ac' does not exist
>>> "Ross" == Ross Boylan <[EMAIL PROTECTED]> writes: Ross> $ libtoolize -n Ross> libtoolize: `configure.ac' does not exist Ross> Try `libtoolize --help' for more information. Ross> $ libtoolize --version Ross> libtoolize (GNU libtool) 1.5.6 Ross> I am trying to use libtool/libtoolize in a project without autoconf or Ross> automake. libtoolize is for autoconf-based packages. If you do not use autoconf, you should require all your users to install libtool before they can install your package. Then in your Makefile you simply 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
Re: libtool --silent based on MAKEFLAGS?
>>> "Ralf" == Ralf Wildenhues <[EMAIL PROTECTED]> writes: [...] Ralf> So, how about this? Let's have Automake include $(LIBTOOLFLAGS) in Ralf> their libtool invocation. The user can then use Ralf> LIBTOOLFLAGS=--silent Ralf> at either configure or make time. This approach is Automake-centric, Ralf> but other buildtools can do similar. Sounds sensible to me. People have also asked this to specify --preserve-dup-deps, and --tag=FOO in cases Automake cannot guess it. Let's make it `$(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS)' with `$(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
Re: libtool: unrecognized option `--tag=CC'
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 contain `--tag', Automake outputs --tag only if the libtool.m4 file used supports them. So this indicates mismatch between libtool.m4 and ltmain.sh. ___ http://lists.gnu.org/mailman/listinfo/libtool
GNU Automake 1.9.5 released
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/automake/automake-1.9.5.tar.bz2 ftp://ftp.gnu.org/gnu/automake/automake-1.9.5.tar.bz2.sig ftp://sources.redhat.com/pub/automake/automake-1.9.5.tar.gz ftp://sources.redhat.com/pub/automake/automake-1.9.5.tar.gz.sig ftp://sources.redhat.com/pub/automake/automake-1.9.5.tar.bz2 ftp://sources.redhat.com/pub/automake/automake-1.9.5.tar.bz2.sig Soon it will also appear on the sources and GNU mirrors listed here: http://www.gnu.org/order/ftp.html http://sources.redhat.com/mirrors.html Finally, here are the MD5 checksums: 3a534ad55d781861e1e92d3b8d898a9a automake-1.9.5.tar.bz2 f22b4cabccbb5243092a6d19912cb5fb automake-1.9.5.tar.gz Please report bugs to . Bugs fixed in 1.9.5: * Longstanding bugs: - All m4 files have been relicensed under an all-permissive license. Previously they used a GPL license, and an all-permissive license was prepended when they were copied into aclocal.m4, leading to some confusion. - aclocal now recognizes AU_ALIAS. - Improve support for `make -k', it didn't work on cygwin. - Fix the definition of FCLINK for preprocessed Fortran. - Fixes for auxiliary scripts: - depcomp's tru64 mode did not work while compiling libtool libraries with static libraries disabled. - mdate-sh now copes with Darwin's non-standard ls output. - missing properly emulates makeinfo when neither -o nor @setfilename are used. - Don't output long variable definitions. Automake normally tries to output variable definitions as they are input, bug very long lines in Makefile.in can break some sed and make implementations with a limited line length. If a line in a variable definition is longer than 1000 characters, automake will wrap the definition around 80 columns. Other definitions are still output untouched. * Noteworthy manual updates: - Hard-Coded Install Paths: New FAQ entry. - How the Linker is Chosen: Rewritten. pgptJ5Xqa6t4C.pgp Description: PGP signature ___ http://lists.gnu.org/mailman/listinfo/libtool
