On 1/8/25 23:16, Ross Burton 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.
I have a series in testing that removes acpaths entirely which solves this
problem at the source instead of having to be worked around in every recipe.
Ross
Hi, Ross, Richard
I tested with latest code, the problem is not resolved. I think we still
need the following patch.
diff --git a/meta/classes-recipe/autotools.bbclass
b/meta/classes-recipe/autotools.bbclass
index e33eae7d48..ac86da361e 100644
--- a/meta/classes-recipe/autotools.bbclass
+++ b/meta/classes-recipe/autotools.bbclass
@@ -169,10 +169,6 @@ autotools_do_configure() {
ACLOCAL="aclocal
--aclocal-path=${STAGING_DATADIR}/aclocal/"
if [ x"${acpaths}" = xdefault ]; then
acpaths=
- for i in `find ${AUTOTOOLS_SCRIPT_PATH}
-ignore_readdir_race -maxdepth 2 -name \*.m4|grep -v 'aclocal.m4'| \
- grep -v 'acinclude.m4' | sed -e
's,\(.*/\).*$,\1,'|sort -u`; do
- acpaths="$acpaths -I $i"
- done
else
acpaths="${acpaths}"
fi
Since this will influence many recipes, I want to ask your opinion
first, if you agree, then I will send out the patch after all test is
passed.
Here is the final aclocal command for libunistring-native:
aclocal
--aclocal-path=/build/tmp/work/x86_64-linux/libunistring-native/1.3/recipe-sysroot-native/usr/share/aclocal/*-I
/build/tmp/work/x86_64-linux/libunistring-native/1.3/libunistring-1.3/gnulib-m4/
-I
/build/tmp/work/x86_64-linux/libunistring-native/1.3/libunistring-1.3/m4/
*--force -I m4 -I gnulib-m4
The bold part is passed by the removed code, actually it is not needed
because ACLOCAL_AMFLAGS = -I m4 -I gnulib-m4 is set in Makefile.am.
with the bold part, aclocal will run autom4te *.m4, "Argument list
too long" error will reported when the * is the long absolute path.
For autotools.bbclass, how about don't pass -I $i to acpaths, suppose
that upstream configure.ac or Makefile.am have set the correct
AC_CONFIG_MACRO_DIRS, ACLOCAL_AUTOMAKE_DIR, or ACLOCAL_AMFLAGS. if the
recipe is not correctly set, the recipe is responsible for set correct
acpaths themselves, or better to send patch to upstream, set correct
macro dirs in configure.ac.
Eg:
for freetype, according to
https://github.com/freetype/freetype/blob/master/autogen.sh#L165, we can
set acpaths= -I .
I tried to do a world build with poky, only 3 recipes failed at
do_configure, I plan to test with all layer under meta-openembeded later.
Do you have any concern or suggestion about this?
Regards
Changqing
On 8 Jan 2025, at 08:40, Changqing Li via
lists.openembedded.org<changqing.li=windriver....@lists.openembedded.org>
wrote:
ping
On 12/17/24 17:09, Changqing Li via lists.openembedded.org wrote:
From: Changqing Li<changqing...@windriver.com>
man-db uses a lot of m4 files, with acpaths set to absolute path,
and the TMPDIR is long/deep, for example when len(TMPDIR) = 350,
do_configure failed with "Argument list too long" error.
[snip]
aclocal: error: cannot open xxx Argument list too long
autoreconf: aclocal failed with exit status: 1
ERROR: autoreconf execution failed.
[snip]
Let aclocal use the relative path for the m4 file rather than the
absolute would fix the problem.
Signed-off-by: Changqing Li<changqing...@windriver.com>
---
meta/recipes-extended/man-db/man-db_2.13.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-extended/man-db/man-db_2.13.0.bb
b/meta/recipes-extended/man-db/man-db_2.13.0.bb
index 2fa18a8f24..553b2d59d2 100644
--- a/meta/recipes-extended/man-db/man-db_2.13.0.bb
+++ b/meta/recipes-extended/man-db/man-db_2.13.0.bb
@@ -22,7 +22,7 @@ USE_NLS:libc-musl = "no"
inherit gettext pkgconfig autotools systemd
EXTRA_OECONF = "--with-pager=less
--with-systemdsystemunitdir=${systemd_system_unitdir}"
-EXTRA_AUTORECONF += "-I ${S}/gl/m4"
+acpaths = "-I ./m4 -I ./gl/m4"
PACKAGECONFIG[bzip2] = "--with-bzip2=bzip2,ac_cv_prog_have_bzip2='',bzip2"
PACKAGECONFIG[gzip] = "--with-gzip=gzip,ac_cv_prog_have_gzip='',gzip"
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#211745):
https://lists.openembedded.org/g/openembedded-core/message/211745
Mute This Topic: https://lists.openembedded.org/mt/110160165/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
