ffgt@kaos:~/build$ grep ^VERSION gluon-ffgt-v2023.2/site-ffgt/gluon-build/openwrt/build_dir/host/autoconf-2.71/Makefile
VERSION = 2.71
ffgt@kaos:~/build$ ls -la gluon-ffgt-v2023.2/site-ffgt/gluon-build/openwrt/build_dir/host/autoconf-2.71/bin/autoconf
-r-xr-xr-x 1 ffgt ffgt 15530 Jul 19 14:25 gluon-ffgt-v2023.2/site-ffgt/gluon-build/openwrt/build_dir/host/autoconf-2.71/bin/autoconf
ffgt@kaos:~/build$ gluon-ffgt-v2023.2/site-ffgt/gluon-build/openwrt/build_dir/host/autoconf-2.71/bin/autoconf --version
autoconf (GNU Autoconf) 2.0.0~0
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>, <https://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
Aus autoconf 2.7.1-Source fällt autoconf 2.0.0 raus?
Auf zwei Blechen, Debian 11-basiert (kaos) und unter Debian 12. Gleiches Ergebnis. (Es gibt ein „mk-ffgt-v20xy.z.sh“, das legt das Verzeichnis (hier gluon-ffgt-v2023.2) an, klont darein dann das Site-Repo (bzw. macht bei Vorhandensein stash & pull), geht in das Verzeichnis und startet dann make 2>&1 | tee make.out, also das Makefile im Site-Repo. D. h. ich schmeiße gluon-ffgt-v2023.2 weg und habe einen sauberen Start.) Und beide Male war in gluon-ffgt-v2023.2/site-ffgt/gluon-build/openwrt/build_dir/host/autoconf-2.71/bin/autoconf ein 2.0.0er Binary drin.
Durchsichtig ist der Buildprozeß ja schon länger nicht mehr, mit OpenWrt, was Sourcecodes patcht, Gluon, was OpenWrt patcht und dazu noch ggf. Patches gegen Gluon (ggf. bis runter ins OpenWrt) aus dem Site-Repo — aber wieso in einem 2.71er autoconf-Source nach make ein 2.0.0er Binary im bin-Verzeichnis langen kann, erschließt sich mir nicht
sudo apt install autoconf && cp -p /usr/bin/autoconf /home/ffgt/build/gluon-ffgt-v2023.2/site-ffgt/gluon-build/openwrt/staging_dir/host/bin/autoconf ermöglicht dann den Bau, aber eben nicht from Scratch. Kann OpenWrt dazu gebracht werden, über Paketabhängigkeiten verschiedenen autoconf-Versionen zu installieren? Unsere Pakete haben ihre Urspünge teils in 2016 und wurden so modifiziert, daß es mit der jeweiligen Gluon-Version kompiliert; ggf. ziehen wir da irgendwie das alte autoconf mit rein?
/ffpi-firmware/gluon/openwrt/build_dir/host/autoconf-2.71/bin$ autoconf --version
autoconf (GNU Autoconf) 2.71
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
<https://gnu.org/licenses/gpl.html>, <https://gnu.org/licenses/exceptions.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Written by David J. MacKenzie and Akim Demaille.
Mit wievielen Prozessen baust Du? In 2022.1.2 wurden ja Probleme behoben:
Various build-errors which sporadically occur when building with a large thread-count have been fixed
Ich baue mit 24/12 Prozessen auf AMD Ryzen 5 3600 6-Core Processor bzw.
112/56 Prozessen auf Intel(R) Xeon(R) CPU E5-2680 v4 @ 2.40GHz. IIRC war der erste Lauf mit -j 1 schon bei v2021 ein Garant, daß die Host-Umgebung korrekt gebaut wurde, aber dann dauert der Bau auch Tage statt Stunden, das kann nicht die Lösung sein.
Und ich frage mich, ob es einen Unterschied bei dir machen würde, um zu versuchen das Problem einzugrenzen, wenn du zum Ausprobieren mal das Makefile aus eurer site weglassen würdest und stattdessen aus einem frischen checkout die minimalen Schritte manuell probieren würdest. Also „git clone“ vom Gluon repo, dann die gewünschte Gluon Version auschecken. Da dann den site Ordner mit eurer site hinzufügen. Und dann „make update && make GLUON_TARGET=ath79-generic“. Ist es dann auch kaputt bei dir?
Da ich das Problem seit ca. v2022.1 habe, habe ich das auch schon mal probiert — und IIRC trat das nicht auf, wenn ich unsere Patches/Packages nicht drin hatte. Bis einschließlich v2021.x haben wir ja Gluon geforkt, gepacht, und auf Basis dieses gepatchten Forks gearbeitet — die Patches-per-Site-Lösung ist da deutlich eleganter.
Aber die Frage ist ja, wie ausgerechnet/ausschließlich in openwrt/build_dir/host/autoconf-2.71/bin/autoconf ein autoconf (GNU Autoconf) 2.0.0~0 landen kann. Über Gluon-Pakete, that is …
Wenn nicht, was ist dann gewonnen? Ich habe eine Latte an Änderungen, ohne die die FW keinen Sinn macht. Und Änderungen auf Ebene Gluon dürften den OpenWrt-Build-Prozeß nicht beeinflussen?
Wenn man dann einen funktionierenden und einen nicht funktionierenden Stand hat, könnte man dann systematisch per Divide & Conquer sich dem Problem annähern.
Beim Überfliegen eurer site frage mich, ob da noch was mit „make -C“ war, ob da evtl. was mit den environment Variablen durcheinander kam oder so. Glaube die meisten machen es umgekehrt wie ihr: Nämlich „cd“ ins Gluon directory und dann den site Ordner per GLUON_SITEDIR angeben: Getting Started — Gluon 2023.2.5 documentation. (Aber nur ein wild guess - daher mag ich eigentlich divide & conquer lieber, weil man da nicht so viel im Dunkeln rumstochern muss )
Wir haben damals FFAC und/oder FFMUC als Basis genommen, für den 2023.2er Build wieder FFACs site-Repo als Basis, aber das bisherige Makefile aus unseren v2022/v2023-Vorversionen.
Letzten Endes scheint das ein Layer-8-Problem zu sein, da es ja augenscheinlich nur bei mir passiert; aber wie zum Henker das passiert, würde mich schon mal interessieren
Im damaligen Thread war mein autoconf-Problem ja 1.6.0 vs. 2.64 — und immer nur beim Bauen der OpenWrt-Host-Umgebung. Wenn das von unseren Patches ausginge – die Packages kommen ja erst später zum Tragen – müßten wir ja einen Gluon-Patch haben, der bzgl. autoconf OpenWrt patcht; anders kann doch bei einem Build, der auf git-Checkouts basiert, nix ›Fremdes‹ reinkommen? Einfach nur sehr merkwürdig …
)