Hi,
Should autoconf build from tarball without help2man? I built a tarball
of git master with 'make dist' but when I attempt to build that on
another system it fails if help2man isn't present. Shouldn't this be a
requirement only for the git builds? 2.69 doesn't have this behaviour.
Cheer
On 14/03/2020 01:03, Paul Eggert wrote:
On 3/13/20 3:42 PM, Ross Burton wrote:
Should autoconf build from tarball without help2man?
Yes, it should.
Can someone else verify that this is working? For me a tarball built
from git master refuses to build without help2man installed.
Ross
On 14/03/2020 16:05, Paul Eggert wrote:
On 3/14/20 2:36 AM, Ross Burton wrote:
On 14/03/2020 01:03, Paul Eggert wrote:
On 3/13/20 3:42 PM, Ross Burton wrote:
Should autoconf build from tarball without help2man?
Yes, it should.
Can someone else verify that this is working?
I said that it
Hi,
So I kicked off a world build in OpenEmbedded with autoconf master as of
this morning. Of note is that Flex and Nasm are both failing in similar
ways with autoconf post-2.69:
nasm:
checking for uintptr_t... yes
./configure: line 6400: syntax error near unexpected token `do'
./configure: l
On 18/03/2020 14:36, Zack Weinberg wrote:
Could you please file issues in the Savannah bug tracker
(https://savannah.gnu.org/support/?func=additem&group=autoconf) for
this and any other problems you find? This will ensure that I don't
forget about them.
Filed https://savannah.gnu.org/support/in
Hi,
libSDL2 configures fine with autoconf 2.69 but fails with git master:
| checking for stdio.h... yes
| checking for stdlib.h... yes
| checking for stddef.h... yes
| checking for stdarg.h... yes
| checking for malloc.h... yes
| checking for memory.h... yes
| checking for string.h... yes
| che
Hi,
When I heard that there were plans to release a new autoconf I decided
to spend a little time rebuilding OpenEmbedded Core with it. OE is a
little special in that apart from a few special cases we autoreconf
*everything* that uses autotools.
So far I've built the bulk of oe-core with a
Hi,
One of the patches we do carry that I'd like to see upstreamed is the
support for multiple files in CONFIG_SITE. Now I'm not just sending the
patch we have as it's pretty horrible:
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/autoconf/autoconf/config_site.pat
Hi,
Using autoconf 2.69c (upgrading from 2.69b meant we could drop two
patches, so that's good news!) to build gmp fails in a rather
mysterious way:
| autoreconf: export WARNINGS=cross
| autoreconf: Entering directory '.'
| autoreconf: configure.ac: not using Gettext
| autoreconf: running: acloca
Yep, that fixes it.
Ross
On Tue, 13 Oct 2020 at 20:26, Nick Bowler wrote:
>
> On 13/10/2020, Ross Burton wrote:
> > Hi,
> >
> > Using autoconf 2.69c (upgrading from 2.69b meant we could drop two
> > patches, so that's good news!) to build gmp f
20:51, Ross Burton wrote:
>
> Yep, that fixes it.
>
> Ross
>
> On Tue, 13 Oct 2020 at 20:26, Nick Bowler wrote:
> >
> > On 13/10/2020, Ross Burton wrote:
> > > Hi,
> > >
> > > Using autoconf 2.69c (upgrading from 2.69b meant we could drop tw
No it's the # in the URL. Simply removing #libidn2 fixes this problem.
Presumably some quoting problem which just needs more precision []?
Ross
On Wed, 14 Oct 2020 at 09:26, Ross Burton wrote:
>
> Similar in libidn2:
>
> | m4:configure.ac:16: Warning: excess arguments to b
Thanks Zack. I can confirm that the patch fixes both of the failures
I've seen in AC_INIT.
Ross
On Wed, 14 Oct 2020 at 23:05, Zack Weinberg wrote:
>
> On Wed, Oct 14, 2020 at 5:47 PM Ross Burton wrote:
> > That patch got totally mangled by mail, can you push it somewhere
Hi,
AC_PATH_X and friends are unusual in autoconf in that they
*explicitly* look into /usr/ for files (see _AC_PATH_X_DIRECT).
Notable this is the *only* macro in autoconf that explicitly looks
into /usr.
To write the logic out in English: iterate through a long list of
paths in /usr for a X11/Xl
On Thu, 15 Oct 2020 at 15:04, Zack Weinberg wrote:
> The thing that comes immediately to mind, and which would be feasible
> for 2.70, is to not run _AC_PATH_X_DIRECT when cross-compiling.
That seems realistic to me. The hardcoded paths are not useful in a
cross environment in the slightest.
>
FWIW, I just upgraded to 2.69d and hit the same problem:
m4:configure.ac:40: Warning: excess arguments to builtin `m4_define' ignored
Line 40 is:
AC_INIT(GNU MP, GMP_VERSION, [gmp-b...@gmplib.org, see
https://gmplib.org/manual/Reporting-Bugs.html], gmp)
Cheers,
Ross
On Tue, 20 Oct 2020 at 14:0
Hi,
The recent changes to AM_GNU_GETTEXT handling in autoreconf have
altered the behaviour, specifically previously AM_GNU_GETTEXT on its
own was sufficient, but now the AM_GNU_GETTEXT_VERSION macro is a hard
requirement. This leads to comedy situations like gettext not
building out of the box. :
Hi,
All through the 2.70 prelease cycle I was periodically running builds
of OpenEmbedded with the snapshots as they were released. As we
autoreconf by default this was great at shaking out some bugs in both
packages and autoconf itself. However, I see that in between the
Release Candidate and t
On Wed, 16 Dec 2020 at 18:05, Zack Weinberg wrote:
> First, could you please test whether the problem is already fixed in
> branch-2.70? The release went out with an embarrassing typo in this
> code. I was waiting to hear back from the automake people about some
> problems running their testsuit
On Sun, 20 Dec 2020 at 16:46, Bruno Haible wrote:
> This patch is already in Gnulib since 2020-12-09. But when people
> run 'autoreconf' on an existing released tarball, they are effectively
> combining an older Gnulib with a newest Autoconf.
>
> Why do people do that? The point of tarballs is th
I wanted to test this beforehand but Christmas got in the way. I'm
testing the contents of the 2.70 branch now and it's looking good, so
thanks very much!
Ross
On Wed, 23 Dec 2020 at 19:21, Zack Weinberg wrote:
>
> On Sun, Dec 20, 2020 at 12:09 PM Zack Weinberg wrote:
> > I'm not happy about n
rite this file? Although I've used configure many times and
know roughly how it works, this is beyond me and the Autoconf manual is
rather vague on this point.
Thanks for any help,
Ross Burton
--
Ross Burton Software Engineer
OneEighty Software Ltd Tel:
on to remain true in the
future? Being able to ditch the config.sub and config.guess update mess
would make things a lot easier...
Regards,
Ross
--
Ross Burton mail: [EMAIL PROTECTED]
jabber: [EMAIL PROTECTED
On 17 Dec 2024, at 18:23, Zack Weinberg wrote:
> The other thing that comes to mind is, if there were anyone working
> seriously on usage of autoconf *without* automake, that would make
> the move a lot more valuable. I know some people have tried that in
> the past but I don't think any of them
Hi,
I’m trying to clean up our autoconf invocation and want to do things the
“right” way.
We’re in a cross environment with split native/target sysroots which makes
things interesting, as this means there are two places which I consider the
“system ac directories”, the target and the native.
es, it really should be in autoconf, right?
> On 2024-12-17 11:01, Ross Burton wrote:
>> I’m trying to clean up our autoconf invocation and want to do things
>> the “right” way.
>>
>> We’re in a cross environment with split native/target sysroots which
>> makes things i
26 matches
Mail list logo
