Re: GNU Coding Standards, automake, and the recent xz-utils backdoor
[adding in coreutils, for some history] On Sat, Mar 30, 2024 at 12:55:35PM -0400, Eric Gallager wrote: > I was recently reading about the backdoor announced in xz-utils the > other day, and one of the things that caught my attention was how > (ab)use of the GNU build system played a role in allowing the backdoor > to go unnoticed: https://openwall.com/lists/oss-security/2024/03/29/4 I'm also wondering whether the GNU system should recommend using zstd instead of or in addition to xz for compression purposes. Automake gained support for dist-zstd back in 2019 [1], but I'm not sure how many projects are using it yet. [1] https://git.savannah.gnu.org/cgit/automake.git/commit/?id=5c466eaf Furthermore, I was around when GNU Coreutils kicked off the initial push to support dist-xz (initially named dist-lzma, before a change in upstream [2]) because of its benefits over over dist-bz2 (compresses smaller, decompresses faster) [3][4], and even when it ditched dist-gzip leaving dist-xz as its ONLY release option [5][6], before needing to be reinstated for bootstrapping Guix [7][8]. [2] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b52a8860 [3] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=b75e3b85 [4] https://lists.gnu.org/r/bug-coreutils/2007-10/msg00165.html [5] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=e1c589ec [6] https://lists.gnu.org/r/coreutils/2011-10/msg0.html [7] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=516cdf38 [8] https://lists.gnu.org/r/coreutils/2020-02/msg00042.html At any rate, it is now obvious (in hindsight) that zstd has a much larger development team than xz, which may alter the ability of zstd being backdoored in the same way that xz was, merely by social engineering of a lone maintainer. It is also obvious that having GNU distributions available through only a SINGLE compression format, when that format may be vulnerable, is a dis-service to users when it is not much harder to provide tarballs in multiple formats. Having multiple tarballs as the recommendation can at least let us automate that each of the tarballs has the same contents, although it won't make it any more obvious whether those contents match what was in git (which was how the xz backdoor got past so many people in the first place). -- Eric Blake, Principal Software Engineer Red Hat, Inc. Virtualization: qemu.org | libguestfs.org
Re: Relative path without realpath
On 10/9/20 10:46 AM, Cristian Morales Vega wrote:
> I would like to send some patches making pkg-config files relocatable.
> pkg-config offers the "pcfiledir" variable to do this.
> The thing is that I need to be able to obtain prefix, libdir,
> includedir, etc. relative to the directory where the .pc file gets
> installed. I can easily do this with realpath, from coreutils, but
> it's not POSIX and I'm not sure people will accept such a dependency.
> The use of automake per se has no dependency to coreutils, does it?
>
> There is any way to obtain the path of one directory relative to
> another in automake without adding a new dependency? "realpath"
> implemented as a m4 macro, maybe?
https://stackoverflow.com/questions/2564634/convert-absolute-path-into-relative-path-given-a-current-directory-using-bash
suggests that it can be scripted in portable shell (although I did not
test if it has odd corner cases when one or the other input contains
things like foo/../bar or symlinks):
#!/bin/sh
relpath () {
[ $# -ge 1 ] && [ $# -le 2 ] || return 1
current="${2:+"$1"}"
target="${2:-"$1"}"
[ "$target" != . ] || target=/
target="/${target##/}"
[ "$current" != . ] || current=/
current="${current:="/"}"
current="/${current##/}"
appendix="${target##/}"
relative=''
while appendix="${target#"$current"/}"
[ "$current" != '/' ] && [ "$appendix" = "$target" ]; do
if [ "$current" = "$appendix" ]; then
relative="${relative:-.}"
echo "${relative#/}"
return 0
fi
current="${current%/*}"
relative="$relative${relative:+/}.."
done
relative="$relative${relative:+${appendix:+/}}${appendix#/}"
echo "$relative"
}
relpath "$@"
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: A new, novel, and faster Binary Search algorithm
On 3/15/19 6:16 AM, Gregorius van den Hoven wrote: > My apologies. The algorithm is licensed under GPL 3 so it seemed relevant > to the GNU community to me. Do you have a suggestion for a more appropriate > mailing list? Perhaps GNU coreutils (coreut...@gnu.org), as the owner of the sort(1) utility, which would be the most likely program to pick up the use of this code? Or to glibc, to see if it is worth improving qsort() by using the ideas in your algorithm? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: AC_ARG_ENABLE and checking for unrecognized switches
On 3/14/19 10:56 PM, Kip Warner wrote: > Hey list, > > I use AC_ARG_ENABLE to create a number of different --enable switches. > I noticed when I accidentally mistyped the in --enable- > , ./configure didn't bail on the unrecognized switch. This is by design; the GNU Coding Standards wants projects to be aggregatable, such that someone else could write a larger project that uses yours as a subdirectory, and takes additional --enable switches that some (but not all) of its subprojects understand. Being able to blindly pass down all of its switches to subprojects, without having to worry about which projects care about which switches, makes this easier. > > Is there something I need to add to configure.ac in order to get it to > do this? Unfortunately, since it is by design that unknown --enable arguments are ignored, I don't know of a handy way to switch that behavior to warn or fail instead. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: autoreconf doesn't follow includes.
Adding the automake list, since that is the impacted project: On 2/21/19 1:05 PM, Carlo Wood wrote: > Hi, > > I'm using a Makefile.am that has an include, like so: > > ---begin of Makefile.am--- > include $(srcdir)/cwm4/root_makefile_top.am > > SUBDIRS = googletest @CW_SUBDIRS@ src > > include $(srcdir)/cwm4/root_makefile_bottom.am ---end of Makefile.am > ---end of Makefile.am > > I do this because every project that I have is the same, except for > SUBDIRS :p. > > This works fine with all autotools except autoreconf; > for example > > sean:~/projects/aicxx/ai-evio-testsuite/ai-evio-testsuite>autoreconf -v -i -s > --no-recursive > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal > > which is wrong because autoreconf ignores the line > > ACLOCAL_AMFLAGS = -I cwm4/aclocal -I m4/aclocal > > in $(srcdir)/cwm4/root_makefile_top.am > > See https://www.gnu.org/software/automake/manual/html_node/Include.html > why this is legal usage of automake. Makefile fragments are valid, but it is not immediately obvious if makefile fragments are allowed to have ACLOCAL_AMFLAGS that affect the overall file, or if it is better to put ACLOCAL_AMFLAGS directly in the primary file rather than hidden in an include file. At any rate, if automake is happy finding that definition after chasing through includes, I'm happy to accept a patch to autoreconf to do similar chasing when building the command line to pass to automake, but I'm not sure how easy it would be for me to write the patch myself. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org
Re: autoreconf and depcomp
On 2/2/19 12:18 AM, bill-auger wrote: > when i run `autoreconf -ivf` and a 'depcomp' already file exists, > 'depcomp' gets added to 'am__DIST_COMMON' in ./Makefile.in - but when i > run `autoreconf -ivf` and the 'depcomp' file does not exist, it is > recreated automatically but is not added to 'am__DIST_COMMON' > > can someone advise me if i should be concerned about this quirky > behavior The contents of the generated Makefile.in result from Automake; so even though autoreconf belongs to Autoconf, any fix to this issue will have to come from a patch to Automake. Updating mail distribution accordingly. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3226 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Libguestfs] [nbdkit PATCH] build: Install ocaml files relative to --prefix
[adding the automake list, in case someone has advice] On 12/7/18 4:22 PM, Richard W.M. Jones wrote: On Fri, Dec 07, 2018 at 03:09:43PM -0600, Eric Blake wrote: Rather than always trying to install ocaml files into $(OCAMLLIBS), which is likely to be root-owned and therefore fail during a './configure --prefix=$HOME/subdir', we instead choose to always install relative to $(prefix) and let distro packagers take steps post-install to move the distro's pre-built copy into the correct location for the distro. This fixes a 'make distcheck' failure. Signed-off-by: Eric Blake --- plugins/ocaml/Makefile.am | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/plugins/ocaml/Makefile.am b/plugins/ocaml/Makefile.am index b95f255..bbde5e1 100644 --- a/plugins/ocaml/Makefile.am +++ b/plugins/ocaml/Makefile.am @@ -39,7 +39,7 @@ EXTRA_DIST = \ if HAVE_OCAML -ocamllibdir = $(OCAMLLIB) +ocamllibdir = $(libdir)/ocaml ocamllib_DATA = NBDKit.mli NBDKit.cmi NBDKit.cmx NBDKit.o NBDKit.cmi: NBDKit.mli I'm actually one of the authors of m4/ocaml.m4. Could that file be fixed to provide a better $(OCAMLLIB)? No. You _can't_ change $(OCAMLLIB) directly, because it is used for more than just an installation location (I tried, and then compilation started failing when it couldn't find ocaml-specific .h files). The problem is tying ocamllibdir to $(OCAMLLIB), not $(OCAMLLIB) itself. I suspect however the answer will be no. Because what we're really getting is the output of ‘ocamlc -where’. Unfortunately if people are using the opam package manager which installs OCaml in your home directory then ‘ocamlc -where’ will be some directory under $HOME and entirely unrelated to $(libdir). Thus I think this patch won't work ... It's a classic problem - if our package wants to install add-ins usable by a third-party, asking the third party where it was installed does NOT mean that WE can install in the same place. And most packages haven't figured out that making it easy to ask 'where should I install MY add-ons so that they can then be easily linked into your project as third-party addons' is a much different question than 'where do you load your third-party addons from'. If it were a standard FHS location, the GNU Coding Standards might have recommended an approach of './configure --ocamldir=...', but that doesn't scale to every possible combination of packages that want to install 3rd-party modules usable by other packages. I'm not upset if this patch doesn't go in, but if it doesn't, I'm stumped at how to get 'make distcheck' to work around the problem of skipping installation to an absolute directory outside of --prefix. Again, I think it's nicer to have './configure --prefix=$HOME/subdir; make; make install' install everything locally, and then follow up as needed with a post-install action to move (or copy/symlink/install) 3rd-party modules from there into their final useful location (creating an .rpm or .deb would be the typical place to do such scripting when building the package in a form intended to be shipped as part of a distro). What's annoying about this is that we DO honor $(DESTDIR), which is great for working around attempts to install into a root-owned directory; but DESTDIR installs are not the same as --prefix=$HOME/user installs. Maybe if there were some way to automate a mode where anything starting with --prefix is installed normally, but anything with an absolute name is installed via DESTDIR, all on the same 'make install' run, and then check that the union of those two install locations makes sense. But that would be a new automake feature, and no telling how long it would take before packages can rely on distros shipping an automake that new. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: if-else if condition in Makefile.am
On 11/28/18 7:08 PM, Deepa Ballari wrote: Hello, How do I write if-else-if condition (or nested if condition) in Makefile.am? Code: if NEWLIB_NANO_FORMATTED_IO LIBADD_OBJS = \ $(lpfx)nano-vfprintf_float.$(oext)\ $(lpfx)nano-svfprintf.$(oext)\ .. else if NEWLIB_FORMATTED_IO LIBADD_OBJS = \ $(lpfx)newlib-vfprintf.$(oext) $(lpfx)newlib-vfprintf_longdouble.$(oext) \ else LIBADD_OBJS = \ .. $(lpfx)svfiwscanf.$(oext) $(lpfx)svfwscanf.$(oext) \ $(lpfx)vfiwscanf.$(oext) $(lpfx)vfwscanf.$(oext) endif if NEWLIB_NANO_FORMATTED_IO LIBADD_OBJS = ... else !NEWLIB_NANO_FORMATTED_IO if NEWLIB_FORMATTED_IO LIBADD_OBJS = ... else !NEWLIB_FORMATTED_IO LIBADD_OBJS = ... endif !NEWLIB_FORMATTED_IO endif !NEWLIB_NANO_FORMATTED_IO You just have to nest things on separate lines, with one endif per if/[else]. The comments after else and endif are optional, but I find they make it a lot easier to reason about things when dealing with nested conditionals. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: automatically showing test-suite.log on failure?
[adding autoconf, as this also affects testsuite.log generated by
projects using autotest instead of automake's built-in support]
On 9/21/18 12:37 PM, Bob Proulx wrote:
Bob Friesenhahn wrote:
Karl Berry wrote:
However, this seems like it would be fairly commonly useful and easy
enough to do in the canonical test-driver script. So, any chance of
adding it as a standard feature? Any reasonable way of enabling it would
be fine, e.g., a flag that can be added to [AM_]LOG_DRIVER_FLAGS.
Take care since some test logs could be megabytes in size.
I want to put a point in that often users try to be helpful and email
that multi-megabyte log file as an email attachment to bug reporting
mailing lists that sometimes have a lot of subscribers. This is very
painful on the network bandwidth usage. And also every downstream
subscriber, perhaps on a metered cell modem data plan, pays the cost
of receiving it whether they can help with it or not.
If there is some way, clever or not, to encourange the user to
compress that log file before attaching it that would save a lot of
downstream pain. When compressed that log file is a small fraction of
the original size and rarely a problem.
Just mentioning it to keep it in the brain cache when thinking about
improvements here. :-)
Indeed - I almost wonder if it would be worth patching the sequences
that generate testsuite.log to automatically generate a compressed
version in parallel, and in the output when a test fails, mention that
the user may inspect testsuite.log but should email the compressed
testsuite.log.XYZ to the developer. Determining the best compression
program to recommend is interesting - if the user is testing a package
that shipped only as foo.tar.xz, then testsuite.log.xz makes the most
sense to generate; but if foo ships both foo.tar.gz and foo.tar.xz, it
is not obvious which form the user uncompressed and would require a
configure or runtime probe for which compression engine to attempt.
If nothing else, autoconf should be patched where it states:
echo
if $at_debug_p; then
at_msg='per-test log files'
else
at_msg="\`${at_testdir+${at_testdir}/}$as_me.log'"
fi
AS_ECHO(["Please send $at_msg and all information you think might help:
in lib/autotest/general.m4, to mention the recommendation for compression.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
Re: copyright problem with install-sh, request for clean-room rewrite
On 09/03/2018 10:35 AM, Thomas Dickey wrote: On Mon, Sep 03, 2018 at 09:13:13AM -0500, Eric Blake wrote: ... Note that the most recent version of 'install-sh' as installed by Automake states: # Copyright (C) 1994 X Consortium looking at my collection of untarred X sources, there's an issue with that: Thanks for digging up more history. With all that, the available information shows that someone "fixed" things in the early 2000s by adding a copyright date to address the derived work. Git blame points to Automake commit 7bb3bbe6e: commit 7bb3bbe6e2560604a2f925fec6ff7b4afd74e180 Author: Alexandre Duret-Lutz Date: Fri May 9 17:58:21 2003 + * lib/install-sh: Update copyright notice and license to that of X11R6. This removes an advertising clause reported as Debian bug #191717. http://bugs.debian.org/191717 is an interesting read, pointing out that versions of automake prior to that point had: -# Copyright 1991 by the Massachusetts Institute of Technology -# (FSF changes in the public domain.) [with an advertising clause] before what now reads as: +# Copyright (C) 1994 X Consortium [with no advertising clause] In turn, that copyright line first appeared in commit 4314bddf in Jul 1996, prior to which point it was indeed shipped without a copyright line. Perhaps autoconf's source repo has additional information. Looking there, it has moved over time (from the top level, to config/install-sh, to now build-aux/config.sh). The initial commit there in 1994 indeed had no copyright (see commit 430e0b6), and the MIT copyright notice was added in Jul 1996 (commit ce6c1f20) - looks like autoconf and automake were kept relatively close in sync at that time, and only later with commit 383913b4 in Sep 1998 did autoconf start syncing install-sh from a different location rather than maintaining it in parallel with automake. As is, the copyright was apparently not applied by the owner of the file. So the sentence in the autoconf manual was, at least at one point in history, correct about the file not carrying a copyright; but is now out of date based on what subsequent modifications have pulled in (although tracking actual copyright may be a lot harder than just doing a clean-room rewrite). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: copyright problem with install-sh, request for clean-room rewrite
On 09/03/2018 01:24 PM, Paul Eggert wrote:
Mathieu Lirzin wrote:
According to ‘git blame’ I appear to not have touch this file, so if you
think that I am eligible, I am volunteering on this rewriting task.
Thanks for volunteering.
Indeed, and I think you are reasonably safe for the task.
Eric, do you think it would save time overall
if you sent him the part of install-sh that you are sure is *not*
problematic, i.e., the part that is already copyright by the FSF? That's
typical procedure in a cleanroom rewrite of anything large; dunno if
it's overkill here.
One thing that is for certain copyright by the FSF is the fact that
'install-sh --help' outputs a useful summary (as the original install-sh
merely reports "install: --help does not exist"). So here's a nice
starting point:
$ lib/install-sh --help
Usage: lib/install-sh [OPTION]... [-T] SRCFILE DSTFILE
or: lib/install-sh [OPTION]... SRCFILES... DIRECTORY
or: lib/install-sh [OPTION]... -t DIRECTORY SRCFILES...
or: lib/install-sh [OPTION]... -d DIRECTORIES...
In the 1st form, copy SRCFILE to DSTFILE.
In the 2nd and 3rd, copy all SRCFILES to DIRECTORY.
In the 4th, create DIRECTORIES.
Options:
--help display this help and exit.
--version display version info and exit.
-c(ignored)
-Cinstall only if different (preserve the last data
modification time)
-dcreate directories instead of installing files.
-g GROUP chgrp installed files to GROUP.
-m MODE chmod installed files to MODE.
-o USER chown installed files to USER.
-sstrip installed files.
-t DIRECTORY install into DIRECTORY.
-Treport an error if DSTFILE is a directory.
Environment variables override the default commands:
CHGRPPROG CHMODPROG CHOWNPROG CMPPROG CPPROG MKDIRPROG MVPROG
RMPROG STRIPPROG
Other black-box testing that I can readily describe is based on how
automake uses the script (as those are the command line invocations that
must work; it may be easier to start with a rewritten script that is
less full-featured than what the current one does, as long as it
provides everything that automake actually uses it for):
install_sh_DATA = $(install_sh) -c -m 644
install_sh_PROGRAM = $(install_sh) -c
install_sh_SCRIPT = $(install_sh) -c
...
mkinstalldirs = $(install_sh) -d
...
INSTALL_STRIP_PROGRAM = $(install_sh) -c -s
...
-test -n "$(am__skip_mode_fix)" \
|| find "$(distdir)" -type d ! -perm -755 \
-exec chmod u+rwx,go+rx {} \; -o \
! -type d ! -perm -444 -links 1 -exec chmod a+r {} \; -o \
! -type d ! -perm -400 -exec chmod a+r {} \; -o \
! -type d ! -perm -444 -exec $(install_sh) -c -m a+r {} {} \; \
|| chmod -R a+r "$(distdir)"
...
install-strip:
if test -z '$(STRIP)'; then \
$(MAKE) $(AM_MAKEFLAGS)
INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)"
INSTALL_STRIP_FLAG=-s \
install; \
else \
$(MAKE) $(AM_MAKEFLAGS)
INSTALL_PROGRAM="$(INSTALL_STRIP_PROGRAM)" \
install_sh_PROGRAM="$(INSTALL_STRIP_PROGRAM)"
INSTALL_STRIP_FLAG=-s \
"INSTALL_PROGRAM_ENV=STRIPPROG='$(STRIP)'" install; \
fi
...
Comparing to GNU coreutils, which also ignores -c, I have no idea why
Automake's snippets that use $(install_sh) pass -c; and while I see a
definite use of -d, -m, -s, and $STRIPPROG, I don't see an obvious use
of -g, -o, -C, or some of the other environment variables, at least for
what automake itself expects to exist (although it's harder to predict
what functionality other projects have come to rely on in their
Makefile.am usage of install-sh).
I also note that 'lib/mkinstalldirs' has a different copyright/license
(namely, "Public domain"), where I don't know if we need to rewrite that
one as well; and find it odd that we also have a line in generated
Makefiles that uses 'install-sh -d' in place of mkinstalldirs. It may
make sense to have automake quit shipping mkinstalldirs, and merely rely
on $(MKDIR_P) and/or 'install-sh -d', for one less helper script
installed by automake.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3266
Virtualization: qemu.org | libvirt.org
copyright problem with install-sh, request for clean-room rewrite
can now review which lines remain unchanged from our original copy into the current age, and see that it is mostly comments or bare control flow, which on its own doesn't do much: $ git diff -w -b 042e80a712..HEAD lib/install-sh | sed 's/^[^ ].*//' | cat -s #!/bin/sh # install - install a program, script, or datafile # # Calling this script install-sh is preferred over install.sh, to prevent # when there is no Makefile. # # This script is compatible with the BSD install script, but was written # from scratch. rmcmd="$rmprog -f" case $1 in -g) chgrpcmd="$chgrpprog $2" shift fi esac done exit 1 else fi dst=$src else # might cause directories to be created, which would be especially bad # if $src (and thus $dsttmp) contains '*'. exit 1 fi exit 1 else fi else fi shift else fi done fi fi # If any of these fail, we abort the whole thing. If we want to # ignore errors from any of these, just make sure not to ignore # Now rename the file to the real destination. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: automake compile problems
On 05/30/2018 02:23 PM, Andy Armstrong wrote: Hi Eric, [top-posting is a bit harder to read on a technical list, so I'll stick with the easier-to-read inline posting] That could well be a far better approach. I am not sure how to perform cross platform builds, especially taking into account the interesting platform uniqueness such as codepage etc. I'm not proposing cross-building (which is indeed a possibility, but a much more technically challenging one to get correct, so it's never my first suggestion), so much as having two machines: - development machine: has autotools installed, has nano.git [https://git.savannah.gnu.org/cgit/nano.git] checked out (or however you are currently trying to build the latest nano); probably GNU/Linux, and most likely using ASCII encoding - build machine: your mainframe with EBCDIC encoding On the development machine, run all of the prep steps, including any required 'autoconf' and 'automake' steps, prior to './configure && make dist', which creates nano-$vers.tar.$suff (where $suff is typically .gz or .xz, depending on what compression the developers liked) Then copy nano-*tar* file to the build machine (whether by ftp, or by a shared network drive, or by whatever other means you have at your disposal) Then on the build machine, unpack the tarball (perhaps involving some dd invocations to transliterate from ASCII to EBCDIC as needed - but do so in a manner which preserves timestamps - I honestly don't know what steps are required in transferring an ASCII-encoded tarball into use on an EBCDIC machine) Now, on the build machine, you only have to type './configure && make'; you don't have to run autoconf or automake (well, as long as you didn't mess up timestamps such that make thinks configure.ac is newer than configure, or some similar spurious change in dependency). In fact, the parts about the development machine have often already taken place without requiring you to anything: https://ftp.gnu.org/gnu/nano/ includes nano-2.9.7.tar.xz, which was built precisely in the same manner that you would build it, by a developer who had autotools on their machine and ultimately ran 'make dist'. So, rather than building from nano.git, just build the pre-built tarball. I have not used the 'make dist' argument before, but it would prerequisite that I chose the appropriate configure and make arguments to compile for the platform I am targeting.thoughts? 'make dist' is SUPPOSED to produce an idempotent and complete tarball (modulo noise like changes in timestamps), independent of what configure options you used (if it doesn't, that's a bug in the particular package you are trying to build). 'make distcheck' tries to check that this is actually the case, by forcefully creating a tarball, faking a PATH with no autotools, and performing a VPATH build from the tarball, to exercise what an end user without autotools is likely to encounter (not all developers use 'make distcheck' the way they should, but it's part of the GNU Coding Standards, and automake tries to promote it for developers). I am not even sure of the official 'name' of the system I am targeting? s390? omvs? To be clear, I am targeting USS on zSystems, not Linux on z. Thoughts? Best practices? Running config.guess (which is included in many different tarballs, again because automake finds it useful) should give the 'official' name of your system, at least in terms that the autotools cater to. Admittedly, very few people use USS on zSystems while ALSO trying to use lots of GNU software, so it's highly likely that you have a LOT of non-portable assumptions to overcome when porting open source software to your platform (such as the 10-year-old autoconf bug you just reported, where we regressed from something that worked to something that tickles a latent bug in m4's eval that has been present even longer). And actually fixing those bugs may require patching configure.ac or Makefile.am, at which point the 2-machine approach requires making the tweak, rerunning 'make dist', and copying over the new tarball for each tweak you want to test. But having the separation between devel and build machine, even if it involves a lot of iterative copying, may still be easier than trying to have the build machine BE the development machine, where you have to get an entire ecosystem of software running before you can directly build from git instead of from tarballs. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: automake compile problems
On 05/30/2018 11:12 AM, Andy Armstrong wrote: To give some context to what I am doing, here is the timeline: I did have Automake version 1.10, but my ultimate goal here is to compile the nano text editor, which requires at least automake 1.15 and autoconf 2.69. That's if you are modifying the source files and actually developing nano on your mainframe. But what's wrong with the (often simpler) approach of using a more typical development box, probably using GNU/Linux, with modern autotools already installed, and running 'make dist' on the nano package there, then copying the tarball over? Once you've done that, './configure && make' should work without requiring either automake or autoconf installed on the mainframe. After all, the point of the autotools is to build self-contained tarballs that no longer require the presence of the autotools. -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: automake compile problems
On 05/30/2018 04:07 AM, Andy Armstrong wrote: Hi all, I want to compile version 1.16 of automake. On which system? I run ./configure, which creates the Makefile. I run 'make' which results in the following: automake-1.16: >make make: Makefile: line 3012: Warning -- FSUM9432 Duplicate entry [t/get-sysconf.sh] in target list That's not GNU make. What version and vendor of make is it? It may mean that automake has regressed, and is no longer outputting makefiles that are portable to your specific make binary. But that's just a warning. Is there an actual failure? make: Makefile: line 3189: Warning -- FSUM9433 Duplicate entry [lib/ylwrap] in prerequisite list @rm -f ./m4/amversion.m4-t ./m4/amversion.m4 make: Error -- @rm: EDC5129I No such file or directory. FSUM8226 make: Error code -1 Okay, that's an actual failure, but it's not obvious on what the context is that might have caused it. Is there an earlier version of automake that built on your platform? Does using GNU make instead of your vendor's default make let you get further? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org
Re: Which files to distribute?
On 01/29/2018 08:11 PM, Victor Porton wrote: > Which of the following files should be uploaded to Git? It depends. Do you want git to track generated files, at the risk of different installed autotools versions creating spurious diffs in those generated files? I don't personally recommend that, but some people like to have their git repo usable even by someone that does not have the autotools installed. Or do you want to require someone checking out the git repo to have tools installed on their machine that the end user client of a tarball does not have to have? > > aclocal.m4 Generated. > autogen.sh Not necessarily the best name (since there is an unrelated GNU Autogen project); some projects prefer the name bootstrap for this sort of script instead of autogen.sh. At any rate, this script is NOT generated by the autotools, so you probably need to check it into git (especially if its goal is to run the autotools to bring a git checkout into a state that you can then run the usual ./configure && make). > compile > config.guess > config.sub > configure > depcomp All generated. > INSTALL If you don't check this in, then you get the default version generated that talks about GNU standards. Which may be fine for your project, or it may be inaccurate; if you check in your own version, automake will leave your version intact. > install-sh > libtool > ltmain.sh > missing All Generated. So of those, I'd only check in autogen.sh (and consider renaming it). However, your subject line said "Which files to distribute", not "Which files to store in version control". The answer there is "All of them" - and automake will automatically distribute all of those files in a tarball when you do 'make dist' (and you can run 'make distcheck' to make sure your tarball is self-contained). -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: Warning - non-POSIX variable name
On 08/09/2017 12:02 PM, Warren Young wrote: > On Aug 9, 2017, at 9:00 AM, Bob Friesenhahn > wrote: >> >> Passing a relative path to CC seems error prone since it only applies to the >> current working directory and will fail as soon as any Makefile recurses. > > Maybe you have a better answer to this related question: is there a portable > alternative to GNU readlink’s -f option? > > On a Linux box, I’d get around the problem you raise with: > > $ ./configure CC=$(readlink -f > ../../llvm-arm-toolchain-ship/3.8/bin/clang) Why not just: ./configure CC="$PWD/../../llvm-arm-toolchain-ship/3.8/bin/clang" which turns your relative name into an absolute one? Do you HAVE to have the canonical name? -- Eric Blake, Principal Software Engineer Red Hat, Inc. +1-919-301-3266 Virtualization: qemu.org | libvirt.org signature.asc Description: OpenPGP digital signature
Re: Defining data files to install
On 01/26/2017 03:22 PM, Julie Marchant wrote: > Hi, > > I'm a little confused about how to set up Autoconf to install data files > for the program to use later, and I wondered if someone can clear up my > confusion. > > For reference, the pertinent program is Project: Starfighter: > > http://starfighter.nongnu.org > > Starfighter has a few different directories with required data files: > "data", "gfx", "music", and "sound". All files in these directories need > to be installed to a location that gets defined as DATADIR. From what I > understand so far, the directory I want to use is the one stored in the > pkgdatadir variable, and I include files to install there by assigning > them in a Makefile.am to pkgdata_DATA. But listing the files out from a > Makefile.am in the same directory doesn't copy the directory structure, > and if I indicate a directory from the top-level Makefile.am, "make > install" just ignores (or rather, "omits") it and then spits out an > error with no accompanying information. Makefile.am is read by automake, so your question is more likely to be answered in the automake manual than the autoconf manual. > > What am I missing here? How can I install these data files not into the > top-level pkgdatadir, but in the respective appropriate sub-directories > of pkgdatadir (e.g. "$(pkgdatadir)/data" and "$(pkgdatadir)/music")? I > can't find any documentation on how to do this anywhere. Automake lets you define new targets that are subdirectories. In fact, a quick search for $(pkgdatadir) found an example that might be pertinent to your use case: https://www.gnu.org/software/automake/manual/automake.html#Alternative But I'm not as good at automake as I am at autoconf, so I'm cc'ing that list in, in case someone else has more ideas. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Words in configure.ac that look like macros forbidden or merely discouraged?
On 06/12/2016 05:25 AM, Gavin Smith wrote: > Hello, Apologies for just now noticing this thread. > > In the Autoconf manual we read: Any reason you mailed this to the automake list, and not autoconf, then? > > > > When you use the same text in a macro argument, you must therefore > have an extra quotation level (since one is stripped away by the macro > substitution). In general, then, it is a good idea to use double > quoting for all literal string arguments, either around just the > problematic portions, or over the entire argument: > > AC_MSG_WARN([[AC_DC] stinks --Iron Maiden]) > AC_MSG_WARN([[AC_DC stinks --Iron Maiden]]) > > > Note what it says: "triggers a warning". However, it seems in some > cases, using a word that looks like it could be a macro triggers a > hard error, not just a warning: > > $ autoreconf -iv > autoreconf: Entering directory `.' > autoreconf: configure.ac: not using Gettext > autoreconf: running: aclocal > configure.ac:4: warning: macro 'AM_DC' not found in library AM_DC is not the name used in the example, but falls into the namespace reserved by automake, so I guess I see why you are testing it instead of AC_DC. > autoreconf: configure.ac: tracing > autoreconf: configure.ac: not using Libtool > autoreconf: running: /usr/bin/autoconf > configure.ac:4: error: possibly undefined macro: AM_DC > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > autoreconf: /usr/bin/autoconf failed with exit status: 1 However, the error message says that it is autoconf (not automake) that is failing, so I don't see how this is applicable to automake. > > Any ideas which it is: is it actually forbidden, or should it be just a > warning? So I guess you are pointing out a documentation error in the autoconf manual, and that the manual should call it an error, not a warning? Sure, I can do that. > > I intend to put information about this here: > http://buildsystem-manual.sourceforge.net/Macro-name-quoting.html#Macro-name-quoting > , which I've adapted from the test in the automake manual. > > Contents of files: > > $ cat configure.ac > AC_INIT([helloprog], [1.0]) > AM_INIT_AUTOMAKE > > echo AM_DC rocks > > AC_CONFIG_FILES([Makefile]) > AC_OUTPUT > $ cat Makefile.am > AUTOMAKE_OPTIONS=foreign dist-xz > $ > > -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: More control over 'make dist'
[re-adding Michal; not sure he is a subscriber. It's usually best to reply-to-all rather than assume that all readers are on-list] On 09/14/2016 02:10 PM, Warren Young wrote: > On Sep 14, 2016, at 7:49 AM, Peter Rosin wrote: >> >> On 2016-09-14 11:33, Michal Privoznik wrote: >>> >>> ln -s $xml.in $xml.out >>> >>> However, I was looking into archive produced by 'make dist' the other >>> day and found out that the symlinks are not preserved. >> >> I believe that is for the benefit of supporting unpacking the release >> tarball on systems that do not support symlinks, or where symlinks are >> not as flexible as one might wish for. > > The question, then, is whether libvirt would ever be unpacked on such a > system. > > I’m barely aware of what libvirt does, but I think I can come up with a > plausible scenario: libvirt built from source on Cygwin. > > It appears from the home page that libvirt already supports Hyper-V, so a > naive user might decide to build it under Cygwin rather than whatever native > Windows toolchain is currently used for that case. (The reason being that > libvirt, coming from the Linux world, probably builds better under a > Unix-like environment.) Since NTFS symlinks have a number of unfortunate > limitations[1] and restrictions[2], the tarball almost certainly won’t unpack > correctly. Cygwin unpacks and handles symlinks just fine as one of the many things it emulates, so that's not the issue (note, however, that non-cygwin apps are generally unable to recognize cygwin symlinks, which are intentionally NOT done as NTFS symlinks because NTFS symlinks are not POSIXy). I'd be more worried if trying to unpack libvirt and build it with mingw, where you no longer have cygwin symlinks in the mix, and would indeed be limited to just NTFS symlinks. But I think that mingw ports of tar already take care of that, by turning symlinks in the tarball into file copies (where the link target was also in the tarball) or an error message (where the link target is unknown) (although I haven't actually tested what MSYS would actually do, so I welcome further comments from anyone with experience). And yes, libvirt is (cross-)built for mingw on Fedora already, as well as me getting ready to prepare a Cygwin distribution build of libvirt (both for the remote machine control aspect, and for the HyperV aspect). I'm less familiar with cross-building for mingw to know for certain whether symlinks in tarballs cause problems for mingw targets, or whether Wine emulation on Linux even handles symlinks. So that agrees with the notion of making tarballs as portable as possible by avoiding symlinks. On the other hand, maybe the GNU Coding Standards should be updated to state that avoiding symlinks is no longer required of GNU packages (it's entirely plausible that when automake first coded up the tar -h rule, years ago, there really were Unixy systems where either the file system or the tar program didn't handle symlinks as gracefully as desired, which is a different beast than today's mingw situation). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: aclocal using automake Automake::XFile
[not really an m4 problem, so future replies can be to just automake]
On 12/08/2015 02:51 AM, Arkadiusz Miśkiewicz wrote:
>
> Hello.
>
> Using
> m4 (GNU M4) 1.4.17
> automake (GNU automake) 1.15
>
> /usr/bin/aclocal contains code:
>
> $traces .= " --language Autoconf-without-aclocal-m4 ";
> $traces = "echo '$early_m4_code' | $traces - ";
> ...
> verb "running $traces $configure_ac";
>
> my $tracefh = new Automake::XFile ("$traces $configure_ac |");
Can you try 'aclocal --verbose', to get the "running ..." output line
produced just before the failed XFile() creation attempt?
>
> which fails here:
> $ cd libgii-2.2.2; LC_ALL=C aclocal
> aclocal: error: cannot open echo 'm4_define([m4_require_silent_probe], [-])'
> |... --trace='AM_AUTOMAKE_VERSION:$f::$n' configure.ac |: No such file or
> directory
Huh - it sounds like your version of perl is trying to open a literal
file named 'echo ... | autom4te ... autoconf.ac |' , instead of properly
opening a subshell command that feeds echo to autom4te then collects the
output of autom4te (basically, Automake::XFile() is trying to do the
equivalent of a popen() on a shell command).
> Tried small script to reproduce and it also fails:
>
> #!/usr/bin/perl
>
> BEGIN {
> push ( @INC,"/usr/share/automake");
> }
>
> use strict;
>
> use Automake::XFile;
>
> my $traces = "echo 'zupa'";
> my $tracefh = new Automake::XFile ("$traces");
>
> $ LC_ALL=C perl a1.pl
> a1.pl: error: cannot open echo 'zupa': No such file or directory
Not quite the same, if you don't actually have a file named 'zupa'
handy; and particularly since the aclocal usage is trying to use perl's
open("command |") notation, not open("file") notation. Could it also be
a problem with your particular build of perl, or maybe a newer version
of perl has introduced some backwards incompatible change that
autoconf/automake now need to work with?
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: method for altering installation location
On 11/13/2015 12:11 PM, Andy Falanga (afalanga) wrote:
> How does one properly make a build system install to the
> system-preferred locations for 64-bit binaries? I'm wondering how to
> properly make my build system choose "/usr/lib64" over simply "/usr/lib"
> when configure is run. I know this can be done simply via
> "--prefix=/usr --libdir=lib64", and maybe this is what it should be
Yes, that IS the preferred way (although autoconf's config.site can make
it easier). Your configure script should not hard code any knowledge,
rather the user of your configure script should supply their knowledge.
It's also recommended that you convince your distro to install a
/usr/share/config.site file, which is the easiest way to get
'./configure --prefix=/usr' to just do the right things for all the
other variables. Fedora has already done so:
$ rpm -qf /usr/share/config.site
autoconf-2.69-20.fc22.noarch
$ cat /usr/share/config.site
# This is the config.site file to satisfy FHS defaults when installing below
# /usr.
#
# You may override this file by your config.site using the CONFIG_SITE env
# variable.
#
# Note: This file includes also RHEL/Fedora fix for installing libraries
into
# "/lib/lib64" on 64bit systems.
if test -n "$host"; then
# skip when cross-compiling
return 0
fi
if test "$prefix" = /usr \
|| { test "$prefix" = NONE && test "$ac_default_prefix" = /usr ; }
then
test "$sysconfdir" = '${prefix}/etc' && sysconfdir=/etc
test "$sharedstatedir" = '${prefix}/com' && sharedstatedir=/var
test "$localstatedir" = '${prefix}/var' && localstatedir=/var
ARCH=`uname -m`
for i in x86_64 ppc64 s390x aarch64; do
if test $ARCH = $i; then
test "$libdir" = '${exec_prefix}/lib' &&
libdir='${exec_prefix}/lib64'
break
fi
done
fi
> (along with some type of bootstrap script). I was just wondering if
> there are already elegant/"smiled upon" methods for doing this in
> configure (i.e. configure.ac).
There's nothing for you to do in configure.ac (that doesn't scale -
you'd have to modify every packages' configure.ac to get them to all act
the same). Rather, the work should be done by whoever wants
installation of things into /usr to just work.
See also the autoconf manual:
https://www.gnu.org/software/autoconf/manual/autoconf.html#Site-Defaults
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: What is minimum set of Automake work files needed for distribution on github?
On 09/28/2015 04:20 AM, Robert Parker wrote: > I need to meet the requirements of 2 sets of users, the ordinary user who > is only interested `./configure; make; make install` and the power users > who want to start with `autoreconf`. > > So far google search on the topic has only increased my confusion. The most common solution: don't store anything but configure.ac and Makefile.am in git. The power user checks out git, and runs 'autoreconf' to bootstrap the project, then runs 'make dist' to create a self-contained tarball. The ordinary user takes a tarball, unpacks it, and runs './configure; make; make install' without needing any autotools installed. Ordinary users therefore do NOT use direct git checkouts. Working with git is reserved for power users. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: How can I pass $@ to Makefile?
On 05/28/2015 02:41 PM, Arthur Schwarz wrote: > > So let's try this with your make rule. The lines starting with a > "+" character are the actual commands being executed by the shell: > > % make SHELL='sh -x' test3.abc > echo '#!/bin/bash' > test3.abc > + echo '#!/bin/bash' > echo "echo test3.abc $# ' [' $@ ']'>> test3.log" >> test3.abc This is what make passed to the shell... > + echo 'echo test3.abc 0 '\'' ['\'' '\'']'\''>> test3.log' ...and this is what the shell executed, after doing shell expansions. > echo "echo I am a test script>> test3.log" >> test3.abc > + echo 'echo I am a test script>> test3.log' > > (to get snarky) I saw the problem before. The issue is that the $#/$@ > expands inside make (when test.abc: is executed and not in the shell script. > I can do this if I put the script into the appropriate directory and take > creation out of Makefile.am. I know this. I just wish there was another way. No, $# did NOT expand inside make, but inside the shell that make was running when asked to execute the commands that will create test3.abc. You were not using correct shell quoting. It sounds like you want to defer expansion of $@ not only in make, but also in the shell that make runs. Let's look more closely at your attempt: echo "echo test3.abc $# ' [' $@ ']'>> test3.log" >> test3.abc says to do shell interpolation of $# and $@ inside the double quotes, then append the resulting string to test3.abc. After executing that statement in shell, the last line in test3.abc will be: echo test3.abc 0 ' [' ']'>> test3.log Whereas if you had used different quoting, as in: echo 'echo test3.abc $# " [" $@ "]">> test3.log' >> test3.abc so that you were telling the shell to NOT interpret $, then the last line in test3.abc will be: echo test3.abc $# " [" $@ "]">> test3.log Of course, that is still underquoted, if you intend to avoid globbing/splitting on the results of $@ when executing the file test3.abc. You want the $@ to be inside double quotes. Ultimately, it sounds like you are not quite sure of how many layers of processing text will go through. So let's work backwards: First, figure out what you want in the file test3.abc. Probably something like this (and note that things are a lot easier by avoiding ' in this script): #!/bin/bash echo test3.abc "$# [ $@ ]">> test3.log echo I am a test script >> test3.log Next, figure out how to generate test3.abc using shell scripting (note that I'm using '' quoting here to suppress all expansions in the text being put in the generated file, which is why I avoided ' in the script I am generating): echo '#!/bin/bash' > test3.abc echo 'echo test3.abc "$# [ $@ ]">> test3.log' >> test3.abc echo 'echo I am a test script >> test3.log' >> test3.abc Finally, write that shell script inside a make rule (make passes everything to shell except for $, which is escaped by adding another $): test3.abc: echo '#!/bin/bash' > test3.abc echo 'echo test3.abc "$$# [ $$@ ]">> test3.log' >> test3.abc echo 'echo I am a test script >> test3.log' >> test3.abc Before you can write effective makefile rules for invoking complicated shell scripting, you first need to know the difference between '' and "" in shell quoting rules, and practice writing shell scripts that generate shell scripts to get a feel for using nested layers of quoting when generating files. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: How do you set VERBOSE for parallel testin
On 05/14/2015 08:29 PM, Peter Johansson wrote: > On 05/15/2015 10:36 AM, Arthur Schwarz wrote: >> And, if I guess correctly, the user can write >> "make check TESTSUITEFLAGS=-jN" > > I've never seen TESTSUITEFLAG before, so I don't know. > TESTSUITEFLAGS is the suggested variable name for someone using the 'autotest' setup from autoconf (which is yet another testing framework, different from automake, where automake runs a single test called 'testsuite', but 'testsuite' itself can run multiple tests in series or parallel). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: How do you set VERBOSE for parallel testin
On 05/08/2015 05:13 PM, Arthur Schwarz wrote: >> >> >> On 05/08/2015 04:55 PM, Arthur Schwarz wrote: >>> >>> I just checked the latest iteration of my output listing (VERBOSE = 1) > and >>> saw the rule for >>> Makefile:478 showing test-suite.log failed. Don't know why. >>> >> >> If any test causes a FAIL, XPASS, or ERROR condition, then 'make check' >> will likewise fail. The output from make is telling you that your >> testsuite caught failures that should not be present if the testsuite >> were passing. > > My issue is that the output indicates that the rule for test-suite.log > fails. Is this expected? My thought (from the automake manual) is that even > if there is a failure there should be no difficulty creating or outputting > test-suite.log. The test harness created a test-suite.log (included as an > attachment) but failed to output it. Don't know why. Yes, this is expected. test-suite.log is created no matter what, but the rules associated with creating it fail if the log contains any failure reports, so that make will quit running and let you investigate those failures. As for why test-suite.log was not replayed as part of the make output, I'm not sure that you had VERBOSE=1 set. So far, you've only attached the generated Makefile (but not the source Makefile.am), and didn't show what command you ran. You'll need to make your setup easier for others to reproduce before we can see what you are attempting. As for the test-suite.log not having much output, it is probably because your tests are not very noisy. Running make captured all of the output of your tests, but if your tests didn't output anything, then the log has very little to show. Again, without knowing what your test scripts are doing, it's hard to reproduce your setup. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: How do you set VERBOSE for parallel testin
On 05/08/2015 04:55 PM, Arthur Schwarz wrote: > > I just checked the latest iteration of my output listing (VERBOSE = 1) and > saw the rule for > Makefile:478 showing test-suite.log failed. Don't know why. > If any test causes a FAIL, XPASS, or ERROR condition, then 'make check' will likewise fail. The output from make is telling you that your testsuite caught failures that should not be present if the testsuite were passing. > The output listing is below and the Makefile.am is included in an > attachment. > > Heck, I don't know what I'm doing. If anyone can explain what I need to do > to remove the error messages I'd really appreciate it. Which error messages are you trying to remove? The only error message I say in the output you posted is expected, given that you have a failing test. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: How do you set VERBOSE for parallel testin
On 05/07/2015 03:42 PM, Arthur Schwarz wrote: > I'm trying to set VERBOSE in a parallel test setup and it doesn't seem to > work. I've used: > VERBOSE = yesand > VERBOSE = 1 Where were you making that setting, in Makefile.am? > > But I get the normal output listing. The Automake manual (Section 15.2.3 > Parallel Test Harness) says: " The output from failed tests is collected in > the test-suite.log file. If the variable 'VERBOSE' is set, this file is > output after the summary." It works for me when I do: make check VERBOSE=1 -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: How do you echo a shell variable reference
On 04/13/2015 04:24 PM, Arthur Schwarz wrote:
>
> I am trying to echo:
>echo 'exit $status' >> file
>
> from the Makefile generated by Makefile.am. What I get is:
>echo 'exit $status' >> file
>
> in the Makefile, which is correct, but in execution (make check) I get
>exit tatus
>
> in file. I have tried variations of $status to no avail. Any idea how I can
> get the correct result in file?
The same as any other time you want a literal $ to be passed through to
the shell when writing Makefile snippets: escape the $ with another $,
so that 'make' won't try to treat it as an expansion of ${s} at make time:
foo:
echo 'exit $$status' >> file
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
Re: Question on AM_TAP_AWK
On 04/07/2015 03:30 PM, Arthur Schwarz wrote: > > TEST_LOG_DRIVER = env AM_TAP_AWK='$(AWK)' $(SHELL) \ > $(top_srcdir)/build-aux/tap-driver.sh > > AM_TAP_AWK is defined right there, in the example code. Its purpose is > to tell the tap-driver.sh program which AWK program to use. > > [1] > https://gnu.org/software/automake/manual/automake.html#Use-TAP-with-the-Auto > make-test-harness > > Cheers, > -- Nick Bowler, Elliptic Technologies (http://www.elliptictech.com/) Hey [Your mail client has the horrible habit of breaking threading, as well as doing poor quoting of the text you are responding to. Then the fact that you stuck your entire reply after a '-- ' separator meant that sane mail clients treat your entire content as part of a signature, which means it gets truncated by default; the only way I could reply to your text was to select the entire message before replying, but that in turn triggers a "feature" in my mail client that loses all line breaks in the signature, making this harder to read] > thanks; I guess what your saying is that the variable needs no > definition; it's self-defining. Does this mean that the TAP interface > needs this variable only under some circumstances but not under all? If I understand correctly, you only need to set AM_TAP_AWK in your makefile if you want to allow the user to select a different awk than what a PATH search would normally find, as that is what tap-driver.sh does when the variable is not set. > Since it is self-defined within an example and not in some text which > defines the TAP interface I suppose that it is only required sometimes, > otherwise the TAP interface would have it as part of its description. > I'm also a bit confused about the use of env. Does this use mean that > Makefile evaluates TEST_LOG_DRIVER by escaping to a shell? Otherwise, > does Makefile do it's own interpretation of 'env'? the reason that I'm > asking this question is that on env Cygwin (8.23-4) manual page (and env > --help) shows: SYNOPSIS env [OPTION]... [-] [NAME=VALUE]... [COMMAND > [ARG]...] which seems to imply that either we have NAME=VALUE or NAME=. > The example shows $(SHELL) which has neither of these. I suppose that The example shows that you are executing $(SHELL) as the COMMAND, with the environment variable AM_TAP_AWK pre-set to a value. The use of 'env' allows use with makefiles that default to executing some other shell than 'sh' (most likely to be the case on windows systems, but non-standard behavior since POSIX standardized make to always use sh). > when $(SHELL) is evaluated it produces some variable name (?) but if it > does, how does TAP determine what this name is from the environment? It produces a command name, not a variable name (namely, the command is the shell to use for interpreting the shell script). > Does it search the environment for a fixed set of names and then assume > success at the first one found? Can I supply TAP with a shell whose name > is not one of the fixed set of names? Anyhow, I'm abandoning TAP and > going to try to use the Custom Drivers and hope that if the definitions > are not clearer then at least I can get some sort of test going. If that > doesn't work then I will distribute my software with no testing. Thanks > art The failure of the past is the challenge of the present and the > success of the future. > -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: how should package config files be installed
On 03/31/2015 02:26 PM, Roman Neuhauser wrote: > # ebl...@redhat.com / 2015-03-31 11:40:52 -0600: >> On 03/31/2015 11:25 AM, Andy Falanga (afalanga) wrote: >>> I want to distribute the correct *.pc files with the libraries I'm >>> building. While it's a simple matter to find the format of this >>> file (by examining existing ones or online), I'd like to know if >>> there's a preferred procedure for generating these files. What >>> should be done in order to make this work? >> >> .pc files are created by the pkg-config tool. More details on their web >> site: http://www.freedesktop.org/wiki/Software/pkg-config/ > > i can't find any support for this claim anywhere in that "web site" > (it's a short page). can you be more specific? It's a different project that automake, so you'll probably get better support on the pkg-config mailing list than you will here. But the page I linked to above includes a link to their FAQ: http://people.freedesktop.org/~dbn/pkg-config-guide.html#faq which goes into more details. I have not personally converted a project over to using pkg-config, so I can't provide any better details than "read the manual". -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: how should package config files be installed
On 03/31/2015 11:25 AM, Andy Falanga (afalanga) wrote: > I want to distribute the correct *.pc files with the libraries I'm building. > While it's a simple matter to find the format of this file (by examining > existing ones or online), I'd like to know if there's a preferred procedure > for generating these files. What should be done in order to make this work? .pc files are created by the pkg-config tool. More details on their web site: http://www.freedesktop.org/wiki/Software/pkg-config/ -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Using 'make dist' with a 32 UID
On 01/05/2015 10:30 AM, Finucane, Stephen wrote:
>> On 01/05/2015 03:08 AM, Finucane, Stephen wrote:
>>> Autotools defaults to the 'v7' legacy tar format in GNU tar, through
>> passing of the '-o' parameter to GNU tar. Enabling this option results in
>> errors for users with 32 bit UIDs. For example, with the Open vSwitch
>> package:
>>
>> 'make dist' is under the purview of automake, not autoconf. You may get
>> a better response by involving the automake list.
>
> Sorry - I find the line between the two to be rather blurred at the best of
> times :) Should I forward this or CC this list?
I've added the automake list in cc (I'm interested enough in the outcome
that I don't mind if the autoconf list remains in the distribution).
>
>>
>>>
>>> $ make dist
>>> ...
>>> tardir=openvswitch-2.3.90 && ${TAR-tar} chof - "$tardir" | GZIP=--
>> best gzip -c >openvswitch-2.3.90.tar.gz
>>> tar: value 12345678 out of uid_t range 0..2097151
>>> tar: Exiting with failure status due to previous errors
>>> make[1]: Leaving directory `/development/ovs'
>>> ...
>>>
>>> I managed to modify the Autoconf 'configure.ac' file to use the 'tar-
>> ustar' format, which allow longer file names and other niceties. Again,
>> with the Open vSwitch package:
>>>
>>> diff --git a/configure.ac b/configure.ac
>>> index ebb8b02..6505189 100644
>>> --- a/configure.ac
>>> +++ b/configure.ac
>>> @@ -19,7 +19,7 @@ AC_CONFIG_MACRO_DIR([m4])
>>> AC_CONFIG_AUX_DIR([build-aux])
>>> AC_CONFIG_HEADERS([config.h])
>>> AC_CONFIG_TESTDIR([tests])
>>> -AM_INIT_AUTOMAKE
>>> +AM_INIT_AUTOMAKE([tar-ustar])
>>
>> Are you proposing that we change the way autoconf is distributed? That
>> won't affect any other packages (you'd have to make the same patch for
>> each affected package), and so far, your code shows that you had
>> problems in building an openvswitch tarball, not an autoconf tarball.
>> Again, changing automake to do this automatically for ALL packages (once
>> those packages are built with a new enough automake) rather than trying
>> to patch one configure.ac for every affected package, seems like it
>> would be the better course of action.
>>
>> I'm still open to be convinced that autoconf needs to alter its own
>> configure.ac, but I don't have enough evidence yet that it would make a
>> difference.
>
> Not necessarily. The use of the 'v7' format means any users with a 32 bit UID
> will need to modify every 'configure.ac' file they come across to fix the
> above issue. However, it's not like I personally work with enough packages to
> make this much of an issue. Instead, an approach that would allow me to
> enable the 'tar-ustar' format dynamically (like the 'configure' option above)
> would be just fine, if such a thing exists. This would allow me (and all
> 32bit UID users) to adopt a standard approach to working with Autotools based
> packages (i.e. always pass an option to the 'configure' script of any
> Autotools-based package).
>
> Changing the default tar format used by Autotools would result in a permanent
> fix for all affected users, as you say (affected users = the other developers
> in my team in Intel, for example). However, I don't know if this would cause
> compatibility issues on certain (very, very old) machines. You could see a
> scenario whereby the 'make dist' target of (previously working)
> autogenerated-Makefiles files would break when Autotools is updated, due to
> the ustar format not being supported. I have no data on tar ustar support,
> I'm afraid.
As for whether the upstream automake should make it easier for runtime
overrides of the format, or even dynamic changes, I am not sure. I also
know that some packages (particularly those using gnulib's GNUmakefile)
explicitly set:
export TAR_OPTIONS = --owner=0 --group=0 --numeric-owner
to try and avoid the problem of a 32-bit uid interfering with the
creation of old-style tar files. Maybe that is an approach that should
be folded into automake?
>
> I will attempt to reproduce this issue on other Autotools-based packages and
> report my findings.
>
Not sure that your additional testing will change anything - again, the
issue here is that automake would be the one place to change for
everyone else to automatically benefit from, once packages are rebuilt
with newer automake.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Portable Use of Variables
On 11/11/2014 10:59 AM, fr33domlover wrote: >>> The first form of expansion on that page, $(var:.a=.b), should be OK. >>> They are standard in POSIX and work on all make implementations that I >>> know of. >>> >>> The version with % characters is not portable. >> >> That said, POSIX is hoping to standardize it in the next few years: >> >> http://austingroupbugs.net/view.php?id=519 >> > > Hmmm I was sure it's portable because `make distcheck` doesn't complain about > the %s, and I'm using -Werror and -Wall automake flags. How bad is it? I > suppose it's not specific to just GNU make alone? automake can't warn about all non-portable aspects, although patches to make it warn about more cases would be welcome. And the fact that POSIX is planning to standardize % substitutions in make is a sign that existing implementations that already support it are in agreement (more than just GNU make), so if you want to be on the leading edge of the curve, you aren't excluding that many users. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Auto-Generating ChangeLog and AUTHORS for projects in a version tracking system?
On 10/29/2014 04:29 PM, Diego Elio Pettenò wrote: [we tend to avoid top-posting on technical lists] > Can't we just say that gnu-flavour automake is pointless and foreign should > be the default? Or am I too opinionated on that? For GNU projects, the 'gnu' flavor still makes sense, even if it could use a little modernization such as easier automation of generating ChangeLog from version control. And while these days, automake is probably used by more non-gnu projects (where 'foreign' may make more sense) than GNU projects, that's still not a good reason to toggle the default. I like what the GNU Coding Standards represent, and deviating from them deserves a mention in configure.ac to make it apparent that you thought about it. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Portable Use of Variables
On 10/27/2014 11:11 AM, Nick Bowler wrote: > On 2014-10-26 22:15 +0200, fr33domlover wrote: >> I'm a bit confused about all the expressive features and ways to use makefile >> variables, so just to be sure - >> >> http://www.gnu.org/software/make/manual/html_node/Substitution-Refs.html >> >> Are these uses of variables portable, or should a portable Makefile.am use >> only >> the plain $(var) form without the tricks? > > The first form of expansion on that page, $(var:.a=.b), should be OK. > They are standard in POSIX and work on all make implementations that I > know of. > > The version with % characters is not portable. That said, POSIX is hoping to standardize it in the next few years: http://austingroupbugs.net/view.php?id=519 -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: What would the correct way be to handle a program with a PID file being built to a prefix directory?
On 06/18/2014 08:19 AM, Gavin Smith wrote:
> On Wed, Jun 18, 2014 at 3:47 AM, Michael Lueck
> wrote:
>> Prefix, building the program with non root permissions to be run in the
>> context of a user's home directory.
>>
>> PID file, generally defaults to /var/run, however in this case permissions
>> are not granted to /var/run. One could assume ~/var/run would be the proper
>> place for the PID file.
>>
>> Building a certain OSS/FS app fails when being built with a prefix
>> specified, as /var/run is still assumed for the PID file. I hacked the
>> source code to obtain ability to target ~/var/run for the PID file, and the
>> program works as expected.
>>
> It depends on the build system of the program in question, but it
> looks like "localstatedir" is the preferred makefile variable for this
> directory, and is as an autoconf output variable. It should be set
> automatically from whatever "prefix" directory was specified.
Actually, autoconf 2.70 (if I ever get time to release it) supports a
new --runstatedir option, which defaults to ${localstatedir}/run; but it
should be preferred over direct use of $localstatedir because some
distros want to stick --runstatedir at /run in stead of /var/run.
--
Eric Blake eblake redhat com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: Produce symlink into builddir on VPATH?
On 06/11/2014 04:18 PM, Rhys Ulerich wrote: > Other than resorting to the shell in a target, is there a way to cause > Automake to produce a symlink from the source tree into the build tree > if-and-only-if the build is VPATH? Yes, for new enough autotools. See how gnulib does it for GNUmakefile: http://git.savannah.gnu.org/cgit/gnulib.git/tree/modules/gnumakefile -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: please confirm license for Automake
On 04/08/2014 01:21 AM, Kovacs, Mariann wrote: > Dear All, > > Please confirm under which GNU license Automake is licensed. Which version of automake are you interested in? It looks like the current git tree is still stuck at GPLv2+, although, from commit fcf2f56, we intend to eventually move to GPLv3+ plus exception (the exception ensuring that you can use automake on a non-GPL project or on a GPLv2[+] project without being forced to use GPLv3), similar to what autoconf has already done. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: autotest, automake & non-recursive makes
On 09/26/2013 12:13 PM, Diab Jerius wrote: > On Thu, Sep 26, 2013 at 2:09 PM, Eric Blake wrote: >> On 09/26/2013 10:16 AM, Diab Jerius wrote: >>> I embarked on a journey yesterday involving automake, autotest, and >>> non-recursive makes. I started with the example Makefile.am snippet >>> provided in the autoconf (v 2.69) manual and ran into a few problems, >>> which I've kludged around. Perhaps others have better solutions? >> >> And when you do come to consensus on the best solution, please also send >> a patch to the autoconf list so that they can update their manual to >> include it as an example. > > > Will do. This seemed a more appropriate starting place for the discussion. Agreed, since it relies on brand-new automake features :) -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: autotest, automake & non-recursive makes
On 09/26/2013 10:16 AM, Diab Jerius wrote: > I embarked on a journey yesterday involving automake, autotest, and > non-recursive makes. I started with the example Makefile.am snippet > provided in the autoconf (v 2.69) manual and ran into a few problems, > which I've kludged around. Perhaps others have better solutions? And when you do come to consensus on the best solution, please also send a patch to the autoconf list so that they can update their manual to include it as an example. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Setting python interpreter in scripts
On 07/31/2013 03:23 PM, Adam Mercer wrote: > Hi > > In one of our projects we have several python scripts that we need to > ensure that the python interpreter is set to the one found by > configure. At the moment we are doing this by having the interpreter > set to @PYTHONPROG@ and then using the following rule: > > python_config.sed: > @-rm -f python_config.sed > @echo "s+@PYTHONPROG@+@PYTHON@+g" >> python_config.sed This is an unsafe sed script, if configure found a version of PYTHON that includes a '+' in its (possibly absolute) name. Better would be using something that has to be quoted for use in the shell, as that is less likely to be the name of any PYTHON directory the user desires to use, as in 's|@PYTHONPROG@|@PYTHON@|'. > > script: $(srcdir)/script.in python_config.sed > $(AM_V_GEN)sed -f python_config.sed $(srcdir)/script.in > script > @chmod +x script > > This has always seemed like an ugly hack to me, especially as the > script is in the VCS as script.in instead of the actual name. > > Can anyone offer any more sane ways of accomplishing this? Why not add this to your configure.ac: AC_SUBST([PYTHON], ...) AC_CONFIG_FILES([script], [chmod +x script]) prior to the AC_OUTPUT, so that running config.status (as part of the configure script itself) will automatically replace @PYTHON@ from the script.in template into the output script without you repeating the work in your makefile. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Put GNU build system files in a subdirectory?
On 04/24/2013 06:44 PM, Andy Tai wrote: > The GNU Build system is generally set up such that the Makefile.am, > configure.ac, etc. files are in the root directory of a software project. > Is there a way to place these files in a subdirectory of the root > directory, like this as an example: > > ./ > README > COPYING > GNUBuild/ > Makefile.am > configure > ... > include/ > src/ > > ... > > > This may mean the user has to run configure from the subdirectory GNUBuild > as the initial step. But the good thing is that this makes the source > files and build files separate and allows co-existence of different build > system support.. for example, CMake's CMakefile.txt can coexist with GNU > build files in a clean fashion Sounds like you are asking a similar question to this: https://lists.gnu.org/archive/html/automake/2013-04/msg00014.html with this answer of no (which really means: if YOU write the patches and prove that they are worth maintaining, then it could be added in the future, but no one else is interested in this unusual setup): https://lists.gnu.org/archive/html/automake/2013-04/msg00021.html -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: $(OBJEXT) equivalent for .lo files?
On 04/16/2013 07:55 AM, Rhys Ulerich wrote: > Hi all, > > Explicit dependencies look like > foo.$(OBJEXT) : $(srcdir)/foo.F90 bar.$(OBJEXT) > where $(OBJEXT) serves to insulate one from whether or not the suffix > is .o for an object file. $(OBJEXT) is .o on Unixy systems, but .obj on some other platforms. > > What's the $(OBJEXT) equivalent for a .lo file? I'm providing > explicit dependencies for some Fortran files and need to express > things like > foo.lo : $(srcdir)/foo.F90 bar.lo > > Or, is the .lo extension guaranteed across platforms? .lo, on the other hand, is platform independent, so it needs no variable wrapper. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Autoreconf stops with "non-POSIX variable name"
On 04/01/2013 05:07 PM, Borchert, Oliver wrote: > Eric and Russ, > > thanks for the reply. After long testing back and forth I decided to use > AC_SUBST. > My solution might not be the cleanest but it works for me. It may work for you, but it alienates all users that were previously able to build your package with non-GNU make. (Are there any?) > > In configure.ac I added the following line > AC_SUBST([DOLLAR_SIGN],[$]) > > In the Makefile.am I changed my previous line into > MY_REVISION=@DOLLAR_SIGN@(shell cat $(SRC_DIR)/$(MY_REVISION_FILE)) If you care about non-GNU make users, then you can't use $(shell). And as long as you are going to mandate that your package be built with GNU make, then you might as well go all the way and document that fact in your README file, as well as: >>> This is actually an Automake question, but the short answer is that >>> you probably have fatal warnings enabled and you need to add >>> -Wno-portability to the Automake flags (in AM_INIT_AUTOMAKE, for >> example). ...tell automake that you don't care about the non-portability aspect by adding -Wno-portability to your AM_INIT_AUTOMAKE, at which point you'd no longer need your @DOLLAR_SIGN@ hack. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Autoreconf stops with "non-POSIX variable name"
[adding automake] On 03/29/2013 03:44 PM, Russ Allbery wrote: >> MY_REVISION_FILE=my-revision.txt >> MY_REVISION=$(shell cat $(top_srcdir)/$(MY_REVISION_FILE)) $(shell ...) is a GNU make extension, and by using it, you are making your Makefile.am useless for all other make flavors. Automake's goal is to be portable to ALL makes by default, hence the warning. > >> server/Makefile.am:9: cat $(top_srcdir: non-POSIX variable name >> server/Makefile.am:9: (probably a GNU make extension) >> autoreconf: automake failed with exit status: 1 Admittedly, the warning is rather poor quality; perhaps it is worth turning this into an automake bug to improve the quality of that message. > > This is actually an Automake question, but the short answer is that you > probably have fatal warnings enabled and you need to add -Wno-portability > to the Automake flags (in AM_INIT_AUTOMAKE, for example). Or don't use $(shell), or upgrade to Automake-NG (which _requires_ GNU make to be installed on the end-user's machine, and therefore should let you use GNU make extensions without question). -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS
On 02/02/2013 01:40 AM, Stefano Lattarini wrote: >> I subscribe to all the good opinions about NG that have been >> made here. I would definitely use it once there is a release >> (I have already been criticized several times for having used >> then-CVS versions of the Autotools in Bison, and I don't want >> to go in that direction again). >> > Oh, but I wasn't suggesting to use Automake-NG to bootstrap an official > GNU package! Why not? The end product tarball will require GNU make, but other than that, the end user won't care whether automake or Automake-NG was used to create the tarball. Besides, it is already possible to use automake in a manner that requires GNU make, so end users of those packages won't notice a difference. I guess where it might matter is if distros try to rerun Automake-NG as aggressively as they try to rerun automake on existing packages. Existing distros have stacked the autotools so that they can rerun the same version of automake as a package was originally built with, even if a newer automake has been released since then. So if Automake-NG releases are breaking backwards compatibility for the first little while due to being at alpha quality, that implies that distros will have to repeat their efforts on providing a stacked Automake-NG release for any cases where a package needs to be re-autotooled as part of the distro process. On the other hand, most of the cases where distros end up relying on stacked automake is for packages that aren't actively maintained upstream, and therefore need to have their configure.ac and Makefile.am patched downstream. It can be assumed that the early adopters of Automake-NG are still active, and will be released frequently enough, that it will be easier to fix issues upstream and re-release than to make the distros have to carry downstream patches against configure.ac and Makefile.am that require rerunning the autotools as part of the distro process. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Automake-NG] Removal of INCLUDES in favour of AM_CPPFLAGS
On 02/01/2013 05:00 PM, Peter Rosin wrote: > > And in fact, I just expressed how I think removing support for > INCLUDES is wrong, for *both* projects! I agree that removing it from automake is counterproductive. But I support removing it from Automake-NG - as long as we are moving to a newer environment, we can afford to modernize and get rid of namespace pollution. > but supporting INCLUDES will never hinder progress (I > fail to see how anyway). Namespace cleanliness in Automake-NG is a nice goal, one where it is worth warning about (but not removing) use of INCLUDES in Automake in order to make it easier to switch to Automake-NG. It may turn out that in Automake-NG, supporting INCLUDES costs a lot more clutter than desirable. Remember, in Automake-NG, we use GNU make features, such as the ability to easily iterate over all targets that match a certain glob pattern - but this only works if a pattern is easy to write. It is easy to glob for all things beginning with AM_, but harder if you have to special-case for outliers like INCLUDES. > To me, the change was made just because > it was perceived as messy or redundant. But the messiest part > of the removed code was the deprecation warning. Carrying on > with the support for INCLUDES in automake costs nearly nothing. I agree that _in automake_, carrying support for INCLUDES costs almost nothing, since we already have code to detect INCLUDES, and since we already have to issue warnings about using INCLUDES. > Supporting INCLUDES in automake-NG costs nearly nothing. This, however, is a statement I'm not willing to concede; so while I agree with the decision to deprecate (but not remove) INCLUDES from automake, I think it is fair game to state that someone switching to Automake-NG should be prepared to avoid INCLUDES, as part of that switch. > > All in my humble opinion, of source. Errm, of course. Same goes for me :) > > Cheers, > Peter > > PS. Keep up the good work. Likewise, I applaud your efforts on both automake and Automake-NG, and hope that we can get automake stable enough that you can spend some fun time with Automake-NG. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Conditional AC_DEFINE with m4_define variable?
[adding autoconf, as this question technically is independent of automake] On 12/22/2012 07:52 AM, Jef Driesen wrote: > Hi, > > When I set a variable with: > > m4_define([dc_version_suffix],[devel]) > > or leave it empty: > > m4_define([dc_version_suffix],[]) > > And then try to conditionally call AC_DEFINE based on whether the > dc_version_suffix is set or not, this doesn't work: > > AS_IF([test "x$dc_version_suffix" = "xdevel"], [ >AC_DEFINE(ENABLE_PTY, [1], [Enable pseudo terminal support.]) > ]) This will expand to either: test "x$" = "xdevel" or test "x$devel" = "xdevel" based on the macro value. Probably not what you wanted. > > However if I use m4_isset, then it does kind of work, except that the > USE_REVISION macro in the config.h is either defined, or not present at > all. > > m4_ifset([dc_version_suffix],[ >AC_DEFINE(USE_REVISION, [1], [Use the revision number.]) > ]) Indeed, this actually does what _I_ would want - since dc_version_suffix is known at m4 time, we might as well use that information to generate the smallest possible configure. But if you _insist_ on delaying the decision until shell time, even though the condition being tested is known at m4 time, then you probably want to use something like this: AS_IF([test "x]dc_version_suffix[" = "xdevel"], [ AC_DEFINE([USE_REVISION], [1], [Use the revision number.]) ]) which expands the literal contents of the macro in place, so that your configure will then either contain: test "x" = "xdevel" or test "xdevel" = "xdevel" Or, if you _want_ a shell variable rather than an m4 variable as the source of your decision, then be sure you set up that shell variable: [dc_version_suffix]=dc_version_suffix AS_IF([[test "x$dc_version_suffix" = "xdevel"]], [ AC_DEFINE([USE_REVISION], [1], [Use the revision number.]) ]) where the extra quoting is necessary to ensure that your configure file will look like either: dc_version_suffix= test "x$dc_version_suffix" = "xdevel" or dc_version_suffix=devel test "x$dc_version_suffix" = "xdevel" Using a different shell variable name than the m4 macro name will make it easier to type, without quite so much quoting: version_suffix=dc_version_suffix AS_IF([test "x$version_suffix" = "xdevel"], [ AC_DEFINE([USE_REVISION], [1], [Use the revision number.]) ]) > > Does anyone know how to implement this correctly? It really depends on what you are trying to accomplish by deciding something at m4 time, but deferring the action on that decision until configure time. -- Eric Blake eblake redhat com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: looking for a good example of non-recursive Make using project
On 11/19/2012 12:51 AM, NightStrike wrote:
> If you include src/more/Makefile.am into src/Makefile.am (a perfectly
> valid thing to do), you will be unpleasantly surprised that
> src/more/Makefile.am has to actually know where it is in the source
> tree. It needs lines like this:
>
> prog_SOURCES += more/file3.c more/file4.c
>
> and **NOT** this:
>
> prog_SOURCES += file3.c file4.c
>
>
> It's really annoying. It means that renaming a directory is reaaly hard.
You can reduce the pain by using variables:
more = more
prog_SOURCES += ${more}/file3.c ${more}/file4.c
so that a rename now only has to touch the 'more =' line, rather than
every use.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: apt-get/yum like dependency installation in autotool
On 10/23/2012 11:19 AM, Dan Kegel wrote: > On Tue, Oct 23, 2012 at 9:05 AM, Rudra Banerjee wrote: >> I don't know if this is asking too much from autotools, but is it anyway >> possible to install missing dependency files via autotools? >> say, in my program, I use libsoup as >> #include >> >> is it possible for autotools to install libsoup if it is missing? > > offhand, I'd say that's beyond the scope of autotools, Agreed. You're not the first person to ask, and this earlier thread should give you more clues why autotools is not the place to do this: https://lists.gnu.org/archive/html/bug-autoconf/2012-09/msg00049.html -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Pre-built binary package
On 09/20/2012 11:56 AM, Too, Justin A. wrote: > Hi Baurzhan, > > On 9/20/12 10:52 AM, "Baurzhan Ismagulov" wrote: > >> On Thu, Sep 20, 2012 at 10:24:28AM -0700, Too, Justin A. wrote: >>> I would like to build and distribute a pre-built binary package for my >>> project >> >> For which OS / distribution? > > For example: Linux (rhel5/6) and Ubuntu. Those are different distros, and therefore have different rules on how to package binaries. You sound like you're trying to reinvent yourself as a distro. My advice: don't. Let the distros package binaries, and you focus on distributing source. The ONLY way you can expect to ship a pre-built binary in your tarball and have it work for all possible users installing your tarball is if your binary is architecture and OS-independent (such as java bytecode). In all other cases, it makes more sense for the user to build the binary themselves from the source (where user includes major distros, who will then package it up in .rpm or apt formats as appropriate for the distro, and where the distro package-manager software like yum or apt-get can then be used to install that binary in desired locations). -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [libvirt] libvirt build failure w/GNU make and automake.git (automake regression?)
On 09/12/2012 09:01 AM, Jim Meyering wrote:
> When I run ./autogen.sh && make, I see this:
> (this arose because I had the latest automake.git/master tools --
> commit c1b83e1af60b866cf5cdeebf77d0275019bad8b2 from today --
> early in my path)
>
> Making all in tests
> make[2]: Entering directory `/h/j/w/co/libvirt/tests'
> Makefile:4355: *** Malformed target-specific variable definition. Stop.
>
> The trouble is that "undefine" is an operator in GNU make.
> The most pragmatic work-around is to rename the "undefine" test script.
Indeed - while the upstream debate continues on whether 'make',
'automake', or both should be patched to allow 'undefine', downstream in
libvirt, I am pushing this trivial patch:
From a20f06d9d9b0353d7fb7a8e11a631253d5961b96 Mon Sep 17 00:00:00 2001
From: Eric Blake
Date: Wed, 12 Sep 2012 11:25:51 -0600
Subject: [PATCH] build: avoid confusing make with raw name 'undefine'
Make has a builtin operator 'undefine', and coupled with latest
automake.git, this test name ended up confusing make into thinking
the file name was meant to be used as the make operator. Renaming
the file avoids the confusion.
* tests/undefine: Rename...
* tests/virsh-undefine: ...to this.
* tests/Makefile.am (test_scripts): Use new name.
Reported by Jim Meyering.
---
tests/Makefile.am | 10 ++
tests/{undefine => virsh-undefine} | 0
2 files changed, 6 insertions(+), 4 deletions(-)
rename tests/{undefine => virsh-undefine} (100%)
diff --git a/tests/Makefile.am b/tests/Makefile.am
index bec89e2..c5cecaa 100644
--- a/tests/Makefile.am
+++ b/tests/Makefile.am
@@ -182,12 +182,13 @@ test_scripts += \
read-bufsiz \
read-non-seekable \
start \
- undefine\
vcpupin \
virsh-all \
virsh-optparse \
virsh-schedinfo \
- virsh-synopsis
+ virsh-synopsis \
+ virsh-undefine \
+ $(NULL)
test_programs += \
eventtest \
@@ -203,12 +204,13 @@ EXTRA_DIST += \
read-bufsiz \
read-non-seekable \
start \
- undefine\
vcpupin \
virsh-all \
virsh-optparse \
virsh-schedinfo \
- virsh-synopsis
+ virsh-synopsis \
+ virsh-undefine \
+ $(NULL)
endif
if WITH_SECDRIVER_APPARMOR
diff --git a/tests/undefine b/tests/virsh-undefine
similarity index 100%
rename from tests/undefine
rename to tests/virsh-undefine
--
1.7.11.4
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: [PATCH] {master} compile: remove support for $(INCLUDES)
On 08/22/2012 03:52 PM, Stefano Lattarini wrote: > OTOH, I believe developers working on older systems should be ready to > install more recent developer tools once in a while. You can't truly > expect not to update your Automake installation for 3, 4 years! Oh, _I_ fully wish that RHEL 5 would at least update the core toolchain (in fact, these links [1],[2] make it look like Red Hat is working towards a solution of supporting parallel toolchains, with a modern toolchain installed alongside the stable distro toolchain even for older RHEL). But the fact remains that Enterprise systems tend to lag very far behind the curve, and so you have a tradeoff of whether to support development on such old systems, or merely support the released product on old systems while requiring development on newer systems. At the end of the day, it boils down to a question of whether upgrading the toolchain would risk introducing FTBFS to some critical piece of in-house software, and enterprise customers frown at risk, so they really do use 3 and 4-year-old automake solutions. [1] https://www.redhat.com/developers/rhel/ [2] https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Developer_Toolset/1/html/User_Guide/chap-Red_Hat_Developer_Toolset.html#sect-Red_Hat_Developer_Toolset-About -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] {master} compile: remove support for $(INCLUDES)
On 08/22/2012 09:12 AM, Stefano Lattarini wrote: >>From 54a49542d417850e646fefe7bad56546a2362449 Mon Sep 17 00:00:00 2001 > Message-Id: > <54a49542d417850e646fefe7bad56546a2362449.1345648257.git.stefano.lattar...@gmail.com> > From: Stefano Lattarini > Date: Wed, 22 Aug 2012 16:40:15 +0200 > Subject: [PATCH] compile: remove support for $(INCLUDES) > > It has already been deprecated in the manual and by warnings in the > 'obsolete' categories for ages (at least since 2003), in favour of > AM_CPPFLAGS. Automake-NG has removed support for it already. > > So, by removing it in Automake 1.13, we will simplify the transition > path for people that want to switch to Automake-NG. What a bummer for packages like libvirt that strive to be buildable from git on both RHEL 5 (requires INCLUDES, since automake 1.9.6 is still the current version there) as well as Fedora rawhide (where removing support for INCLUDES entirely will force the issue over to AM_CPPFLAGS). It means I'll have to come up with some compatibility hacks in order to share one Makefile.am among both automake versions. Or maybe I'll just give up and say that libvirt can no longer be bootstrapped on RHEL 5 (it can still be developed there, but only if you bootstrap somewhere else and then 'make dist' and develop on the distributed tarball). At any rate, I'm fine taking the burden of trying to support cross-automake versioning in order to cater to the fact that enterprise systems are still stuck on ancient automake, but a little help from automake would make it easier. I'd much rather a mandatory noisy warning period before a feature is completely removed. Yes, you've warned, but the warning wasn't mandatory, so no one has been forced to come up with workarounds yet. It is only once people have the workarounds in place that it is safe to remove the feature; I think that argues that you can't remove INCLUDES until 1.14, but that 1.13 should make the warning unconditional. It would also be nice if you provided a feature that could be probed at m4 time in order to write a configure.ac that can then set an automake conditional, so that Makefile.am can then set either INCLUDES or AM_CPPFLAGS as appropriate within the two branches of the conditional. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [Automake-NG] Automake vs. Automake-NG
On 08/21/2012 10:30 AM, Ralf Corsepius wrote: >>> And I've done that already where possible and reasonable. For example, >>> the 'silent-rules' option is now active by default, and the tags-related >>> rules have been reworked and improved. > > Well, from a distro maintainer's view this a bad idea. Ralf, how many times do we have to tell you? Setting the automake option 'silent-rules' does NOT make the build silent by default, it merely enables the possibility of a silent build. Remember, when 'silent-rules' was first implemented, we did it with an implementation that violated POSIX make, and so we made it optional whether your Makefile would work on 95% of make implementations by supporting silent rules at the expense of POSIX (you, the end user, still decide whether to be silent or noisy), or whether your Makefile would work on 100% of make implementations but lack the ability to configure silent vs. noisy (you, the end user, have no choice). Since that original implementation, we came up with a way to make silent rules configurable in a manner compliant with 100% of make implementations, without violating POSIX. Therefore, we can now ALWAYS emit the automake code that allows you, the end user, a choice between silent or noisy. It is still up to individual packages whether the build will be silent or noisy by default, and it remains something that you can override package defaults with a config.site that forces noisy builds. The 'silent-rules' change in automake change did NOT make more builds instantly silent, nor are we preventing you from your goal of noisy builds for the Fedora buildbots. Quit beating a dead horse to spread FUD about something which is not true. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: v1.11.6 tag missing from automake.git?
On 08/14/2012 04:24 PM, Stefano Lattarini wrote: > Hi Eric. > > On 08/15/2012 12:16 AM, Eric Blake wrote: >> I see v1.12.2, but no tag for v1.11.6 for the CVE-2012-3386 fix. >> > Hmm... I can see it without problems: > > <http://git.savannah.gnu.org/cgit/automake.git/tag/?id=v1.11.6> > > User error on your part, or am I missing something? I blame 'git remote update origin' for not pulling all tags that are not also reachable from a current branch; and since origin/branch-1.11 is no longer maintained, I no longer have a branch spec to pull in the new label by default. I had to do an explicit 'git fetch --tags origin' to get it, but now I see the label again. It really IS a good practice to keep a branch associated with all public long-lived tags; it doesn't waste any additional space in the git repo, and makes fetches pick up those tags with less effort. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
v1.11.6 tag missing from automake.git?
I see v1.12.2, but no tag for v1.11.6 for the CVE-2012-3386 fix. Is this intentional? -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: distinguish automake 1.11 from 1.12+ at autoconf time
On 08/06/2012 05:29 PM, Peter Johansson wrote: > Hi, > > I'd like to distinguish automake 1.11 from 1.12 (or later) at autoconf > time. I wonder is there's any documented macro that was introduced in > 1.12 that I could use to m4_ifdef? If nothing else, the autoconf philosophy of feature checks being better than version checks should guide your decision here. What _specific_ feature are you using from 1.12 that wasn't present in 1.11? Or put another way, either your configure.ac works equally well with both versions (so you don't care which version), or there's something you do with 1.12 that doesn't work with 1.11 and therefore you are trying to make it conditional so that 1.11 can still process the rest of the file. Determine that feature, and we are that much closer to helping you conditionalize your configure.ac to work with both versions. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH] config: drop scripts that automake says are not independent
[adding autoconf] On 06/26/2012 12:26 PM, Bruno Haible wrote: > Eric Blake wrote: >> * build-aux/elisp-comp: Delete. > > What about modules/elisp-comp? That module has only had one edit: it's introduction in 2006: https://lists.gnu.org/archive/html/bug-gnulib/2006-08/msg00248.html with a claim that autoconf needs it. But autoconf uses automake, and can get the file from automake, if it really needs it. For that matter, WHY does autoconf need it? Looking at 'git grep -l elisp-comp', I see: .gitattributes .gitignore ChangeLog.3 cfg.mk which means the ONLY mention of elisp-comp is historical or version-control, other than the cfg.mk listing that syncs the file. It appears that autoconf itself does not either use or advertise the existence of elisp-comp, so I will be fixing autoconf to delete the syncing of the file. On the unlikely chance that someone was relying on autoconf (rather than automake) as their upstream source for elisp-comp, I will also include a NEWS entry as part of that effort. For gnulib, I therefore think it is appropriate to completely delete modules/elisp-comp, unless someone speaks up with some evidence of a package that is actively relying on the module. Again, a NEWS entry pointing to automake would be appropriate. I'll respin the gnulib patch accordingly. > >> * build-aux/ylwrap: Likewise. > > OK. Many packages (gettext-runtime/intl, parse-datetime, ...) rely directly > on bison. Only packages which support old yacc need this wrapper script, and > they typically use Automake. And not mentioned in my proposed commit message, but I specifically kept mdate-sh as one of the mirrored files, even though Stefano originally suggested that it might be automake-centric; that particular script is small enough to be useful in a standalone context. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
[PATCH] config: drop scripts that automake says are not independent
These three scripts are too closely tied to automake internals to be independently useful. In fact, automake would rather that people did not mix the latest version of these scripts with older versions of automake, as there is no effort being put into maintaining backwards-compatibility when these scripts are updated. * config/srclist.txt: Drop elisp-comp, missing, and ylwrap. * build-aux/elisp-comp: Delete. * build-aux/missing: Likewise. * build-aux/ylwrap: Likewise. Signed-off-by: Eric Blake --- Any objections to this patch? ChangeLog|8 ++ build-aux/elisp-comp | 93 build-aux/missing| 214 -- build-aux/ylwrap | 232 -- config/srclist.txt |3 - 5 files changed, 8 insertions(+), 542 deletions(-) delete mode 100755 build-aux/elisp-comp delete mode 100755 build-aux/missing delete mode 100755 build-aux/ylwrap diff --git a/ChangeLog b/ChangeLog index ebbc96b..228383c 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,11 @@ +2012-06-26 Eric Blake + + config: drop scripts that automake says are not independent + * config/srclist.txt: Drop elisp-comp, missing, and ylwrap. + * build-aux/elisp-comp: Delete. + * build-aux/missing: Likewise. + * build-aux/ylwrap: Likewise. + 2012-06-24 Bruno Haible ptsname_r: Make it consistent with ptsname on AIX. diff --git a/build-aux/elisp-comp b/build-aux/elisp-comp deleted file mode 100755 index 7766db4..000 --- a/build-aux/elisp-comp +++ /dev/null @@ -1,93 +0,0 @@ -#!/bin/sh -# Copyright (C) 1995-2012 Free Software Foundation, Inc. - -scriptversion=2010-02-06.18; # UTC - -# Franc,ois Pinard , 1995. -# -# This program is free software; you can redistribute it and/or modify -# it under the terms of the GNU General Public License as published by -# the Free Software Foundation; either version 2, or (at your option) -# any later version. -# -# This program is distributed in the hope that it will be useful, -# but WITHOUT ANY WARRANTY; without even the implied warranty of -# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the -# GNU General Public License for more details. -# -# You should have received a copy of the GNU General Public License -# along with this program. If not, see <http://www.gnu.org/licenses/>. - -# As a special exception to the GNU General Public License, if you -# distribute this file as part of a program that contains a -# configuration script generated by Autoconf, you may include it under -# the same distribution terms that you use for the rest of that program. - -# This file is maintained in Automake, please report -# bugs to or send patches to -# . - -case $1 in - '') - echo "$0: No files. Try '$0 --help' for more information." 1>&2 - exit 1; - ;; - -h | --h*) -cat <<\EOF -Usage: elisp-comp [--help] [--version] FILES... - -This script byte-compiles all '.el' files listed as FILES using GNU -Emacs, and put the resulting '.elc' files into the current directory, -so disregarding the original directories used in '.el' arguments. - -This script manages in such a way that all Emacs LISP files to -be compiled are made visible between themselves, in the event -they require or load-library one another. - -Report bugs to . -EOF -exit $? -;; - -v | --v*) -echo "elisp-comp $scriptversion" -exit $? -;; -esac - -if test -z "$EMACS" || test "$EMACS" = "t"; then - # Value of "t" means we are running in a shell under Emacs. - # Just assume Emacs is called "emacs". - EMACS=emacs -fi - -tempdir=elc.$$ - -# Cleanup the temporary directory on exit. -trap 'ret=$?; rm -rf "$tempdir" && exit $ret' 0 -do_exit='(exit $ret); exit $ret' -trap "ret=129; $do_exit" 1 -trap "ret=130; $do_exit" 2 -trap "ret=141; $do_exit" 13 -trap "ret=143; $do_exit" 15 - -mkdir $tempdir -cp "$@" $tempdir - -( - cd $tempdir - echo "(setq load-path (cons nil load-path))" > script - $EMACS -batch -q -l script -f batch-byte-compile *.el || exit $? - mv *.elc .. -) || exit $? - -(exit 0); exit 0 - -# Local Variables: -# mode: shell-script -# sh-indentation: 2 -# eval: (add-hook 'write-file-hooks 'time-stamp) -# time-stamp-start: "scriptversion=" -# time-stamp-format: "%:y-%02m-%02d.%02H" -# time-stamp-time-zone: "UTC" -# time-stamp-end: "; # UTC" -# End: diff --git a/build-aux/missing b/build-aux/missing deleted file mode 100755 index 06e0af1..000 --- a/build-aux/missing +++ /dev/null @@ -1,214 +0,0 @@ -#! /bin/sh -# Common wrapper for a few potentially missing GNU programs. - -scriptversion=2012-06-14.10; # UTC - -# Copyright (C) 1996-2012 Free Software
Re: Don't distribute auto*tools output; do distribute autoreconf input
On 05/10/2012 01:14 PM, Paul Elliott wrote: > > I want the people that receive my tarball to do autoreconf. Their system's > autoconf-archive may be more up-to date than mine. > > What is the best way to tell automake not to distribute (i.e. put in > tarball), > all the files created by autoreconf, ./configure? ./configure must be put in the tarball (otherwise, you are _forcing_ your end users to use autoconf, but the whole point of autoconf is to make it so that your end users can run configure without having autoconf installed on their machine). However, ./configure need not be stored in your VCS. If what you are really asking is how to avoid generated files in your VCS, so that people developing your package (those that check out from your VCS, rather than end users that build from your tarball) must regenerate the files with their version of the tool, then that's a question that depends on your choice of VCS. Autoconf is such a project, where generated files such as ./configure are part of the tarball but not part of the VCS. > I especially do not want to distribute aclocal.m4 or files that contain it's > info. I want the build system to get up-to-date files from its > autoconf-archive > files. > > I note these files are usually distributed by default, even though no dist_ > statement is asking for them. > > Will it work to put the unwanted files in nodist_prog_SOURCES? > Is there a canonical way to do this? No, because the moment you quit distributing these files, you have required end users to have more tools available than normally required by the GNU Coding Standards to even be able to use your tarball. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: should an empty "pkgdata_DATA" cause creation of $(pkgdatadir) by "make install"?
On 03/13/2012 08:55 AM, Robert Boehne wrote: >> >> So we're in a sort of a tie here: some users think that the current >> Automake >> behaviour is a feature (and I lean toward that position), other ones >> (with >> Ralf among them, apparently) believe it's a bug. Hmmm. What now? >> >> Regards, >>Stefano > > I would agree with the "feature" camp. Users should be able to create > an empty $(pkgdatadir) - suppose that empty directory is populated by > other methods. They should also be able to not create $(pkgdatadir) as > well as a non-empty $(pkgdatadir). I like the idea of installing empty directories by default, as a feature, but can also see the arguments for omitting a directory. What about a compromise: By default, we create the empty directory: pkgdata_DATA = But with the noinst flag, a directory can be specifically marked for no creation unless it later has contents: noinst_pkgdata_DATA = For the sake of conditional concatenation, we should either allow: noinst_pkgdata_DATA = if COND pkgdata_DATA += file endif or else make the documentation explicit that to conditionally install contents to a directory, but to omit the directory if no contents are present, then you must do: noinst_pkgdata_DATA = pkgdata_DATA = if COND pkgdata_DATA += file endif Either way, the semantics are that if there are contents in a directory, then the directory is created; if the conditions make it so there are no contents in a directory, then the directory is created _unless_ the noinst_ prefix also appeared with that directory. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: automake 1.11.3 check-TESTS and command line length
On 02/27/2012 12:52 PM, Stefano Lattarini wrote: > [re-adding the relevant automake bug in CC] > > Hi Peter, thanks for chiming in. > > On 02/27/2012 12:15 PM, Peter Rosin wrote: >> >> I *think* the environment and the command line shares space (approx 64kB, I can confirm this, based on my testing of Windows process spawning. > So, basically, on MSYS, a: > > $ make TESTS="..." > > invocation reduces the size available for the command lines of the make > recipes, because the value of TESTS that gets exported in the environment > eats away space that could be used by those command lines? Oh joy ... Yes. Unlike on *ix systems, where argv and environ are independent entities, Windows makes you deal with both limits at the same time, so increasing the size of environ reduces the size permitted in argv. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: pkglibdir, pkgdatadir and program_transform_name
On 02/27/2012 02:37 AM, Miles Bader wrote: > Stefano Lattarini writes: >> Any transformation of a $(pkg*dir) by $(program_transform_name) >> would be a bug; if you encounter such an issue, I'd be grateful if >> you report it. >> >> But I'm pretty sure the inconsistency you are seeing here is due to >> another reasons (maybe some Makefile.am or configure.ac settings >> you're missing?) > > When I was googling earlier (due to this same thread on the autoconf > mailing list), I found patches to automake to _implement_ such a > transformation posted to the grub mailing list... so maybe it's a > modified version of automake. I think it's worth pursuing a patch to the GNU Coding Standards that allows a standardized configure option that allows one to specify an alternate package name, so that things like $(pkglibdir) become $(libdir)/$(alternate_package_name) - precisely because of situations like grub vs. grub2 where there are two versions of the same package 'grub' but which are worth installing in parallel. Allowing distro package managers to install the two versions side-by-side by way of a new standardized configure option for specifying the alternate package name of the second installation, and then adding automake and/or autoconf support for providing configure support for an alternate package name, seems like it would be worthwhile for more than just grub. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: *simple* example using Autotest
On 02/07/2012 03:08 PM, Robert Boehne wrote: > All, > > I'd like to start using Autotest in a project (that needs is badly) but > the full-featured GNU M4 example is a bit hard to wrap my head around. > Can anyone suggest another project I could look at as an example, that > has more basic/rudimentary Autotest use? Automake is probably the wrong list to ask, since autotest is provided by autoconf, and automake isn't using autotest. But here are several projects I know of that use autotest: autoconf itself m4 bison libtool some of them easier than others to figure out, but that should hopefully help you get started on seeing how others have used it. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Automake 1.11.2b test release
On 01/27/2012 01:08 PM, NightStrike wrote: > On Thu, Jan 26, 2012 at 1:47 AM, Ralf Corsepius > wrote: >>> - The support for the "obscure" multilib feature has been deprecated, >>> and will be moved out of the automake core in the next major Automake >>> release (1.12). >> >> Bummer - Please reconsider this and understand that politliness prohibits me >> to furtherly comment on this. > > Seconded. Moving multilib files out of the core does not mean that it is being permanently broken, it only means that you have to start pulling in the contrib directory if you want to use multilib. That is, we're not killing the feature entirely, we're only splitting it out of automake proper into its own project, where it will hopefully get more attention than what the current level it is getting while embedded in automake. Re-read the list where we discussed this - gcc is doing a better maintenance job of multilib support in the first place, so this move is intended to point you towards the better-maintained source in the first place. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
RFC: cool hack for simplifying do_subst generation of scripts
I was chatting with Federico on IRC about a way to avoid duplication between Makefile.am and configure.ac. His particular case had a script file that wanted a few full substitutions (which implies a make-time substitution, per [1]), but he didn't want to have to copy the whole list of AC_SUBST from configure.ac into Makefile.am in his do_subst script, and didn't want to build a file.in.in that goes through configure AC_CONFIG_FILES only to have file.in then go through a make-time expansion. We came up with the autoconf-documented use of $(top_builddir)/config.status --file=- (from [2]). And to demonstrate the ease of use, I've done this preliminary patch against automake itself. Is this something we are interested in doing (since it _does_ provide a reduced maintenance burden, where adding a new AC_SUBST that does not need make-time expansion can now be done in just one file instead of two)? And if so, should I expand this RFC patch into something that passes the testsuite as well as mentioning it in the automake manual? [For the purposes of my quick test, I started a 'make check', still underway as I type this, and noticed that at least aclocal5.test failed, but everything else through f90only.test is happy so far. But I won't bother to investigate failures unless we decide to go forward with this plan.] [1] https://www.gnu.org/software/automake/manual/html_node/Scripts.html [2] https://www.gnu.org/software/autoconf/manual/autoconf.html#config_002estatus-Invocation diff --git i/Makefile.am w/Makefile.am index 8fe9c0f..0ef39c1 100644 --- i/Makefile.am +++ w/Makefile.am @@ -67,21 +67,11 @@ uninstall-hook: done -## We can't use configure to do the substitution here; we must do it -## by hand. We use a funny notation here to avoid configure -## substitutions in our text. +## We want a handful of substitutions to be fully-expanded by make; +## then use config.status to substitute the remainder where a single +## expansion is sufficient. We use a funny notation here to avoid +## configure substitutions in our text. do_subst = sed \ - -e 's,[@]APIVERSION[@],$(APIVERSION),g' \ - -e 's,[@]PACKAGE[@],$(PACKAGE),g' \ - -e 's,[@]PACKAGE_BUGREPORT[@],$(PACKAGE_BUGREPORT),g' \ - -e 's,[@]PACKAGE_URL[@],$(PACKAGE_URL),g' \ - -e 's,[@]PATH_SEPARATOR[@],$(PATH_SEPARATOR),g' \ - -e 's,[@]PERL[@],$(PERL),g' \ - -e 's,[@]PERL_THREADS[@],$(PERL_THREADS),g' \ - -e 's,[@]SHELL[@],$(SHELL),g' \ - -e 's,[@]am_AUTOCONF[@],$(am_AUTOCONF),g' \ - -e 's,[@]am_AUTOM4TE[@],$(am_AUTOM4TE),g' \ - -e 's,[@]VERSION[@],$(VERSION),g' \ -e 's,[@]configure_input[@],Generated from $@.in; do not edit by hand.,g' \ -e 's,[@]datadir[@],$(datadir),g' @@ -92,7 +82,7 @@ automake: automake.in aclocal: aclocal.in automake aclocal: Makefile rm -f $@ $@.tmp - $(do_subst) $(srcdir)/$@.in >$@.tmp + $(do_subst) $(srcdir)/$@.in | ./config.status --file=- >$@.tmp chmod +x $@.tmp chmod a-w $@.tmp mv -f $@.tmp $@ -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
bug#8071: Please rename automake invocation node
On 12/28/2011 12:33 PM, Stefano Lattarini wrote:
>> > This can be fixed by using an @anchor{} to the old name at the same
>> > location as you switch to the new consistent node name. The tools will
>> > then keep the old link live by virtue of the anchor, without having to
>> > mess with .symlinks.
>> >
> Good idea. What about the attached patch? I'm not very familiar with
> the translation of @anchor directives in the HTML output, so I'd like an
> explicit ACK before pushing.
>
>
> -
> -@node Invoking Automake
> +@c The anchor is required to avoid breaking existing web hyperlinks
> +@c still using the old name of this node.
> +@anchor{Invoking automake}
> +@node automake Invocation
> @chapter Creating a @file{Makefile.in}
Autoconf has this example:
@node Specifying Target Triplets
@section Specifying target triplets
@cindex System type
@cindex Target triplet
@c This node used to be named Specifying Names. The @anchor allows old
@c links to still work.
@anchor{Specifying Names}
I'm not sure if putting the @anchor after the @node make a difference.
If the anchor takes the old name to the previous node, then we may want
to move the anchor to appear after the @node.
--
Eric Blake ebl...@redhat.com+1-919-301-3266
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
bug#10237: AM_SILENT_RULES does not work with NonStop make
On 12/07/2011 01:54 PM, Roumen Petrov wrote: >> Exactly. Hence the proposal for a configure-time check, which expands >> to the extension where the extension was tested to work, and which >> expands to an innocuous variant that avoids nested variables where the >> test fails. >> > > I remember one old discussion from automake list that end with following > solution > lib_LTLIBRARIES = @MODULE@.la > @MODULE@_la_SOURCES = module.c > @MODULE@_la_LDFLAGS = -module -avoid-version How is that relavant to this bug? The whole point of Paul's proposal is that @AM_V@ and @AM_DEFAULT_VERBOSITY@ are automake internals, and appear only in Makefile.in, not Makefile.am. > > Following current discussion I think that next will be automake to be > able to process following Makefile.am > > MODULE = @MODULE@ > lib_LTLIBRARIES = $(MODULE).la > $(MODULE)_la_SOURCES = module.c > $(MODULE)_la_LDFLAGS = -module -avoid-version You're asking for something different, which is a smarter automake that can handle Makefile.am in such a way that it can see through a user-provided @MODULE@, even when it is later spelled $(MODULE). But that is unrelated to fixing AM_SILENT_RULES to produce POSIX-compliant makefiles. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile_at_at_check.
On 11/16/2011 06:04 PM, Gary V. Vaughan wrote: > Right, and even when I wrote the dubious comment quoted above in 2003, other > parts of libtool were still using macro expansions in make targets, so I think > the whole thing is probably a red herring. Libtool has never fully supported > any make that can't deal with macros in targets, and we've never received a > complaint or bug report, which makes me think that if such a make exists, no > one wants to use it with libtool, so we can safely ignore the whole thing. > > The NEWS entry I wrote for this commit is purely for future repo archaeology. Then it's not NEWS-worthy. It's worth keeping that analysis in the git commit message (as you say, for repo archaeology), but let's limit it to just there, rather than potentially causing users to worry about some perceived loss of portability when they read NEWS. -- Eric Blake ebl...@redhat.com+1-919-301-3266 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Weird behaviour of AM_CONDITIONAL
On 09/02/2011 08:24 AM, Thibaut Le Guilly wrote: I am using AM_CONDITIONAL to enable a user to choose between one kind of library and another one with : AM_CONDITIONAL([ENABLE_A], [test x$condition=xyes]) > Am I doing something wrong? Do you know how to solve this problem? Wrong syntax. You meant: test "x$condition" = xyes the quoting around $condition, and the spacing around =, are essential in shell syntax. Otherwise, if $condition has no whitespace to cause IFS word splitting, you end up testing whether the single word x$condition=xyes is non-empty, which it is, so the test is always true. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: Makefile.in not generated using Automake
[followups can drop autoconf, as this is an automake-only question] On 06/14/2011 02:12 AM, Rushabh Doshi wrote: > > > $ automake --add-missing > configure.ac:6: installing `./install-sh' > configure.ac:6: installing `./missing' > Makefile.am: installing `./INSTALL' > Makefile.am: required file `./NEWS' not found ... > $ ls > aclocal.m4 autoscan.log configure.ac depcomp INSTALL Makefile.am > autom4te.cache config.h.in COPYING hello.c install-sh missing There's your problem - you blindly ignored the error message from automake and failed to check for non-zero exit status. Automake won't produce Makefile.in if required files are missing. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: debbugs, and a FAQ, for Autotools
On 02/23/2011 05:02 PM, Ben Pfaff wrote: > The question "libtool reorders link fags" seems to have a > spelling error in the last word. It's not obvious to me what > word is meant. flags -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: debbugs, and a FAQ, for Autotools
On 02/13/2011 11:12 AM, Ralf Wildenhues wrote: > [ Cross post; Reply-To and Mail-Followup-To set. Please followup to > the automake list only, to avoid excessive spammage. Thank you. ] > > Hello everyone, > > I've been advertising debbugs before, I think we should be a good > example. So, two proposals: > > 1) Autoconf and Libtool should also use debbugs. > > bug-automake has switched a few months ago, and I find it helpful to > avoid losing reports. Given that we never have enough time on our > hands, it becomes more important to not lose track. > > See http://debbugs.gnu.org/ and linked pages for details. Seems like it might be reasonable for autoconf. However, my biggest concern is that right now, I filter both autoconf and automake messages into the same mail folder, but debbugs anonymizes which list a bug is being reported against (that is, the To: is rewritten as ###@debbugs.gnu.org, so there is no longer any mention of 'automake' in any of the normal mail headers). While I could probably force filtering to take place on X-Debbugs-Original-To:, that still doesn't solve the problem of no visual indication on which list a bug is reported against. Any ideas on how to resolve that issue? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: debbugs, and a FAQ, for Autotools
On 02/19/2011 06:50 PM, Russell Shaw wrote:
> Looking through a ./configure script, i see lots of things being done
> with file descriptors >&5 and >&6. What is going on here? eg:
The example only showed use of >&5.
> eval ac_try_echo="\"\$as_me:${as_lineno-$LINENO}: $ac_try_echo\""
> $as_echo "$ac_try_echo"; } >&5
> (eval "$ac_compile") 2>conftest.err
> ac_status=$?
> if test -s conftest.err; then
> grep -v '^ *+' conftest.err >conftest.er1
> cat conftest.er1 >&5
> mv -f conftest.er1 conftest.err
> fi
> $as_echo "$as_me:${as_lineno-$LINENO}: \$? = $ac_status" >&5
FD 5 is config.log. That is, everything that redirects output to 5 is
setting up more verbose output that will end up in the log file,
compared to the shorter output that appears on just stdout.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: portable way to normalize whitespace?
On 02/09/2011 11:44 AM, Daily, Jeff A wrote: > I'm aware of GNU make's text processing functions. Specifically, I'm looking > for the $(strip string) functionality, but hopefully portable. Is this > functionality available portably? Thanks. Portably within make, no. As a shell sub-process, yes, using common shell text processing programs (such as sed). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: dashes in Makefile macro names
On 01/28/2011 04:38 AM, Bruno Haible wrote: > Hi, > > Can you use $(FOO-BAR) in Makefile? It's not portable in POSIX [1] > "Applications shall select macro names from the set of characters >consisting solely of periods, underscores, digits, and alphabetics >from the portable character set" > And the Autoconf manual too says that it's not portable [2]. > > But Paul Eggert found a number of such Makefile macro names in Emacs [3], > which have apparently not been hurting for years. > > Prompted by this, I've tested the support for Makefile macro names with > dashes in > - GNU make, > - dmake 4.12, > - smake 1.2.1, > - the vendor 'make' in > - MacOS X, > - FreeBSD 6.4, > - OpenBSD 4.4, > - NetBSD 5.0, > - AIX 5.1, > - HP-UX 10.20, > - IRIX 6.5 (also pmake, smake), > - OSF/1 5.1, > - Solaris 2.6 (also dmake), The Austin Group has asked if you would mind repeating the tests to see if all versions of make support leading '.', '-', and digits as a macro name. (The POSIX standard currently doesn't forbid leading digits or periods, but the thought was that there might be implementations that require alphabetic or underscore as the first character, and if so, we ought to fix the wording of the standard to call out that point at the same time it allows dash). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: dashes in Makefile macro names
[adding automake]
On 01/28/2011 04:38 AM, Bruno Haible wrote:
> Hi,
>
> Can you use $(FOO-BAR) in Makefile? It's not portable in POSIX [1]
Then let's get that addressed in POSIX! We're already in the middle of
getting POSIX to support ${var${v}} nested variable expansions, on the
same arguments of multi-implementation portability and ease-of-use for
automake:
http://austingroupbugs.net/view.php?id=336
So I just added another bug report requesting '-' in macro names:
http://austingroupbugs.net/view.php?id=373
> So I think it's time to update the Autoconf documentation by adding a
> sentence. Here's a proposed patch.
>
> 2011-01-28 Bruno Haible
>
> doc: Don't discourage dashes in Makefile macro names.
> * doc/autoconf.texi (Special Chars in Names): Mention that dashes in
> Makefile macro names are supported.
Looks reasonable to me. But I'll wait for any additional feedback
before pushing, in case anyone else has input on the matter.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: High-Precision NFS Timestamps
[adding bug-make, replies can drop automake] On 01/12/2011 03:08 PM, Eric Reischer wrote: > I recently upgraded our NFS fileserver to an ext4 filesystem, and since > then we've been having clock skew warnings from make (3.81). Because > the ext3 filesystem that was previously running on the NFS server didn't > support high-precision timestamps, we didn't have clock skew warnings > because an hourly cron job kept the clocks in relatively close sync. > However, since ext4 does support sub-second timestamps, we're getting > warnings about clock skews on the order of a few milliseconds. I tried > adding our target objects to the .LOW_RESOLUTION_TIME target, however > now we're getting a warning about > > make: *** Warning: .LOW_RESOLUTION_TIME file .lib_deps has a high > resolution time stamp > make: warning: Clock skew detected. Your build may be incomplete. > > Since asking to have system clocks of NFS clients and servers synced to > sub-millisecond precision is a bit excessive, is there a way (or feature > request: could there be a way) to set the threshold for clock skews > either via a runtime Makefile directive, or an environment variable? I > can't see any other way to eliminate these warnings without reverting > back to ext3 (which isn't happening). If it's a hard-coded value, there > should be at least a little room for slop in there (~5 milliseconds?) > due to network lag, etc. Even on a point-to-point network, there's > going to be one-way transit times of a millisecond or two. This is more likely a make issue than an automake issue. That said, NFS timestamps are indeed a source of pain, and gnulib has recently put in quite a bit of work dealing with timestamp skew across NFS (including code to ignore relatively close timestamps, rather than insist that sub-millisecond differences represent skew); some of that may be worth incorporating into the make code base if it isn't there already. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Any way to get rid of -MP parameter to gcc for dependency creation?
On 01/03/2011 04:43 PM, Xan Lopez wrote: > Alternatively, is there some well-known way to reduce either the size > or the processing time for the Makefile in huge automake projects?[1] Have you tried './configure --disable-dependency-tracking' as a way to make automake quit outputting -MP options in the makefile? Since you're already willing to give up the benefits of dependency tracking, you might as well tell that to configure. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: configmake module and automake 1.9.6
[dropping gnulib for this reply]
On 12/14/2010 02:54 PM, Eric Blake wrote:
>>> # Listed in the same order as the GNU makefile conventions.
>>> # The Automake-defined pkg* macros are appended, in the order
>>> # listed in the Automake 1.10a+ documentation.
>>> +# Support newer definitions even when using older automake 1.9.6
>>
>> The Automake version is probably irrelevant here. It's the Autoconf
>> version that matters.
>
> Oh; it's a mix of both autoconf and automake macros (autoconf AC_SUBST's
> localedir, but only automake 1.11 AC_SUBST's pkglibexecdir); the comment
> in modules/configmake only mentioned automake, but both tools have a
> hand in feeding configmake.h.
In fact, I think automake has a minor bug. automake.in lists the
following directories:
my %standard_prefix =
map { $_ => 1 } (qw(bin data dataroot dvi exec html include info
lib libexec lisp localstate man man1 man2 man3
man4 man5 man6 man7 man8 man9 oldinclude pdf
pkgdatadir pkgincludedir pkglibdir pkglibexecdir
ps sbin sharedstate sysconf));
That list is missing 'doc' and 'locale'.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: configmake module and automake 1.9.6
On 12/14/2010 02:33 PM, Bruno Haible wrote:
>>> In configure.ac add:
>>>
>>> dnl Installation directories.
>>> dnl Remove this when you can assume autoconf >= 2.60.
>>> AC_SUBST([localedir], ['${datadir}/locale'])
>
> This is the essential change.
It's also the change that is most likely to cause conflicts if done
incorrectly - that is, we don't want to do this if autoconf and/or
automake is new enough to already cover it.
>
>> But the Makefile.am in question is generated by gnulib. Adding it to
>> the top level won't affect the generation of configmake.h.
>
> Then you could use gnulib-tool's option --makefile-name and include the
> gnulib-generated Makefile.am fragment from your real Makefile.am.
But the whole point of the configmake module is that it should just work
without the user having to specify --makefile-name. At least we can
inject both configure.ac and Makefile.am snippets into the configmake
module.
However, it appears you are right; after testing, I confirmed that the
AC_SUBST edit to configure.ac plus a single mention of $(localedir) in
the gnulib-level Makefile.am (already present, thanks to the configmake
substitutions) is sufficient to get even automake 1.9.6 to automatically
populate $(localedir) = @localedir@, without me having to edit any
Makefile.am.
>
>> # Listed in the same order as the GNU makefile conventions.
>> # The Automake-defined pkg* macros are appended, in the order
>> # listed in the Automake 1.10a+ documentation.
>> +# Support newer definitions even when using older automake 1.9.6
>
> The Automake version is probably irrelevant here. It's the Autoconf
> version that matters.
Oh; it's a mix of both autoconf and automake macros (autoconf AC_SUBST's
localedir, but only automake 1.11 AC_SUBST's pkglibexecdir); the comment
in modules/configmake only mentioned automake, but both tools have a
hand in feeding configmake.h.
>>echo '#define DATAROOTDIR "$(datarootdir)"'; \
>>echo '#define DATADIR "$(datadir)"'; \
>> + echo '#ifndef DATAROOTDIR'; \
>> + echo '# define DATAROOTDIR DATADIR'; \
>> + echo '#endif; \
>
> I would prefer to do this at configure.ac level. Because if a package has
> C code which accesses DATAROOTDIR or LOCALEDIR, chances are high that it
> also has Makefile rules that install files into $(datarootdir) or
> $(localedir).
> The change that you propose handles the C code but not the Makefile.am rules.
Okay, then, I'm back to trying to modify the configmake module's
configure.ac section, in a way that is friendly to the autotools already
providing a definition, and which allows use of these variables
throughout makefiles in addition to C files.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: configmake module and automake 1.9.6
On 12/14/2010 02:10 PM, Bruno Haible wrote:
> Eric Blake wrote:
>> I just ran into an issue where libvirt failed to compile when autotooled
>> with automake 1.9.6, because automake failed to define $(localedir) and
>> therefore gnulib's configmake module did not define LOCALEDIR. Any
>> suggestions on how to make gnulib guarantee $(localedir) will be defined
>> even when using older automake, such as an extra snippet of code to
>> include in Makefile.am, and which will not interfere when using newer
>> automake?
>
> In Makefile.am add:
>
> localedir = @localedir@
>
> In configure.ac add:
>
> dnl Installation directories.
> dnl Remove this when you can assume autoconf >= 2.60.
> AC_SUBST([localedir], ['${datadir}/locale'])
But the Makefile.am in question is generated by gnulib. Adding it to
the top level won't affect the generation of configmake.h.
I'm going for a different approach, I'm in the middle of testing this
(well, expanding it further for fallbacks for all of the variables,
including LOCALEDIR):
diff --git i/ChangeLog w/ChangeLog
index c9c467c..bf7f17b 100644
--- i/ChangeLog
+++ w/ChangeLog
@@ -1,3 +1,9 @@
+2010-12-14 Eric Blake
+
+ configmake: support more values with older automake
+ * modules/configmake (Makefile.am): Provide fallbacks for older
+ automake.
+
2010-12-13 Eric Blake
cloexec, fcntl: relax license
diff --git i/modules/configmake w/modules/configmake
index d826c13..a19f3da 100644
--- i/modules/configmake
+++ w/modules/configmake
@@ -25,6 +25,7 @@ Makefile.am:
# Listed in the same order as the GNU makefile conventions.
# The Automake-defined pkg* macros are appended, in the order
# listed in the Automake 1.10a+ documentation.
+# Support newer definitions even when using older automake 1.9.6
configmake.h: Makefile
$(AM_V_GEN)rm -f $...@-t && \
{ echo '/* DO NOT EDIT! GENERATED AUTOMATICALLY! */'; \
@@ -35,6 +36,9 @@ configmake.h: Makefile
echo '#define LIBEXECDIR "$(libexecdir)"'; \
echo '#define DATAROOTDIR "$(datarootdir)"'; \
echo '#define DATADIR "$(datadir)"'; \
+ echo '#ifndef DATAROOTDIR'; \
+ echo '# define DATAROOTDIR DATADIR'; \
+ echo '#endif; \
echo '#define SYSCONFDIR "$(sysconfdir)"'; \
echo '#define SHAREDSTATEDIR "$(sharedstatedir)"'; \
echo '#define LOCALSTATEDIR "$(localstatedir)"'; \
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
configmake module and automake 1.9.6
I just ran into an issue where libvirt failed to compile when autotooled with automake 1.9.6, because automake failed to define $(localedir) and therefore gnulib's configmake module did not define LOCALEDIR. Any suggestions on how to make gnulib guarantee $(localedir) will be defined even when using older automake, such as an extra snippet of code to include in Makefile.am, and which will not interfere when using newer automake? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: recursive make variables coming to POSIX
[adding the Austin Group; this is in regards to
http://austingroupbugs.net/view.php?id=336, and this email implies that
we may want to tweak the wording and restart the 30-day interpretation
window if it is important to not invalidate existing IRIX behavior]
On 12/05/2010 08:50 PM, Ralf Wildenhues wrote:
> Hi Eric,
>
> * Eric Blake wrote on Thu, Dec 02, 2010 at 08:21:13PM CET:
>> On 12/02/2010 12:10 PM, Ralf Wildenhues wrote:
>>> I'm not sure if it was mentioned before in the discussion, but
>>> portability-wise, there is a difference between one level of recursion
>>> and arbitrary many. IIRC then IRIX make only supported one level, i.e.,
>>> $(var1$(var2$(var3)))
>>>
>>> was erroneous, but
>>> $(var1$(var2))
>>>
>>> was not. Also, with a one-character variable X
>>> $(var$X)
>>>
>>> was erroneous with at least one legacy make implementation (but I think
>>> it was more than one); but
>>> $(var$(X))
>>>
>>> worked.
>>>
>>> If you like, I can go back and verify the details.
>>
>> Yes please, and I will feed that information back to the Austin Group.
>
> Thank you. Here we go. With the following Makefile,
>
> V = v
> V1 = v1
> V11 = v11
> O = 1
> ONE = 1
> O1 = 11
> Vr1 = $(V$(O))
> Vr2 = $(V$(ONE))
> Vr3 = $(V$(Z))
> Vr4 = $(V$O)
> Vr5 = $(V$Z)
> Vrr1 = $(V$(O$(Z)))
> Vrr2 = $(V$(O$(O)))
> Vrr3 = $(V$(Z$(Z)))
> Vrr4 = $(V$(O$Z))
> Vrr5 = $(V$(Z$Z))
> R = R
> Vrrr = $($($($($($($($($($($($($($(R))
> all_FLAGS = bar
>
> all:
> @echo $(Vr1), $(Vr2), $(Vr3)
> @echo $(Vrr1), $(Vrr2), $(Vrr3)
> @echo $(Vrrr)
> @echo $(Vr4), $(Vr5)
> @echo $(Vrr4), $(Vrr5)
> @echo $($...@_flags)
> @echo $($(@)_FLAGS)
>
> the make implementations from
> AIX 5.2, 5.3, 6.1, 7.1
> Darwin 10.4.0 (GNU make 3.81)
> FreeBSD 6.4, 7.1
> GNU
> HP-UX 10.20, 11.00, 11.11, 11.23, 11.31
> NetBSD 5.99.39
> OpenBSD 4.4
> Solaris 2.6, 7, 8, 9, 10
> Tru64 OSF 5.1D
>
> all print:
>
> v1, v1, v
> v1, v11, v
> R
> v1, v
> v1, v
> bar
> bar
>
> IRIX 6.5 make fails over each expansion in output lines 4, 5, and 6,
> e.g.:
>
> v1, v1, v
> v1, v11, v
> R
> UX:make: ERROR: Unmatched closing curly braces or parenthesis in line
> containing:
> $(V$O).
>
>
> The last line containing $($(@)_FLAGS) is wrongly expanded to empty by
> this make.
>
>
> So, in summary, the parenthesization is an issue, and expanding of the
> automatic $@ variable recursively. I haven't tried to determine whether
> there is an upper limit to recursive expansion (should I?).
>
> See also this old thread:
> <http://thread.gmane.org/gmane.comp.sysutils.automake.general/9943/focus=9945>
>
> Cheers,
> Ralf
Thank you, Ralf, for providing this additional research.
Hmm, we also haven't really tested other corner cases, such as ${V${O}}
instead of $(V$(O)) (braces instead of parenthesis), $(V${O}) or
${V$(O)} (mixing braces and parenthesis), or $(V:$(O)=2) (recursive
expansion inside substitutions).
Meanwhile, this may work as an appropriate wording that still permits
IRIX behavior, by stating that recursive expansion is only specified for
parenthesized variables that are not one of the five internal macros (@,
%, ?, <, *), and only when nested with () or {}:
Change line 95800:
"The parentheses or braces are optional if string1 is a single character."
to:
"The parentheses or braces are optional if string1 is a single
character, except when the expansion is nested inside another macro
expansion."
Lines 95801-95802 and 95807-95808 both contain:
"If string1 in a macro expansion contains a macro
expansion, the results are unspecified."
In both cases, replace them with:
"If string1 in a macro expansion contains a macro expansion where the
inner expansion uses parenthesis or braces and is not an internal macro,
that inner macro expansion shall be recursively expanded before use.
Any other form of macro expansion in string1 has unspecified results."
as well as listing in the rationale examples such as $($(@)_FLAGS) and
$(V$O) that are unspecified.
Also, we should probably modify the wording at line 95807 to mention
nested macro expansions in subst1 or subst2, although it will require
more testing of make implementations to determine whether $(V:$(O)=2) is
well-defined or unspecified in practice.
--
Eric Blake ebl...@redhat.com+1-801-349-2682
Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
Re: recursive make variables coming to POSIX
On 12/02/2010 12:10 PM, Ralf Wildenhues wrote: > I'm not sure if it was mentioned before in the discussion, but > portability-wise, there is a difference between one level of recursion > and arbitrary many. IIRC then IRIX make only supported one level, i.e., > $(var1$(var2$(var3))) > > was erroneous, but > $(var1$(var2)) > > was not. Also, with a one-character variable X > $(var$X) > > was erroneous with at least one legacy make implementation (but I think > it was more than one); but > $(var$(X)) > > worked. > > If you like, I can go back and verify the details. Yes please, and I will feed that information back to the Austin Group. It may result in a wording modification and a restart of the 30-day review window (changing the wording proposal to explicitly leave the problematic corner cases unspecified) so that the goal of including the change as part of the technical corrigendum 1 of POSIX 2008 (probably coming by late 2011) will not invalidate existing implementations; or it may result in the Austin Group deferring the change to the next full revision of the standard (several years out) to give those implementations time to comply with a tighter standard. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
recursive make variables coming to POSIX
Good news! Today's Austin Group meeting included a review of http://austingroupbugs.net/view.php?id=336, which is proposing that $(var$(V)) as a way of choosing between $(var0) and $(var1) based on the contents of $(V) be standardized in POSIX. If the 30-day interpretation window starting today does not raise any objections (that is, if no one complains of a counterexample existing make implementation that fails to meet the proposed wording), then automake's silent-make implementation will switch from exploiting unspecified behavior over to using a POSIX-standardized feature. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: Augment instead of replace maude_DEPENDENCIES
On 11/18/2010 12:00 PM, Daily, Jeff A wrote: > Some of my test programs require generated input files - perhaps one per test > program. I want to generate them as dependencies of the particular test > programs which use them. However, I don't want to replace the dependencies > which automake already determines for my test programs. maude_DEPENDENCIES > appears to be the correct way to go, but if I replace what automake generates > automatically, then I have to recreate what automake would have done for me. > > check_PROGRAMS = tests/FillValue > tests_FillValue_SOURCES = tests/FillValue.C > tests_FillValue_DEPENDENCIES = data/FillValue.nc libpagoda.la You're not the first to request this :) > Is my only recourse to replace maude_DEPENDENCIES? That, or build automake from git or wait for 1.12 to be released; from the NEWS: - For programs and libraries, automake now detects EXTRA_foo_DEPENDENCIES and adds them to the normal list of dependencies, but without overwriting the foo_DEPENDENCIES variable, which is normally computed by automake. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: When "aclocal" causes an error message, "sed: invalid option -- 'q'"
On 11/17/2010 09:59 AM, Bruce Korb wrote: >> Is it worth installing a temporary sed wrapper earlier in your PATH that >> outputs debugging information such as the process id of its parent if it >> detects that one of the arguments starts with -q? > > Next time I run into it. I unwound everything I was doing and > started reapplying my changes. Before I get to where it breaks > again, I am having to figure out how to "git push" without > tripping over "fast-forward", whatever that is. 'fast-forward' is the state when your commits are a strict superset of what is on the receiving end (what you want). Your problem is that git is complaining about non-fast-forwards; that is, when your patches and someone else's patches diverge, such that your patches are no longer a superset of the receiving end. The two ways to fix non-fast-forwards are merging and rebasing; automake favors merging for distinct topics and rebasing for work on an existing topic, while gnulib enforces rebasing only by forbidding merging so as to keep a linear history. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: When "aclocal" causes an error message, "sed: invalid option -- 'q'"
On 11/17/2010 08:11 AM, Bruce Korb wrote: >> OK. I don't see where it should come from in Autoconf nor Automake. >> Any case the package at hand contains m4_esyscmd in configure.ac that > ^ >> contains a buggy sed script? If not, please state exact versions of >> autotools programs used, and show autoreconf -v output. > > There's a really good chance of that. > > AC_INIT([GNU libposix], > m4_esyscmd([./git-version-gen .tarball-version]), > [bug-gnu...@gnu.org]) > > $ for f in autoconf automake libtool autoreconf ; do $f --version | head -1 ; > done > autoconf (GNU Autoconf) 2.65 > automake (GNU automake) 1.11.1 > ltmain.sh (GNU libtool) 2.2.6 > autoreconf (GNU Autoconf) 2.65 "git grep 'sed.* -q'" in automake, autoconf, gnulib, and libtool doesn't turn up any culprits. Is it worth installing a temporary sed wrapper earlier in your PATH that outputs debugging information such as the process id of its parent if it detects that one of the arguments starts with -q? -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org signature.asc Description: OpenPGP digital signature
Re: using autoconf with ppuxlc++,spuxlc++
[adding automake, replies can drop autoconf] On 10/26/2010 04:31 PM, John Wohlbier wrote: I searched the mailing list archives for this question and only found one message containing ppuxlc which didn't answer my question. We're trying to use autoconf in a hybrid environment that includes the CellBE. I have a configure.ac for the CellBE PPE core and one for the SPE core. I also have some macros for setting up the compilers and their flags since it appears that AC_PROG_CC and AC_PROG_CXX do not support these compilers. I have what I feel are valid compiler flags for, in this case, ppuxlc++. However, I think I have a problem with the interaction of autoconf/libtool and cannot get my sources to compile. Below is what I see on output. To try and narrow down on the error "ppuxlc++: 1501-208 (S) command option D is missing a subargument" I went through by hand and removed all of the -D arguments, and it still failed. Finally, I removed the -MD argument and it "compiles." Unfortunately I don't know enough about autoconf/libtool to know what the -MD -MP -MF arguments are or where they come from. Can anyone provide any hints or suggestions on how to figure out what is going on? They are used by makefile dependency tracking rules, which is under Automake's domain (the depcomp script, as well as automake rules run at configure time to determine which style of compiler dependency to request of the depcomp script). Thanks. (Sorry if this is more appropriate for the libtool list, but I just don't know and didn't think it was appropriate to cross post.) Actually, you'll probably have better luck on the automake list, since autoconf itself does not touch any -M option. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: POSIX make standardization wish list
[adding the GNU automake list, as an interested party in the current spate of proposals for improving POSIX make; other messages start: http://thread.gmane.org/gmane.comp.standards.posix.austin.general/3102] On 10/15/2010 02:27 AM, tom honermann wrote: Thanks to David Wheeler for pushing for additional standardization of the make utility. As long as we're on the subject, I thought I'd throw out my wish list of features I'd like to see POSIX standardize. GNU Automake would really like to standardize double variable indirection: http://lists.gnu.org/archive/html/automake/2009-04/msg00040.html - To allow to override the silencing at 'make' run time, we use of a makefile construct with recursive variable expansion $(var1$(var2)). This is not specified by POSIX, and so might not be portable to all kinds of 'make' implementations. That means, if your package has the option 'silent-rules' enabled, then even with V=1, a strict POSIX 'make' may barf on this construct. Now, before anyone screams: all 'make' implementations that I could get hold of *do* accept this construct correctly; that includes IRIX 6.5, AIX 4.3.3, Tru64 4.0D, Solaris 2.6, HP-UX 10.20, NetBSD, FreeBSD, OpenBSD, and of course GNU; Also, we tried an alternative implementation that uses only constructs specified in POSIX, but that turned out to be *a* *lot* *less* portable in practice. http://lists.gnu.org/archive/html/automake-patches/2008-12/msg00027.html 2) We replace it with a functionality that is compliant. I thought I finally had an idea to remain compliant: you can legally have macros on the left hand side of macro assignments. For example, you can have foo$(var) = bar where $(var) is evaluated at the time this line is parsed. Of course this allows to pass only one bit of information per $(var). I have reworked the patch a bit to this end; see below. Unfortunately, while this is Posix-compliant AFAICS, it is rather unportable and fails silently with several vendor makes (e.g., IRIX, HP-UX). I haven't found another way yet. If we can't find one, then your choice of $(var1$(var2)) is certainly better than nothing, in combination with (1). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: what is $ac_t ?
On 09/17/2010 11:05 AM, Eric Blake wrote: [adding automake] On 09/17/2010 11:01 AM, Eric Blake wrote: checking for getrlimit declaration... (cached) install-shextern int getrlimit (enum __rlimit_resource, struct rlimit *); Hmm, on looking at this closer, I only fixed config.status, which happens towards the end of configure, but you are quoting a line that occurs before config.status is created. Aha, I found another instance. My first 'git grep' was for 'ac_t=', but by looking for 'for ac_t', I found that Automake is the other culprit that is stomping on autoconf's namespace and also polluting the ac_t variable. Patch to automake coming up shortly... Or not. It appears this is coming from autoconf after all (sorry for the implication); autoconf commit d30a7f66 in Dec 2009 removed another use of $ac_t, so autoconf 2.62 through 2.65 set it to install-sh, but 2.66 and onwards no longer corrupt $ac_t in the manner you described. No further patches needed. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: what is $ac_t ?
[adding automake] On 09/17/2010 11:01 AM, Eric Blake wrote: checking for getrlimit declaration... (cached) install-shextern int getrlimit (enum __rlimit_resource, struct rlimit *); Hmm, on looking at this closer, I only fixed config.status, which happens towards the end of configure, but you are quoting a line that occurs before config.status is created. Aha, I found another instance. My first 'git grep' was for 'ac_t=', but by looking for 'for ac_t', I found that Automake is the other culprit that is stomping on autoconf's namespace and also polluting the ac_t variable. Patch to automake coming up shortly... -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: [PATCH] nds32: add nds32 support into config_sub
On 09/06/2010 06:03 AM, Macpaul Lin wrote: NDS32 is a new 32-bit RISC architecture invented by Andestech.com. This is the commit for supporting automake and related config.sub. Thanks for the patch. However, as documented in config.sub itself, you need to send this upstream to config-patc...@gnu.org; automake will then automatically pick this up once it is accepted upstream. And make sure you also check whether config.guess needs a matching patch. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: Automake and Texinfo: clean the info or pdf file
On 09/03/2010 11:07 AM, Stefano Lattarini wrote: Why the Makefile is removed when I call the distclean target? Because it is generated by configure And more particularly, because Makefile is machine-dependent and must NOT be part of a tarball. Remember, 'make distclean' is the process to take you back to the state of the tarball. So why we choose to keep the *.info files if they are generated files? Because they require a maintainer-only, unportable tool to be generated. And since they do not depend on the architecture or configuration of the system were they will be installed, the best policy is to distribute them in their already-processed form. Indeed, since *.info files are machine-invariant, it is a courtesy to the user to let them use a pre-built version rather than requiring that they have the same maintainer-only tools for generating them. The same argument goes for *.c files generated from *.y grammars - the *.c file may be generated, but it is machine-independent, therefore, it makes sense to distribute it pre-built in the tarball so that users need not have flex and bison available. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: Automake and Texinfo: clean the info or pdf file
On 08/31/2010 11:54 AM, Eric Blake wrote: make default target /creates/ files in the source directory? Yes, in the maintainer's tree. One other point - it is assumed that the maintainer's tree is _never_ read-only (that is, a maintainer rule that modifies srcdir is fine). Otherwise, how are you maintaining anything? Read-only srcdir applies _only_ to end user setups, and 'make distcheck' does a good job of separating maintainer issues (the 'make dist' portion) from the end user issues (the VPATH 'make check' build from a read-only srcdir portion). -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: Automake and Texinfo: clean the info or pdf file
On 08/31/2010 11:46 AM, Steffen Dettmer wrote: On Mon, Aug 30, 2010 at 7:54 PM, Ralf Wildenhues wrote: * YuGiOhJCJ Mailing-List wrote on Mon, Aug 30, 2010 at 05:41:40PM CEST: I work on a project which use automake and include a documentation in Texinfo format. If I call : $ make The .info file is built. In the source tree (right?). And it will be distributed (with 'make dist'). make default target /creates/ files in the source directory? Yes, in the maintainer's tree. But isn't this wrong and verified by making srcdir read-only in `make distcheck'? No, it is not wrong, and yes, it is verified by 'make distcheck'. Remember, the key point is that if it is distributed in the tarball, then it MUST be made in srcdir (not builddir), and although the _maintainer_ may have rules to build it, the _end user_ should not have to build it. 'make distcheck' is from the end user's perspective - did all the files get included in the tarball, and with appropriate timestamps that prevent a rebuild? A read-only srcdir works in this case, because the rules to rebuild the .info files are not run. Wouldn't this break things (e.g. in VPATH leading to a .info in src and builddir?)? No - provided that it lives ONLY in the srcdir, then VPATH isn't confused. The confusion happens if you try to stick it in builddir and then distribute it. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
Re: linux to windows cross compile af a dll
[adding libtool] On 08/24/2010 10:42 AM, Joost Kraaijeveld wrote: *** Since this library must not contain undefined symbols, *** because either the platform does not support them or *** it was explicitly requested with -no-undefined, *** libtool will only create a static version of it. It seems to be related to http://ricardo.ecn.wfu.edu/~cottrell/cross-gtk/libtool.html Is the hack that is mentioned necessary or is there another solution? This seems like it is a question more appropriate for the libtool list. -- Eric Blake ebl...@redhat.com+1-801-349-2682 Libvirt virtualization library http://libvirt.org
