make menuconfig vs. make busybox-menuconfig (kernel-menuconfig)

[er13]

Schön. Mit welchem Knopf in "make menuconfig" wurde das (automatisch) aktiviert (oder könnte man das deaktivieren)?

Mit "Build binutils and gcc for target" (aka FREETZ_TARGET_TOOLCHAIN=y). Lässt sich alles mit einem einfachen Klick auf Help auf dieser Option bzw. auf einer der Libraries rausfinden.

Warum sind da jetzt die Voreinstellungen für die Builds anders, als wenn ich es fertig runterlade?

Mal Gegenfrage: warum sollen sie denn identisch sein? Default-Einstellungen für die selbstgebaute toolchain sind nicht unbedingt die sinnvollsten für die download-toolchain und umgekehrt. Genau deswegen sind sie anders.

Bzw: Wo genau sind die Einstellungen im Wiki/Source dokumentiert, um genau die Downloadversion zu erreichen?

Habe ich das nicht in #13 geschrieben?

 

[Wiedmann]

Mal Gegenfrage: warum sollen sie denn identisch sein?

Weil das der Standard bei normalen Paket-/Buildsystem ist? Ein normales "make" erstellt/installiert die Software so, wie wenn man das Paket fertig als Binary runterläd. Bei einem "make" auf die Sourcen hätte ich aber die Möglichkeit die Konfiguration für mich passend zu verändern.

 

[Wiedmann]

Edit: Alle Optionen, mit denen die download-toolchains gebaut werden, kannst Du rausfinden, indem Du die Zeile "make KTV=..." (aktuell Zeile 62) in build_download_toolchains auskommentierst und das Script laufen lässt.

Hmmm, Zeile 62 auskommentieren und "tools/build_download_toolchains" ausführen...

... also da hat er jetzt erst mal alles was er die letzten 4h gebaut hat gelöscht, inkl. die .config und fängt an etwas für die 7270 zu bauen (die ich nicht hab). Muss ich da jetzt auch wieder 4h warten um was genau zu erfahren?


Zusatz:
Was mir grad noch auffällt, dieses Vorgehen hat mir auch gleich den ganzen "./dl" gelöscht (!?!), ein neues, leeres "dl" im Homeverzeichnis angelegt, und darauf einen Symlink gesetzt...

 

[Wiedmann]

Mit "Build binutils and gcc for target" (aka FREETZ_TARGET_TOOLCHAIN=y). Lässt sich alles mit einem einfachen Klick auf Help auf dieser Option bzw. auf einer der Libraries rausfinden.

Schön, das wäre dann also:
menuconfig --> Advanced options --> Shared Libraries --> Multi precision arithmetic libs

und dort

[X] GNU MP Bignum Library (libgmp.so)
[X] GNU MPFR Library (libmpfr.so)
[X] GNU MPC Library (libmpc.so)

Das lässt sich dort dann aber nicht mehr abwählen...

Alleine das Verzeichnis "/usr/lib/freetz" belegt ja 848K und ist bei der Download-Toolchain ja auch nicht auf der Box.

Zusatz:
Wenn man "Build binutils and gcc for target" danach mal abwählt, werden die obigen Libs trotzdem noch gebaut.
--> diese Libs werden zwar durch "Build binutils and gcc for target" aktiviert, aber nicht automatisch deaktiviert.

 

[er13]

Entschuldige bitte mir meine etwas unfreundliche Antwort. Aber arbeite Dich bitte ein wenig in die Materie ein (menuconfig, warum Sachen nicht automatisch abgewählt werden (können), make config-clean-deps ist übrigens das Stichwort). Manches ist in FAQ, manches ist in "Freetz für Newbies" von gismotro drin. Zur Not lese einfach den Quellcode (ist immer die most up-to-date Dokumentation). Von einem der die toolchain selbst baut, wird erwartet, dass er sich selbst helfen kann. Zu Deinen Fragen:

• Nein, es macht nicht immer Sinn, dass die default-Optionen für die download- und für die selbstgebaute Version übereinstimmen. Das einfachste Beispiel ist FREETZ_TOOLCHAIN_32BIT. Hat man ein 64bit System, so möchte man bestimmt davon profitieren (d.h. 64bit host-binaries bauen). Daher ist die Option per Default ausgeschaltet. An die download-Version wird dagegen die Anforderung gestellt, auf allen (d.h. sowohl auf 32-bit als auch auf 64-bit) Systemen zu laufen. Daher wird die Option bei der download-Version eingeschaltet.
• build_download_toolchains ist wie der Name vermuten lässt in erster Linie dafür da, alle download-toolchains, die benötigt werden, zu bauen. Dass dabei auch alle .configs gespeichert werden, mit denen die download-toolchains gebaut werden, ist nur ein Nebeneffekt. Tut mir leid, ich hätte in der Tat Dich darauf hinweisen sollen, dass beim Aufruf alles gelöscht wird (hättest Du aber auch durch kurzes Reinschauen selbst ablesen können).
• Du hast ja "Build binutils and gcc for target" zusätzlich gewählt und damit ein paar Libraries mitausgewählt. Die Option ist bei der download-Variante nicht eingeschaltet (d.h. die default-Werte der download- und der selbstgebauten Toolchain stimmen hier überein). Daher gibt es eben ein paar Libraries unter "/usr/lib/freetz", die es in der download-Version nicht gibt. Also entweder akzeptieren und nicht wundern, dass es größer wird, oder einfach abwählen, wenn Du die Option nicht brauchst. Bei der download-Variante ist die Option wie gesagt nicht eingeschaltet.
• "Autoabwählen" geht wie oben schon geschrieben mit: make config-clean-deps

 

[Wiedmann]

Entschuldige bitte mir meine etwas unfreundliche Antwort.

Passt schon. Immerhin sind wir weiterhin in einer Diskussion ;-)

Aber arbeite Dich bitte ein wenig in die Materie ein (menuconfig,

wie z.B.:

select should be used with care. ... In general use select only for non-visible symbols (no prompts anywhere)

Ist ja nicht die einzigste Stelle, wo "select" auch völlig unnötig und zum Nachteil benutzt wird.

Aber gut, man kann sowas ja auch im makefile (Config.in) deaktivieren. Was halt eigentlich auch nicht Sinn der Sache (Buildsystem) ist, sowas durch manuelles Anpassen des Makefiles zu ändern.

make config-clean-deps ist übrigens das Stichwort).

Auch mit Vorsicht zu genießen, weil es ja u.a. Dinge abweichend vom Standard abwählt, die man ja vielleicht aus gutem Grund ausgewählt hat. Also müsste man danach erst mal wieder in die Konfig rein und alles wieder anwählen was man braucht (und in der Hoffnung man vergisst dann nichts).

Zur Not lese einfach den Quellcode (ist immer die most up-to-date Dokumentation).

[*] Nein, es macht nicht immer Sinn, dass die default-Optionen für die download- und für die selbstgebaute Version übereinstimmen. Das einfachste Beispiel ist FREETZ_TOOLCHAIN_32BIT. Hat man ein 64bit System, so möchte man bestimmt davon profitieren (d.h. 64bit host-binaries bauen). Daher ist die Option per Default ausgeschaltet. An die download-Version wird dagegen die Anforderung gestellt, auf allen (d.h. sowohl auf 32-bit als auch auf 64-bit) Systemen zu laufen. Daher wird die Option bei der download-Version eingeschaltet.

Eben das ist der Denkfehler. Seien es Ports , pkgsrc, oder wegen mir dpkg usw.. Die Binary-Pakete werden immer aus den Source-Paketen mit den Standardoptionen gebaut. Wie will man sonst nachvollziehbare und reproduzierbare Ergebnisse erhalten.

Das siehst du doch schon hier:
Ein Image mit "Download-Toolchain" läuft auf der Box, ein ansonsten gleiches Image mit "Build-Toolchain" nicht. Wo soll man denn da mit Fehlersuche anfangen, wenn das Eine nicht schon mal grundsätzlich das Andere ergibt (und das make ohne Fehler durchläuft)?

Zur Not lese einfach den Quellcode (ist immer die most up-to-date Dokumentation).

Soweit OK. Aber sich wegen grundlegend Sachen wie eine Defaultkonfiguration durch den Quellcode zu quälen? Eigentlich will man ja andere Probleme lösen und das sollte eine offensichtliche Info sein.

Ansonsten wirst das ja nicht wirklich wollen ;-) Da hat einer noch nie "Avoiding Linuxisms/Bashisms" gelesen... (*gruselig*) *g*

[*] Du hast ja "Build binutils and gcc for target" zusätzlich gewählt

Da bleibt mir nichts anderes übrig.... Aber das ist erst mal ein anderes Thema. (auch wenn hier was von "Target" steht, braucht man es u.U. ja auch zum Bau der Toolchain selbst (siehe mk files).



Wie war das jetzt mit den Symlinks:
- Müssen die nur in "./toolchain/build/..." vorhanden sein, oder eben auch in "./build/modified/filesystem/...".
- Und wenn sie in "build/modified/filesystem/..." sein sollten, wieso sind sie da bei der Eigenbau-Toolchain dort nicht?

Kann natürlich schon sein, dass das Eigenbuild nur auf die versionierte Version linkt. Dann wären sie natürlich unnötig. Ist das aber auch für die AVM-Binaries gültig (und wie kommen sie dann in die Download-Toolchain).

(Bestimmt steht das in irgendeinem Makefile, was man suchen könnte. Aber eigentlich sollte das ja zumindest der wissen, der das Makefile dazu geschrieben hat)

Nur um meinem eigentlichen Problem etwas mehr auf die Schliche zu kommen...

 

[Wiedmann]

Sodele, neues Jahr, neues Glück Hoffe ihr seit alle gut rübergekommen.

Wie war das jetzt mit den Symlinks:
- Müssen die nur in "./toolchain/build/..." vorhanden sein, oder eben auch in "./build/modified/filesystem/...".

Um meine Frage zu beantworten, in "./build/modified/filesystem/..." müssen die Symlinks nicht vorhanden sein.

Nur um meinem eigentlichen Problem etwas mehr auf die Schliche zu kommen...

Auch hier die Antwort darauf: Ein "find" bei dem Fehler unterdrückt und ignoriert wurden.
Eine simple Antwort auf die Frage wie die Download-Toolchain erstellt wird, hätte mir da Stunden bei der Suche an der falschen Stelle erspart. Danke.


Ansonsten hab ich jetzt was ich wollte. Anstatt 5-6 Stunden für den Bau der Toolchain/Firmware geht das jetzt in unter 1er Stunde. Irgendwie schon daneben, wenn ein *nix vorhanden ist, ein Linux in 'ner VM betreiben zu müssen nur um freetzen zu können...


Unter http://freetz.org/wiki/help/howtos/common/install:

• fehlt noch "wget" in der Liste der notwendigen Pakete.
• zu "tofrodos" hab ich jetzt auch nichts gefunden.
• "dos2unix" hab ich jetzt nur bei "openjpeg" gefunden. Wird das noch wo anders gebraucht? Weil dort könnte man das simpel ersetzten und man wäre diese Abhängigkeit los.

Zur Download-Toolchain hätte ich noch was was. Da wäre es praktisch, wenn auch ein `uname -m`-`uname -s` mit im Dateiname wäre, bzw. nicht einfach eine runter geladen wird, die dann womöglich gar nicht zum System passt.

Bei "make toolchain" werden zwar schön zwei LZMA-Dateien erstellt, es wäre natürlich aber besser, wenn die dann auch benutzt würden, wenn man im "make menukonfig" umstellt das man eine Download-Tolchain benutzen will. Und das ohne das man ein Makefile verändern muss.