Dear automake maintainers,
I recently upgraded Automake from 1.11.1 to 1.14 using MacPorts on my
mac running OSX 10.6.
Since the upgrade the script "configure" in my project gets clobbered in
the distdir when running "make dist": size 0, executable bit removed.
All other
Hello. When I crosscompiled some app I had to patch some file generated by
autoreconf -i, where I have to add thumbv7[arm] (using the analogy to
armv7[arm] already present there) there. Though I haven't found the source file
corresponding to it, so no patches. Feel free to fix yourselves.
Hi,
in commit
https://git.savannah.gnu.org/cgit/automake.git/commit/m4/python.m4?id=ed8daa069a6c8ed34f7856c42402ec46f305e670
line 160 of python.m4
you changed the sed command so that am_cv_python_pythondir does not
contain the content of $PYTHON_PREFIX anymore but the variable name
$PYTHON_PR
ed to change. A previous setting in the Makefile.am should yield
the value of PYTHON_PREFIX to be substituted.
The documentation mentions in several places that the variables set by
Automake are only really designed to be used in the Makefiles that it
generates. Using AC_SUBST to directly subst
ed to change. A previous setting in the Makefile.am should yield
the value of PYTHON_PREFIX to be substituted.
The documentation mentions in several places that the variables set by
Automake are only really designed to be used in the Makefiles that it
generates. Using AC_SUBST to directly subst
Hi!
I download https://ftp.gnu.org/gnu/automake/automake-1.16.5.tar.gz
and compiled it. I have several tests failed in `make check ` command
Most of them are marked with # TODO long-standing limitation
but there are several other failed tests
I configured installation with non-statndard path
In Docker(in the vmware ubunt also has the problem):
Environment:
Ubuntu 20.04 5.15.0-78-generic.
Automake1.4 from ftp://gcc.gnu.org/pub/java/automake-gcj-1.4.tar.gz.
root@576a62413a36:~/automakeOut# automake --version
syntax error at /usr/local/bin/automake line 932, near "
e done.
I don't have Python 3.10 or Ubuntu/Debian, but maybe I'll play with
this anyway, I'll see. It may be a bit of a guessing game with more
than 1 attempt. Fortunately, it's "just" the test that's failing
because the paths are different and it&#
Hello.
Referring to the discussion related to the upcoming release, I
confirm defect #64837 on Debian GNU/Linux 12 (bookworm) and I confirm
that the last patch in #54412 (the one attached in the defect in
Message#14 - https://debbugs.gnu.org/cgi/bugreport.cgi?bug=54412#14,
not the one inlined) f
_SOURCES.
https://www.gnu.org/software/automake/manual/automake.html#Sources
that var is meant for generating headers before Automake's depgen logic
can kick in. that sounds minor, but in practice it means that every
built source is generated before anything else is compiled. which can
insert a
Mike Frysinger , 2024-01-13 07:19:
On 15 Mar 2023 17:31, Bogdan wrote:
Another patch from my side. This one makes it possible for users to
pass additional options to libtool in 'compile' mode. Fixes #54020.
Added documentation and a test case including the '-no-suppress'
option. All tests
Mike Frysinger , 2024-01-14 02:06:
On 13 Jan 2024 22:29, Bogdan wrote:
Mike Frysinger , 2024-01-13 07:19:
On 15 Mar 2023 17:31, Bogdan wrote:
Another patch from my side. This one makes it possible for users to
pass additional options to libtool in 'compile' mode. Fixes #54020.
Added d
Mike Frysinger , 2024-01-17 06:04:
On 14 Jan 2024 18:55, Bogdan wrote:
Mike Frysinger , 2024-01-14 02:06:
On 13 Jan 2024 22:29, Bogdan wrote:
Mike Frysinger , 2024-01-13 07:19:
On 15 Mar 2023 17:31, Bogdan wrote:
Another patch from my side. This one makes it possible for users to
pass a
Hello.
The attached patch fixes the tests for Python 3.12 (and, hopefully
later ones), while still keeping them working for earlier versions.
A simple fix. Could perhaps be written better (like in a single
Python script), but this is enough.
--
Regards - Bogdan ('bogdro') D. (G
Hi.
I have access to just Linux and SunOS and cannot reproduce the error
(the tests pass), but Karl's solution seems reasonable and shouldn't hurt.
Attaching a simple patch which (hopefully) fixes the issue. At
least, it doesn't hurt Linux or SunOS, so it shouldn't make things
worse. Feel free
Hello, Bruno.
Thank you for your testing.
About your defect:
1) t/objcxx-* - may need our attention,
2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from it) prior to running the test?
3) t/yacc
Hello, Bruno.
Thank you for your testing.
About your defect:
1) t/objcxx-* - may need our attention,
2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from it) prior to running the test?
3) t/yacc
Bruno Haible , 2024-02-19 01:33:
Hello Bogdan,
Thank you for dealing with the Automake support.
Thank you for testing :)
2) t/strip2 - could you check if you have the STRIPPROG environment
variable set and, if yes, unset it (or, at least, remove the
"--verbose" parameter from
s not added to the
command line, making the test fail during linking.
Yes, 'c++' works as an Objective-C++ compiler:
How interesting. Especially that it compiles, but doesn't link.
[...]
$ c++ -c hello.mm
$ c++ hello.mm
[3 link errors, due to undefined symbols.]
What Autoc
when STRIP consists of more than one word.
-# This test needs GNU binutils strip. See sister test 'strip3.sh'.
+# See sister test 'strip3.sh'.
required='cc strip'
. test-init.sh
@@ -39,7 +39,7 @@ $ACLOCAL
$AUTOCONF
$AUTOMAKE -a
-./configure --prefix="$(pwd)/inst" STRIP='strip --verbose'
+./configure --prefix="$(pwd)/inst" STRIP='strip -x'
$MAKE
$MAKE install-strip
--
2.35.1
Hello.
Thank you for reporting the issue.
The attached patch should fix the problem. It may be a bit of an
overkill, perhaps just one of the fixes would suffice, but it seems to
work at least.
I've re-made your useful script into an Automake test. Since
non-deterministic defects may be ha
Hello.
Thank you for reporting the issue.
I believe I have fixed the defect. The attached patch assumes that
"no-dist-built-sources" is the right option name, following the
documentation and the Options.pm file.
Automake itself has been changed to process the option correctly,
dist
Hi.
I've just noticed that bug #68860 (patched) may be a duplicate of
#26471. Different descriptions and error messages, but looks like the
same cause.
--
Regards - Bogdan ('bogdro') D. (GNU/Linux & FreeDOS)
X86 assembly (DOS, GNU/Linux):http://bogdro.evai.pl/index-en.php
Sof
Karl Berry , 2024-08-25 10:45:
Thanks much, Bogdan.
-recheck: all %CHECK_DEPS%
+recheck: all-am %CHECK_DEPS%
Do you have a grip on all-am? Looking at handle_all in bin/automake, I
admit I remain baffled as to what all those pieces of all-am are, and
why it's done as it is.
Karl Berry , 2024-08-25 19:17:
> - $output_rules .= "check-am: all-am\n";
> + $output_rules .= "check-am: all-am";
> if (@check)
> {
> - pretty_print_rule ("\t\$(MAKE) \$(AM_MAKEFLAGS)", "\t ",
@check);
> + $output_
Good morning,
GNU Astronomy Utilities (Gnuastro) uses GNU Autotools. A Gnuastro
developer encountered the "Numeric user ID too large" error when
generating a tarball with the 'make dist' command on his macOS (Monterey
12.3) laptop. His user id is an integer with 9 digits, which is too big
for
Hi Karl,
thanks for the detailed answers.
We've run few more tests, and we've found a couple more issues.
1. As you pointed out, TAR_OPTIONS is working fine from the command
line, but it doesn't work when written inside Makefile.am, neither on
Mac, nor on Linux.
$ TAR_OPTIONS="--version"
$ ex
t/bw/include'
hint=recommended
useposix=true
d_sigaction=define
useithreads=undef
usemultiplicity=undef
use64bitint=define
use64bitall=define
uselongdouble=define
usemymalloc=n
default_inc_excludes_dot=define
bincompat5005=undef
Compiler:
alpha$
Just c
I tested automake-1.16.2 in a fresh build on top of autoconf-2.69b
(latest beta). Instead of all automakes tests passing or skipping,
as happened with autoconf-2.69, I now have 2 new failures (but
autoconf now has zero failures, which is a big improvement).
Already reported to autoconf (with
I've recently started using automake with Vala; it works very well! I'm
particularly impressed that the "make dist" rules include the C files, so
that the builder doesn't need a Vala compiler.
There's one nit: I want to make multiple .c files from the same .vala f
---
contrib/README | 35 ---
1 file changed, 16 insertions(+), 19 deletions(-)
diff --git a/contrib/README b/contrib/README
index a4d7eeb8d..f43e1da9b 100644
--- a/contrib/README
+++ b/contrib/README
@@ -1,26 +1,23 @@
This is the 'contrib' directory of the GN
On Thu, 15 Oct 2020 at 13:06, Reuben Thomas wrote:
> I've recently started using automake with Vala; it works very well! I'm
> particularly impressed that the "make dist" rules include the C files, so
> that the builder doesn't need a Vala compiler.
>
>
I'm sorry, I see this question is covered in the manual:
Note that currently, you cannot use per-target ‘*_VALAFLAGS’ (*note
> Renamed Objects::) to produce different C files from one Vala source
> file.
>
Feel free to close this issue!
On Thu, 15 Oct 2020 at 22:09, Karl Berry wrote:
>
> I found some long-ago patches (not for this particular issue) from a
> previous contributor (Daniel Espinosa), which surely worked at the time
> they were written, but now break things. And Daniel stopped replying to
> my mail. Sorry to be so va
Attached, a patch to improve valac version detection. The vala compiler,
valac, can report the API version it supports. For releases, this is the
same as the major & minor version of the compiler, so for example:
$ valac --version
Vala 0.48.11
$ valac --api-version
0.48
The advantage of using the
Sorry, I simply failed to update the test; I noticed a failure message, and
didn't understand it. Simply lack of effort on my part, apologies.
I attach an updated patch, which now also patches the test to account for
the new mode of operation (checking --api-version not --version) and
updated erro
I've had a look at the patch now, and found and fixed one bug.
However, an issue comes up for VPATH builds that needs a more thorough fix:
C files generated from Vala sources are shipped by "make dist" and hence
end up in srcdir, but in a VPATH build with a Vala compiler, they will be
in builddir.
opies the file
there if it is newer than the corresponding .vala file.
Having worked on this patch, I do wonder whether the hacks involved are
worth it. It seems to me there are two sensible options:
1. Add more support to automake for files that can be either generated or
distributed. (Have I ov
t would certainly streamline Vala support in automake.
Also, being frank, removing "Vala-generated-C" support is the only way I
would offer to have anything to do with making such a patch, as (as far as
I can see) that route would be much simpler than retaining the current
support (even in
To follow up clearly: if it were up to me, I'd install an acceptable
version of my patch, as it improves the status quo, and include it in the
next release. Then I'd think about whether it's possible to redo the Vala
support entirely.
--
https://rrt.sc3d.org
On Fri, 30 Oct 2020 at 01:45, Karl Berry wrote:
> install an acceptable version of my patch, as it improves the status
> quo, and include it in the next release. Then I'd think about
> whether it's possible to redo the Vala support entirely.
>
> Sounds sensible.
>
> I applied your cha
I'm trying to port a project to docker and I'm also testing it on my
Raspberry Pi 3B+
when I *./configure* and *make* the project, it fails with this message
gcc: error: unrecognized -mcpu target: armv7l
gcc: note: valid arguments are: arm8 arm810 strongarm [...] cortex-a53 [...]
gcc: error: miss
Or, bug #11347 again.
I just spent quite a while chasing down a test failure that was due to
testsuite-part.am not being remade when new tests were added.
I duly found bug #11347, which contains a rationale for not having
testsuite-part.am depend on all the tests.
However, the rationale doesn't
If your current directory path contains a space then Automake creates an
invalid site.exp file. The problem is in the following code placed into
Makefile.in:
@echo 'set srcdir "$(srcdir)"' >>site.tmp
@echo "set objdir `pwd`" >>site.tmp
2, Karl Berry wrote:
> Reuben - any chance you can look into this vala failure?
>
> It seems that, (only) in the make distcheck done inside the test, the .c
> files are not remade from the .vala?
>
> Thanks,
> Karl
>
>
> Date: Fri, 20 Nov 2020 22:25:55 +0100
> From
On Sat, 21 Nov 2020 at 22:01, Karl Berry wrote:
>
> By the way, I don't think that find command (or the cp -p for that
> matter) is excessively portable. But I guess we don't much care about
> crufty systems for vala support. --thanks, karl.
>
They are both using only POSIX-2008 features; these
The example filename "zardoc.c" in the Vala section should be "zardoz.c";
it doesn't really matter, but it is almost certainly a typo.
--
https://rrt.sc3d.org
There doesn't seem to be a way for the user to configure a different ctags
program, unless I'm overlooking something? Passing "CTAGS=foo" to configure
has no effect; it seems that all one can do is pass "CTAGS=foo" to make
every time one runs "make tags".
--
https://rrt.sc3d.org
On Thu, 3 Dec 2020 at 22:17, Karl Berry wrote:
> Hi Reuben,
>
> There doesn't seem to be a way for the user to configure a different
> ctags program
>
> I don't know of anything to the contrary. So ... would you be up for
> making a patch to support it :)? Etags too, I guess? At least the
I just noticed while updating to look at something else that a version of
my patch seems to have been applied, but with a misleading commit message.
It has my name on it, commit 7581ec208. But I don't think I had anything to
do with that commit!
The commit log says: "reverse -newer test". But it
On Fri, 4 Dec 2020 at 22:20, Karl Berry wrote:
> You sent the proposed change in the bug report to Bruno, so I committed
> it in your name.
>
Sorry, I didn't mean to say I had nothing to do with the contents of the
patch, just that I didn't have anything to do with installing it. (And I
wasn't a
On Thu, 3 Dec 2020 at 22:26, Reuben Thomas wrote:
>
> Happy to look into it.
>
I have looked into it and attach a trivial patch, which works nicely.
It's not obvious to me whether any documentation is required; I rather
expected that these variables would behave like others (CC, CXX etc.). I've
Subject: obscure bug "extern void free (void *__ptr) __attribute__
((__nothrow__ , __leaf__));"
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -march=x86-64 -mtune=generic -O2 -pipe -fno-plt
-DDEFAULT_PATH_VALU
The source of the problem is that /dev/null was a regular file on my system.
I checked against this before filing the bug, but not in proper ways.
I am sorry for the inconvenience.
is a patch courtesy of Dirk Müller.
Josef
--- automake-1.16.3/bin/automake.in
+++ automake-1.16.3/bin/automake.in
@@ -2388,7 +2388,7 @@
$var->requires_variables ("\@${lt}LIBOBJS\@ used", $lt . 'LIBOBJS')
if ! keys %libsources;
- foreach my $iter (keys %libsources)
.m4' from
'/opt/local/share/aclocal/ax_cxx_compile_stdcxx_11.m4'
aclocal: installing 'm4/ax_require_defined.m4' from
'/opt/local/share/aclocal/ax_require_defined.m4'
aclocal: error: too many loops
aclocal: Please contact .
at /opt/local/share/automake-1.16/Automake/Channels.pm line 655
lf-tests is a good one. However I reach the same conclusion as Bruno,
that having a module like valgrind-tests is probably not the best way to
solve it. To me, having a timeout seems like an essential feature of a
self-test framework. I know automake isn't primarily a self-test
framework,
of a Scheme compiler used as a build tool; thanks to
> Turing-completeness of Scheme macros, such a build may not terminate).
This makes me believe even stronger that the functionality ought to be
provided by automake natively -- it seems the desired functionality is
not only timeouts for self-tes
severity 48113 wishlist
retitle 48113 Self-test timeout functionality
thanks
Karl Berry writes:
> What do bug-automake people think?
>
> For myself, I have no objection to sprinkling timeout commands through
> the Automake test infrastructure wherever appropriate. It's no
On Sun, May 9, 2021 at 9:28 PM Karl Berry wrote:
>
> Ei Eric,
>
> Automake::ChannelDefs::prog_error("too many loops") called at
> /opt/local/bin/aclocal line 1187
>
> I've never seen that error before. The comment in aclocal where the
> check i
I'm one of the maintainers of the c-ares project at
https://github.com/c-ares/c-ares and have had a couple of users report
this issue. At first glance it appears to be an issue introduced
between automake 1.16.1 and 1.16.3.
I actually did some testing on MacOS 11.4 with automake 1.16.
On 8/17/21 1:06 PM, Nick Bowler wrote:
On 2021-08-17, Brad House via Bug reports for Automake
wrote:
I'm one of the maintainers of the c-ares project at
https://github.com/c-ares/c-ares and have had a couple of users report
this issue.
I took a quick glance and I found this:
lly a bug in the latest
ax_code_coverage.m4 that quotes AC_MSG_ERROR() which causes older
autoconf/automake versions to barf.
https://github.com/c-ares/c-ares/commit/3883d99b05a845e4b40fc25c43ca83db70f4f20f#diff-fe38622a6c742be1bb93e6e65a0728f659114b3dc8d88172cb8844fa963418f9
I'm not sur
I download https://github.com/crosstool-ng/crosstool-ng.git and try to build
it under cygwin and get error automake-1.16: error: unrequested trace '$n'
(1j0/cygdrive/c/Users/feelus/_repos/_foreign)--0---(feelus@feelus-PC@23:53)
[503] $ git clone --depth 1 --config core.auto
On 2/20/22 14:00, Mike Frysinger wrote:
On Fri, 26 Jul 2013 11:32:18 -0400, Diab Jerius wrote:
The fort5 test fails on Mac OS X 10.6.8.
the failing part of the log:
/bin/sh ./libtool --tag=FC --mode=link gfortran -g -O2 -o libhello.la
-rpath /usr/local/lib foo.lo bar.lo libgoodbye.la
li
I'm using automake 1.16.5. The advice about how to disable the "dvi" target
doesn't seem to work.
In the manual it says:
To make ‘dvi’ into a do-nothing target, see the example for
‘EMPTY_AUTOMAKE_TARGETS’ in *note Third-Party Makefiles::.
If I have:
EMPTY_AUTOMAKE_
On Sat, 7 Jan 2023 at 08:46, Nick Bowler wrote:
>
> This example in the manual is talking about writing a custom
> Makefile, *without* using Automake, that you want to recurse
> into using Automake's SUBDIRS feature.
>
Aha! Thanks for pointing this out. I think the man
On Sun, 8 Jan 2023 at 00:23, Karl Berry wrote:
> How does this change to the doc look? --thanks, karl.
>
Thanks for this Karl; it certainly fixes the problem I had! (I'll leave the
assessment of technical accuracy to others.)
--
https://rrt.sc3d.org
over the bug ? we'd want to write a test for it so we
> can be sure it doesn't fail again.
No, I don't have one. It just crossed my eyes while working on more
silent rules in Automake. I made Ben recently aware of these changes,
which are availalbe here:
https://github.com/
On Mon, Jan 23, 2023 at 3:29 PM Zack Weinberg wrote:
>
> On Mon, Jan 23, 2023, at 4:38 AM, Bert Wesarg via Bug reports for Automake
> wrote:
> > On Fri, Jan 13, 2023 at 6:58 AM Mike Frysinger wrote:
> > No, I don't have one. It just crossed my eyes while working o
, Jan 24, 2023 at 7:06 AM Bert Wesarg wrote:
>
> On Mon, Jan 23, 2023 at 3:29 PM Zack Weinberg wrote:
> >
> > On Mon, Jan 23, 2023, at 4:38 AM, Bert Wesarg via Bug reports for Automake
> > wrote:
> > > On Fri, Jan 13, 2023 at 6:58 AM Mike Frysinger wrote:
&g
I have an automake project with a 'po' subdirectory whose contents,
including Makefile.in.in, is entirely generated by gettext. 'po' is in my
top level Makefile.am's SUBDIRS.
When I add an AM_EXTRA_RECURSIVE_TARGETS entry, say 'foo', automake tries
to recurse in
I found the "Rules-*" feature of gettext to do this; sorry for the noise!
--
https://rrt.sc3d.org
Using automake 1.16.5, in my Makefile.am, I have the following lines:
noinst_LTLIBRARIES = liba2ps.la
liba2ps_la_LDFLAGS = $(LIBGC_LIBS)
liba2ps_la_SOURCES = $(liba2pssources) $(libitsources) $(mylibitsources)
liba2ps_la_LIBADD = ../lib/libgnu.la $(LIBINTL) $(LIBSOCKET)
$(GETHOSTNAME_LIB
On Sun, 5 Feb 2023 at 06:09, Nick Bowler wrote:
>
> What Automake is trying to tell you is that LDFLAGS is meaningless
> on a static library. This message could definitely be improved!
>
Of course, thanks! I was confused because in another Makefile.am that had
only a static libra
I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do a
parallel build (in my case, MAKEFLAGS=-j4), I get build failures sometimes:
$ make all
make all-am
make[1]: Entering directory '/home/rrt/.local/var/repo/a2ps/src'
YACC parsessh.c
CC libparse_
On Wed, 12 Apr 2023 at 16:17, Reuben Thomas wrote:
> I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do
> a parallel build (in my case, MAKEFLAGS=-j4), I get build failures
> sometimes:
>
In fact, I don't need to do a parallel build, just build serially
On Wed, 12 Apr 2023 at 17:59, Reuben Thomas wrote:
> On Wed, 12 Apr 2023 at 16:17, Reuben Thomas wrote:
>
>> I am bootstrapping GNU a2ps git master[1] with automake 1.16.5. When I do
>> a parallel build (in my case, MAKEFLAGS=-j4), I get build failures
>> sometimes:
>
On Sun, 3 Dec 2023 at 03:47, Mike Frysinger wrote:
> >
> > I think I've worked it out: I need to add the .c file that is generated
> > from the .y file, not the .h file, to BUILT_SOURCES. Certainly, doing
> that
> > fixes the problem.
>
> we prob could add a .y/.l example to the manual. i think
On Wed, 6 Dec 2023 at 23:59, Karl Berry wrote:
> Any chance that one of you could write a patch for the manual to explain
> whatever needs to be explained (better)? --thanks, karl.
>
I'd happily do that if I could work out, or someone could explain, exactly
what's going on here.
The manual curr
On Sat, 9 Dec 2023 at 00:03, Karl Berry wrote:
> The manual currently says: "You should never explicitly mention the
> intermediate (C or C++) file in any `SOURCES' variable; only list
> the source file."
>
> I don't know the code here, and this probably wasn't the question, but I
> t
istribution that is made. That way the user
@@ -6359,11 +6360,11 @@ What Automake cannot guess, though, is where this header will be used:
it is up to you to ensure the header gets built before it is first
used. Typically this is necessary in order for dependency tracking to
work when the he
GCC developers have recently found a source of non-determinism in
automake; this is bad for reproducible builds:
-- Forwarded message -
From: Jakub Jelinek
Date: Mon, Apr 15, 2024 at 8:43 AM
Subject: [PATCH] gotools: Workaround non-reproduceability of automake
To: Ian Lance
.
>
> Looking at automake.in, it's not obvious to me where a list is failed to
> be sorted. Those -local targets aren't generated by automake itself, so
> far as I can see. --thanks, karl.
>
generate C preprocessor directives, I have to do
conditional inclusion at build time some other way. So, I am doing it by
using automake conditionals.)
With current automake, something like the following Makefile line is
generated:
$(builddir)/libenchant_la_vala.stamp: api-windows.vala api-posix.vala
On Wed, 24 Apr 2024 at 22:57, Reuben Thomas wrote:
>
> The patch is trivial, so hopefully it's obvious if there's a problem for
> some reason! I hope I explained well enough what problem I'm trying to
> solve.
>
Apologies, I should have run the tests before posting the patch. Indeed, I
have brok
Reuben Thomas
Date: Wed, 24 Apr 2024 22:41:48 +0200
Subject: [PATCH 2/2] vala: do not build Vala sources excluded by automake
conditionals
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
* bin/automake.in: make the _vala.stamp file depend on the relevant
On Sat, 27 Apr 2024 at 00:53, Karl Berry wrote:
> Reuben, any chance you can whomp up a test for this patch?
>
No problem, I will do this when I can find a moment. Since I don't actually
need this fix after all, it may not be quick!
--
https://rrt.sc3d.org
compiler optional. But I think this is a great feature of
Automake's Vala support! (Certainly, I believe it is unique.)
So if Automake had in future a mode where it shipped only Vala sources,
then in that mode it would make sense to conditionally-include Vala
sources, and that would work.
he @code{_LDFLAGS} variable for the program.
@cindex Vala Support
@cindex Support for Vala
-Automake provides initial support for Vala
-(@uref{https://www.vala-project.org/}).
-This requires valac version 0.7.0 or later, and currently requires
-the user to use GNU @command{make}.
+Automake sup
On Wed, Aug 28, 2024 at 6:43 PM Karl Berry wrote:
>
> Hi Eric,
>
> Subject: bug#72852: Testsuite summary for GNU Automake 1.17 on
> x86_64-apple-darwin20.6.0
>
> Thanks for the report. It looks like Apple's compiler, or linker, or
> something, is leaving n
On Tue, Sep 10, 2024 at 6:46 PM Karl Berry wrote:
>
> Hi Eric - I've just committed a change that I hope fixes the version
> number problem. (See https://bugs.gnu.org/72157)
>
> However, looking at your list of failures, I see that some of them are
> still about *.dSYM, now relating to distclean.
On Tue, Sep 10, 2024 at 10:59 PM Eric Gallager wrote:
>
> On Tue, Sep 10, 2024 at 6:46 PM Karl Berry wrote:
> >
> > Hi Eric - I've just committed a change that I hope fixes the version
> > number problem. (See https://bugs.gnu.org/72157)
> >
> > However, looking at your list of failures, I see t
On 11/21/24 12:56, Nick Bowler wrote:
CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know
the content is safe.
On 2024-11-20 21:56, Li, Changqing via Bug reports for Automake wrote:
The failure is
Collin Funk cited me:
> As Bruno Haible said in a Gnulib thread [1]:
>
> > "#!/usr/bin/env perl" does not work on GuixSD (where the only program
> > that has a hardcoded file name is /bin/sh; there is no /usr and no
> > /bin/env on this distro).
>
> So I don't think it would work in this case.
>
Nick Bowler wrote:
> The Linux program loader expects to find a newline in the first 128
> bytes of the file (increased to 256 in recent versions), otherwise
> you will get an ENOEXEC error from execve.
My testing indicates:
The first line which specifies the interpreter and interpreter args is l
Kirill Makurin wrote:
> I applied patches and they work for Msys2.
>
> I also tested it with (what I assume is) "Msys-based MinGW"
> (https://osdn.net/projects/mingw/) and it fails. Its `uname -s` reports
> `MINGW32_NT-6.2` and it has `MSYSTEM` set , and it lacks `cygpath`.
> ...
> I explicitly
Kirill Makurin wrote:
> The installer from https://osdn.net/projects/mingw/ is the same as
> found in https://sourceforge.net/projects/mingw/ (except for possible
> difference in versions) and the Wikipedia article points to the former
> website (mingw.org website is no longer alive). This installe
Kirill Makurin wrote:
> I was going to just say that this patch is good and go ahead with it, but I
> decided to check it and turns out it fixes this issue only partially, but the
> patch itself is good.
>
> Msys2 has multiple environments (see
> https://www.msys2.org/docs/environments/) and th
Karl Berry wrote:
> Kirill (cc'd) proposed setting the MSYS2_ARG_CONV_EXCL envvar in the
> compile script which comes from Automake, to avoid a double-conversion.
> See his report in the first msg here, and the final suggestion in the last:
> https://debbugs.gnu.org/cgi/bugrep
1 - 100 of 115 matches
Mail list logo
