autoconf git and no host help2man
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. Cheers, Ross
Re: autoconf git and no host help2man
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
Re: autoconf git and no host help2man
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 *should* work, not that it *does* work. I believe you that it doesn't work. (I should have made that clear.) Okay, so the problem was that I was patching autoreconf.in and the rules appear to have been changed/improved so that means rebuilding the manpages. Dropping the patching and it builds without help2man from tarball fine. Ross
New failures with autoconf master
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: line 6400: `do :'
The code around here is:
6393 printf "%s\n" "#define uintptr_t $ac_type" >>confdefs.h
6394
6395 ac_type=
6396 fi
6397 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
6398test -z "$ac_type" && break
6399 done
6400 fi
6401
6402
6403
6404 # Check whether --enable-pdf-compression was given.
6405 if test ${enable_pdf_compression+y}
6406 then :
6407 enableval=$enable_pdf_compression;
6408 else
6409 enableval=yes
6410 fi
flex:
checking for strtol... yes
./configure: command substitution: line 16785: syntax error near
unexpected token `then'
./configure: command substitution: line 16785: `then :'
./configure: line 16777: = xyes
then :
cat >>confdefs.h <<_ACEOF
[pages of configure script]
The flex issue is worked around by picking this commit from flex git:
https://github.com/westes/flex/commit/c42de062bbdc7c31d7181c10a74202d493280ada
That refers to a mail sent to bug-autoconf in February 2018, with no reply:
https://lists.gnu.org/archive/html/bug-autoconf/2018-02/msg5.html
Any thoughts?
Ross
Re: New failures with autoconf master
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/index.php?110210 and https://savannah.gnu.org/support/index.php?110211. I think the line number in the syntax error must be wrong; there's no "do :" anywhere in the snippet you quoted. I'll poke at this some later today, but can you tell me where to download a tarball of the exact same version of Nasm that you are testing? I want to be sure I'm looking at the same thing. Agreed. We're using the tarball of nasm 2.14.02. We do have some patches, but nothing relevant. Hm, I don't immediately see how we get from misbehavior in autoheader with 'dnl' inside an AC_CHECK_THINGS([...]) list, to syntax errors in configure. Again, I'd like to poke at this some myself, can you tell me where to get the exact version of flex that you are testing? Agreed again. Definitely confusion somewhere... Flex 2.6.4 tarball, again a few patches but nothing huge. To see *exactly* what we're building, this is in OpenEmbedded: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/flex http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/nasm I'm not battling binutils which demands a specific autoconf release, so I'll need to package up both 2.69 and git master for that. Ross
Should AM_PROG_CC call AM_PROG_CPP?
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 | checking for strings.h... (cached) yes | checking for wchar.h... yes | checking for inttypes.h... (cached) yes | checking for stdint.h... (cached) yes | checking for limits.h... yes | checking for ctype.h... yes | checking for math.h... yes | checking for float.h... yes | checking for iconv.h... yes | checking for signal.h... yes | checking for size_t... yes | checking for M_PI in math.h... ../SDL2-2.0.10/configure: line 13143: CPP: command not found | checking how to run the C preprocessor... x86_64-poky-linux-gcc -E --sysroot=/scratch/poky/work/corei7-64-poky-linux/libsdl2/2.0.10-r0/recipe-sysroot -m64 -march=nehalem -mtune=generic -mfpmath=sse -msse4.2 -fstack-protector-strong -D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security | ../SDL2-2.0.10/configure: line 13269: ac_fn_c_try_cpp: command not found | ../SDL2-2.0.10/configure: line 13269: ac_fn_c_try_cpp: command not found | configure: error: in `/scratch/poky/work/corei7-64-poky-linux/libsdl2/2.0.10-r0/build': I note that the configure.ac doesn't explictly call AM_PROG_CPP and adding that fixes it, but I'm guessing from the undeclared ac_fn_c_try_cpp that this should have been done automatically? Ross
My experience with autoconf master
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 snapshot of autoconf from last week with the following failures: - flex. dnl in AC_CHECK_FUNCS, already fixed in upstream git - curl. Pointless AC_REQUIRE([AC_RUN_IFELSE]) now causing failure. - libsdl. Used $CPP without explicit call of AC_PROG_CPP which now is not being called implicitly. - nasm. Failure from AC_CHECK_HEADERS formatting (fix is to add a newline in the middle of ])]). Seems like it could be a regression to me. - ruby. Not investigated yet. - apr. "could not determine the string function for int64_t", not investigated yet. - apt. The AC_PROG_EGREP thing discussed earlier. - babeltrace. Something about how bison is being detected: very much bad code in babeltrace not autoconf. - ghostscript. "cannot find install-sh". Not investigated yet. We're carrying several patches but some are very specific to us (prefering bash over sh for consistency, or adding new stages to autoreconf) and some most likely need further discussion. I don't see any patches that should be upstreamed as-is, at least. If anyone wants to see what I'm up to, my branch is at http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=ross/newautoconf. Ross
Multiple arguments to CONFIG_SITE
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.patch The use-case is that we have a collection of config.site files: one for "all builds", one for "all Linux targets", one for "x86-64 targets", and so on: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/site (those have grown organically over many years so need a massive review, but that's the model) However CONFIG_SITE only takes a single filename, so we patch autoconf to treat CONFIG_SITE as a list of absolute filenames instead. I'd like to see this functionality upstreamed but I'd like to discuss how CONFIG_SITE is parsed first. Should it just be treated as a space-separated list? Any better suggestions? Also note that there's potentially very bad interaction: if someone has done as the manual suggests and dropped a /usr/share/config.site in then that will be read when doing --prefix=/usr, *even in cross-compile situations* where /usr is a target prefix and not valid on the host. Then again this isn't exactly the first time autoconf has this problem. Thanks, Ross
Weird failure with autoconf 2.69c in gmp
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: aclocal --system-acdir=/home/ross/Yocto/build/tmp/work/aarch64-linux/gmp-native/6.2.0-r0/recipe-sysroot-native/usr/share/aclocal/ --automake-acdir=/home/ross/Yocto/build/tmp/work/aarch64-linux/gmp-native/6.2.0-r0/recipe-sysroot-native/usr/share/aclocal-1.16 --force | m4:configure.ac:40: Warning: excess arguments to builtin `m4_define' ignored | autom4te: error: m4 failed with exit status: 1 | aclocal: error: echo failed with exit status: 1 | autoreconf: error: aclocal failed with exit status: 1 Line 40 is: AC_INIT(GNU MP, GMP_VERSION, [gmp-b...@gmplib.org, see https://gmplib.org/manual/Reporting-Bugs.html], gmp) Has anyone seen this, or similar, before? Ross
Re: Weird failure with autoconf 2.69c in gmp
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 fails in a rather
> > mysterious way:
> [...]
> > | m4:configure.ac:40: Warning: excess arguments to builtin `m4_define'
> > ignored
> > | autom4te: error: m4 failed with exit status: 1
> > | aclocal: error: echo failed with exit status: 1
> > | autoreconf: error: aclocal failed with exit status: 1
> >
> > Line 40 is:
> >
> > AC_INIT(GNU MP, GMP_VERSION, [gmp-b...@gmplib.org, see
> > https://gmplib.org/manual/Reporting-Bugs.html], gmp)
> >
> > Has anyone seen this, or similar, before?
>
> This appears to be caused by a quoting bug in _AC_INIT_PACKAGE (expanded
> by AC_INIT) which was recently introduced by commit 6a0c0239449a ("Trim
> whitespace from arguments of AC_INIT").
>
> It would seem that the comma from the 3rd argument ends up getting
> passed unquoted to m4_define which results in this error.
>
> This code in lib/autoconf/general.m4:
>
> m4_ifndef([AC_PACKAGE_BUGREPORT],
> [m4_define([AC_PACKAGE_BUGREPORT], _ac_init_BUGREPORT)])
>
> should probably be changed to:
>
> m4_ifndef([AC_PACKAGE_BUGREPORT],
> [m4_define([AC_PACKAGE_BUGREPORT], m4_defn([_ac_init_BUGREPORT]))])
>
> Cheers,
> Nick
Re: Weird failure with autoconf 2.69c in gmp
Similar in libidn2:
| m4:configure.ac:16: Warning: excess arguments to builtin `m4_define' ignored
16 AC_INIT([libidn2], [2.3.0], [help-lib...@gnu.org],,
17 [https://www.gnu.org/software/libidn/#libidn2])
Not handling the tarname being unset?
Ross
On Tue, 13 Oct 2020 at 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 two
> > > patches, so that's good news!) to build gmp fails in a rather
> > > mysterious way:
> > [...]
> > > | m4:configure.ac:40: Warning: excess arguments to builtin `m4_define'
> > > ignored
> > > | autom4te: error: m4 failed with exit status: 1
> > > | aclocal: error: echo failed with exit status: 1
> > > | autoreconf: error: aclocal failed with exit status: 1
> > >
> > > Line 40 is:
> > >
> > > AC_INIT(GNU MP, GMP_VERSION, [gmp-b...@gmplib.org, see
> > > https://gmplib.org/manual/Reporting-Bugs.html], gmp)
> > >
> > > Has anyone seen this, or similar, before?
> >
> > This appears to be caused by a quoting bug in _AC_INIT_PACKAGE (expanded
> > by AC_INIT) which was recently introduced by commit 6a0c0239449a ("Trim
> > whitespace from arguments of AC_INIT").
> >
> > It would seem that the comma from the 3rd argument ends up getting
> > passed unquoted to m4_define which results in this error.
> >
> > This code in lib/autoconf/general.m4:
> >
> > m4_ifndef([AC_PACKAGE_BUGREPORT],
> > [m4_define([AC_PACKAGE_BUGREPORT], _ac_init_BUGREPORT)])
> >
> > should probably be changed to:
> >
> > m4_ifndef([AC_PACKAGE_BUGREPORT],
> > [m4_define([AC_PACKAGE_BUGREPORT],
> > m4_defn([_ac_init_BUGREPORT]))])
> >
> > Cheers,
> > Nick
Re: Weird failure with autoconf 2.69c in gmp
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 builtin `m4_define' ignored
>
> 16 AC_INIT([libidn2], [2.3.0], [help-lib...@gnu.org],,
> 17 [https://www.gnu.org/software/libidn/#libidn2])
>
> Not handling the tarname being unset?
>
> Ross
>
> On Tue, 13 Oct 2020 at 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 two
> > > > patches, so that's good news!) to build gmp fails in a rather
> > > > mysterious way:
> > > [...]
> > > > | m4:configure.ac:40: Warning: excess arguments to builtin `m4_define'
> > > > ignored
> > > > | autom4te: error: m4 failed with exit status: 1
> > > > | aclocal: error: echo failed with exit status: 1
> > > > | autoreconf: error: aclocal failed with exit status: 1
> > > >
> > > > Line 40 is:
> > > >
> > > > AC_INIT(GNU MP, GMP_VERSION, [gmp-b...@gmplib.org, see
> > > > https://gmplib.org/manual/Reporting-Bugs.html], gmp)
> > > >
> > > > Has anyone seen this, or similar, before?
> > >
> > > This appears to be caused by a quoting bug in _AC_INIT_PACKAGE (expanded
> > > by AC_INIT) which was recently introduced by commit 6a0c0239449a ("Trim
> > > whitespace from arguments of AC_INIT").
> > >
> > > It would seem that the comma from the 3rd argument ends up getting
> > > passed unquoted to m4_define which results in this error.
> > >
> > > This code in lib/autoconf/general.m4:
> > >
> > > m4_ifndef([AC_PACKAGE_BUGREPORT],
> > > [m4_define([AC_PACKAGE_BUGREPORT], _ac_init_BUGREPORT)])
> > >
> > > should probably be changed to:
> > >
> > > m4_ifndef([AC_PACKAGE_BUGREPORT],
> > > [m4_define([AC_PACKAGE_BUGREPORT],
> > > m4_defn([_ac_init_BUGREPORT]))])
> > >
> > > Cheers,
> > > Nick
Re: Weird failure with autoconf 2.69c in gmp
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 or attach > > it? > > Sorry about that. You can get it from > https://git.savannah.gnu.org/git/autoconf.git in the > 'zack/ac-init-quoting' branch. > > zw
AC_PATH_X and friends explicitly look into /usr/lib
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/Xlib.h file, and if that exists try a compile test. Then iterate through the same set of paths after s/include/lib/ looking for anything with a library extension (.a .so .sl .dynlib .dll .la) and if one is found try a link test. The big failure case is in cross compilation situations using a sysroot where the target is binary compatible with the host. In this case AC_PATH_X will happily look at /usr and say that yes, X is available, even if the sysroot doesn't have X. My preferred solution would be to delete AC_PATH_X and friends and get everyone to use PKG_CHECK_MODULES(x11), but I can see that isn't a realistic solution. Because the failure case above is a real problem for us, we just delete all of that code. Does anyone have a better solution that would continue to work but not be so dramatically dependent on host assumptions? Cheers, Ross
Re: AC_PATH_X and friends explicitly look into /usr/lib
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.
> It might also make sense for
> _AC_PATH_X_XMKMF to look for ${ac_tool_prefix}-xmkmf rather than plain
> xmkmf, except I don't know if that would break existing cross compile
> build farms.
To be honest, nothing uses xmkmf/Imake anymore, so I don't think
anyone would know or care if the test was deleted entirely...
Ross
Re: Weird failure with autoconf 2.69c in gmp
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:01, Zack Weinberg wrote: > > On Wed, Oct 14, 2020 at 5:04 PM Zack Weinberg wrote: > > > > If you could both please test this patch? I would also appreciate a > > second pair of eyes on it -- even with an expanded "AC_INIT with > > unusual strings" test and careful inspection of all the places where > > the AC_PACKAGE_* macros are used, I'm not 100% sure I got everything. > > I'm going to commit this patch tomorrow if I don't hear any more > feedback before then. > > zw
Change in gettext behaviour
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. :). Was this change intentional? Cheers, Ross
Request to revert the C version change
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 the final release a large breaking change to C version detection was integrated that basically means that any software using gnulib needs to update? Obviously this causes our builds to break straight away, the build chains stop at bison and gettext failing to configure. Please consider reverting this change: as a change that landed after the RC there was a very limited window of opportunity for testing and the requirement for all software to update gnulib just means that nobody will upgrade to the new autoconf because it breaks everything else. Cheers, Ross
Re: Request to revert the C version change
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 testsuite with 2.70, that may or may not need a > fix in autoconf, before cutting a 2.70.1, but I can push my schedule > for that up a little if it'll help you. As far as I can tell I've already picked the fixes in the branch. This is how bison failed: | checking for gcc option to enable C11 features... none needed | ../bison-3.7.4/configure: line 6187: syntax error near unexpected token `ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89' | ../bison-3.7.4/configure: line 6187: ` ac_cv_prog_cc_stdc=$ac_cv_prog_cc_c89' gettext failed in the same manner. I can bisect and identify where it broke tomorrow. Ross
Re: Request to revert the C version change
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 that you can run > './configure' right away. > > If people want to modify the build infrastructure, it would often be > more reasonable to start off the git repository of the package (possibly > from a specific release tag or release branch). Because it’s not uncommon to need newer config.status, or updated m4 files, or to patch Makefile.am or configure.ac. Ross >
Re: Request to revert the C version change
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 needing to kludge backward compatibility with the > > older std-gnu11.m4 into autoconf 2.70.1 but I'm going to do it. > > As of commit 2d0f19d84ddb13412382674fd48e6fc5c2875d0e, Autoconf > *trunk* should now be backward compatible with the older std-gnu11.m4. > I verified that I can regenerate bison 3.7.4's configure script with > that version of Autoconf, making no other changes to the bison release > tarball, and then configure, build, and test bison with no errors. > > The patch is somewhat invasive, though. The full text is attached, > and before I merge it to the 2.70 branch, I'd appreciate any extra > testing and/or code review anyone cares to give it. > > zw
Cross-compilation with autoconf
Hi, What is required to add a new processor target to autoconf? I ask as we are currently looking at porting a unit testing framework (check.sf.net) to allow it to run on embedded systems. It currently uses autoconf so we were looking at simply extending the tests it does (basically all we need to add is "can fork? can use FILE*?") but the crucial point running configure for the embedded target. As far as I can tell, we'd run on a desktop "./configure --target=avr-iar" and then configure needs to load a file containing the symbols for that target. How do I write 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: +44 20 8680 8712 Cygnet HouseFax: +44 20 8680 8453 12-14 Sydenham Road [EMAIL PROTECTED] Croydon, Surrey CR9 2ET, UK http://www.180sw.com./ Under the Regulation of Investigatory Powers (RIP) Act 2000 together with any and all Regulations in force pursuant to the Act OneEighty Software Ltd reserves the right to monitor any or all incoming or outgoing communications as provided for under the Act
config.sub/guess and --host/--build
Hi, I am creating packages for Debian. The current practise at the moment if a package uses autoconf is to replace the config.sub and config.guess files in upstream with the latest version (which is available through the autotools-dev package) before building. Also, all Debian systems (running on 11 architectures) know what they are, so most packages also call configure with --host and --build arguments. So, does using --host and --build mean that config.sub and config.guess will never be used? From a brief look at configure this appears to be the case, but is it a behaviour I can depend 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] www: http://www.burtonini.com./ PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF
Re: aclocal's past and future home (was Re: Best practise for aclocal paths in cross builds)
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 ever got anywhere. There’s definitely a non-zero number of projects in real use that use autoconf but not automake, so moving it does seems like a reasonable thing to do. Ross IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Best practise for aclocal paths in cross builds
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. Unfortunately you can’t pass a colon-separated list for —system-acdir so right now we’re effectively doing: $ ACLOCAL="aclocal --system-acdir=/sysroot-target/usr/share/aclocal” autoreconf --include /sysroot-native/usr/share/aclocal That is quite ugly. Now aclocal actually knows where the native aclocal directory is already so I could simplify that to: $ ACLOCAL="aclocal --aclocal-path=/sysroot-target/usr/share/aclocal” autoreconf But that still feels a little icky. Does anyone have any better suggestions? I’ll even try remembering how to write perl if there’s a neat solution that just needs a little coding. Cheers, Ross IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
Re: Best practise for aclocal paths in cross builds
On 17 Dec 2024, at 17:17, Nick Bowler wrote: > Adding the automake list, because (mostly for historical reasons) > aclocal is actually part of automake, not autoconf. I’ve been using autotools for too many years and I _still_ forget what tool is where… Though considering what it does, 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 interesting, as this means there are two places which I >> consider the “system ac directories”, the target and the native. > > I don't really get it, why you would need different autoconf macro > directories for "the target and the native", but ok... We need to build autoconf-native into the native sysroot so we can run it on the build machine, obviously. Then eg pkgconfig-native is needed as pkgconfig is a build-time binary, and that installs m4 macros into the native sysroot. Then a target package may depend on something like target libxml2 and its libxml2.m4 which will be in the target sysroot. So, aclocal needs to be able to find macros in the target and native sysroots. >> Unfortunately you can’t pass a colon-separated list for —system-acdir >> so right now we’re effectively doing: > > I believe the dirlist mechanism[1] for aclocal can be used to achieve > the result you are trying to achieve. > > Either put a dirlist file in the specified directory which points to the > other one, or specify a totally different directory containing a dirlist > file that refers to both. Interesting. I’ll have a read. Thanks, Ross IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
