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

[Wiedmann]

Hallo,

Im menuconfig kann ich ja z.B. unter "Advanced options -> BusyBox options -> IPv6 options" z.B. das ping 6 Kommando aktivieren. Das tut auch soweit. Schau ich aber nach dem Build in busybox-menuconfig nach, ist es dort nicht aktiviert.

Welchen Sinn macht es jetzt, diese Option in menuconfig und/oder busybox-menuconfig zu aktivieren.


Analog die Frage zu kernel-menuconfig. Wenn ich da in menuconfig z.B. conntrack (ip_conntrack.ko) deaktiviere, muss ich trotzdem noch in kernel-menuconfig rein um es wirklich los zu sein.


Auch scheint es Unstimmigkeiten im Wiki zu geben?

Unter http://freetz.org/wiki/packages/inetd steht:

Wenn man die voreingestellte Box auf eine andere umändert, bei welcher kein inetd verwendet wird/verwendet werden kann (z.B. 7170), dann bleibt inetd trotzdem ausgewählt. Man kann es manuell abwählen (Advanced options ⇒ BusyBox options ⇒ inetd) oder nach dem Beenden von "make menuconfig" und Speichern der Einstellungen mittels "make config-clean-deps" (Details hier) abwählen.

Unter Advanced options ⇒ BusyBox options ⇒ inetd kann ich den jedenfalls nicht abwählen (großes X)


Oder was mich mehr "nervt"... unter http://freetz.org/wiki/packages/iptables-cgi steht:

Bei der Auswahl von iptables-cgi in make menuconfig wird conntrack u.U. rekursiv mit ausgewählt. Man kann es jedoch manuell abwählen, sodass dessen Installation unterbleibt.

Nachdem conntrack automatisch mit ausgewählt wurde, habe ich keine Möglichkeit diese Module dort wieder manuell abwählen... Wie ist dann da die korrekte Vorgehensweise?

 

[olistudent]

Die busybox-Optionen in menuconfig überschreiben Änderungen im busybox-menuconfig. Jedoch sind im Freetz menuconfig nur ein kleiner Teil der busybox-Optionen verfügbar. Du brauchst das also nicht 2x auswählen.

Die Auswahl für Kernelmodule im menuconfig wählt nur aus, ob diese Module mit ins Image kopiert werden. Es ändert jedoch nichts an der .config, die zum Bauen des Kernels benutzt wird. Wenn du also ip_conntrack.ko nicht bauen willst, dann musst du das wirklich in kernel-menuconfig deaktivieren.

inetd: Wenn du eine Box ohne "AVM"-Inted hast und das Standard Package "inetd" abwählst, dann solltest du auch eine busybox ohne inetd bauen können!?

iptables-cgi: Wenn du iptables-cgi auswählst, dann werden einige Module davon fest ausgewählt, die kann man dann nicht manuell abwählen. Das müsstest du in der Config.in ändern oder iptables-cgi nicht auswählen...

Gruß
Oliver

 

[Wiedmann]

Die Auswahl für Kernelmodule im menuconfig wählt nur aus, ob diese Module mit ins Image kopiert werden. Es ändert jedoch nichts an der .config, die zum Bauen des Kernels benutzt wird. Wenn du also ip_conntrack.ko nicht bauen willst, dann musst du das wirklich in kernel-menuconfig deaktivieren.

Hmmm, also bei mir ist das so:

menukonfig: ip_conntrack abgewählt
kernel-menukonfig: ip_conntrack gewählt
--> auf der Box hab ich ip_conntrack

menukonfig: ip_conntrack abgewählt
kernel-menukonfig: ip_conntrack abgewählt
--> auf der Box hab ich kein ip_conntrack


Also ob er es baut wär ja egal. Aber wenn ich das nicht auf der Box haben will, dann muss ich das zwingend in der kernel-menukonfig abwählen. Oder wird's in einem Fall nur nicht shared als Modul gebaut, sondern statisch?

inetd: Wenn du eine Box ohne "AVM"-Inted hast und das Standard Package "inetd" abwählst, dann solltest du auch eine busybox ohne inetd bauen können!?

Also die die 7170 hat keinen "AVM"-Inted. Das Standard Package "inetd" ist aber mit einem [X] vorausgewählt und kann hier nicht abgewählt werden.

Im Grunde kann ich den auch benutzen wenn er eh schon da ist. Ich hab das nur aus der FAQ anders rausgelesen...

iptables-cgi: Wenn du iptables-cgi auswählst, dann werden einige Module davon fest ausgewählt, die kann man dann nicht manuell abwählen. Das müsstest du in der Config.in ändern oder iptables-cgi nicht auswählen..

So ähnlich mach ich das gerade. Das erste Auswählen mach ich mit der standard Config.in. Wodurch viel mit einem [X] vorselektiert wird. Danach mach ich dort das "select FREETZ_PACKAGE_IPTABLES_STANDARD_MODULES" raus und wähl ab was ich nicht brauch.

Auch das hab ich aus der FAQ irgendwie anders rausgelesen.

 

[olistudent]

ip_conntrack: Wenn es im menuconfig nicht ausgewählt ist und deshalb in der .config nicht als =y auftaucht, dann sollte es auch nicht im Image landen.

inetd: Bist du sicher? Für mich sieht das so aus als würde AVM den inted auf der 7170 nutzen.

Gruß
Oliver

 

[Wiedmann]

ip_conntrack: Wenn es im menuconfig nicht ausgewählt ist und deshalb in der .config nicht als =y auftaucht, dann sollte es auch nicht im Image landen.

Dann stimmt da wohl was nicht. Liegt's vielleicht noch am Replace Kernel?

Müsst man mal "kurz" nochmals ein Build mit "menukonfig: ip_conntrack [ ]" und "kernel-menukonfig: ip_conntrack [X]" durchlaufen lassen. (Die kernel-menukonfig darf ich aber schon aufmachen und speichern?)

Müsste eh schauen, ob die Toolchain die er grad in der Jail gebaut hat tut ;-)
Wollte halt nur gleich eine Bauen die ich auch wirklich brauchen kann (mit Conntrack stürzt die Box bei 'nem simplen nmap ab).

inetd: Bist du sicher? Für mich sieht das so aus als würde AVM den inted auf der 7170 nutzen.

Laut Wiki:

Wenn man die voreingestellte Box auf eine andere umändert, bei welcher kein inetd verwendet wird/verwendet werden kann (z.B. 7170),

Also laufen hat man nach dem Firmwareupdate nur einen Inetd von der Busybox, der erst mal für nichts zuständig ist. Und in der inetd.conf stehen nur deaktivierte Einträge von Freetz drin, nichts von AVM.

 

[Wiedmann]

ip_conntrack: Wenn es im menuconfig nicht ausgewählt ist und deshalb in der .config nicht als =y auftaucht, dann sollte es auch nicht im Image landen.

Müsst man mal "kurz" nochmals ein Build mit "menukonfig: ip_conntrack [ ]" und "kernel-menukonfig: ip_conntrack [X]" durchlaufen lassen. (Die kernel-menukonfig darf ich aber schon aufmachen und speichern?)

Keine Ahnung was das letztens war. Aber kann das jetzt nicht mehr reproduzieren. Wenn's in der menukonfig aus ist, ist's jetzt auch nicht im Image.
War wohl doch mal nötig ein distclean zu machen ;-)


Was mir noch grad so auffällt...
Wenn ich unter "menuconfig -> Advanced options -> Toolchain options" auswähle:
- Build toolchain
- Build binutils and gcc for target

Ist das erzeugte Image deutlich größer als wenn ich sag "download and use precompiled version". Liegt insb. an der libuClibc-0.9.29.so, die dann deutlich größer ist. Auch sind es in "build-modified" dann ein paar Symlinks weniger. Sollte da nicht das Selbe rauskommen?
(und die Box hängt mit der Firmware in einer Rebootschleife)

 

[olistudent]

Die Größe ist natürlich von ein paar Optionen abhängig. Die fehlenden Symlinks würden mich interessieren?

Gruß
Oliver

 

[Wiedmann]

Die Größe ist natürlich von ein paar Optionen abhängig.

Und die da wären? Wenn ich eben sag ich will die Toolchain, binutils und gcc selbst bauen, dann ist die "libuClibc-0.9.29.so" ja über doppelt so groß als bei der Download-Version. Mit dem Ergebniss, dass schon ein Standard-Image nicht mehr auf die Box passt. Und an der Stelle kann man ja nur auswählen: download/selbst bauen.

Die fehlenden Symlinks würden mich interessieren?

Ich werde mal beide Versionen nochmal durchlaufen lassen und ein Verzeichnisvergleich vom Ergebnis machen. Dauert halt etwas...

 

[olistudent]

Die Größe wird maßgeblich durch die einkompilierten locales beeinflußt. Hier kannst du im menuconfig ein reduziertes locale set verwenden.

Gruß
Oliver

 

[Wiedmann]

Hier kannst du im menuconfig ein reduziertes locale set verwenden.

OK, das hab ich natürlich nicht abgeschaltet. Nachdem das aktuelle Build jetzt ja auch schon 'n paar Stunden läuft, lass ich den auch so fertig laufen...

Hier ist dann die Frage:
- Was muss ich einstellen, damit der Selbstbau dem Download entspricht?
- Warum ist das nicht die (Default-) Voreinstellung?

 

[Wiedmann]

Nachdem das aktuelle Build jetzt ja auch schon 'n paar Stunden läuft, lass ich den auch so fertig laufen...

Sodele, ist fertig.

Als erstes ein Build mit der Download-Toolchain (Anhang anzeigen .config-download.gz):

make distclean
make menuconfig
make

Da kommt dann raus:

  kernel image size: 7153408 (max: 7798784, free: 645376)
  Aproximately free time for the answering machine: 157s (2min 37s)
packing images/W900V_7170_04.87-freetz-devel-9778M.de_20121227-165803.image

Als nächstes ein Build mit der Eigenbau (Build Toolchain/bintutils/gcc) -Toolchain (Anhang anzeigen .config-build.gz):

make distclean
make toolchain
make menuconfig
make

Da kommt dann raus:

  kernel image size: 7567104 (max: 7798784, free: 231680)
  WARNING: Not enough free flash space for answering machine!
packing images/W900V_7170_04.87-freetz-devel-9778M.de_20121227-225407.image

Interessant hier schon, der Unterschied in der Download-Toolchain:

2219302 mipsel_gcc-3.4.6-freetz-r9637-shared-glibc.tar.lzma
8930569 mipsel_gcc-4.6.3_uClibc-0.9.29-freetz-r9637-shared-glibc.tar.lzma

Und der Gebauten:

2219302 mipsel_gcc-3.4.6-freetz-r9637-shared-glibc.tar.lzma
2036860 mipsel_gcc-3.4.6.tar.lzma

Der Unterschied in der uClibc ist
Download:

410640 libuClibc-0.9.29.so

Gebaut:

644124 libuClibc-0.9.29.so

Bei einem "diff -rq build-toolchain/ donwload-toolchain/" kommt Anhang anzeigen diff-dirs.txt.gz raus.

Ich hab mal in jedem Verzeichnis ein "find . -printf '%y\t%s\t%p\n'" gemacht. Dabei kommt dann Anhang anzeigen dir-build.txt.gz und Anhang anzeigen dir-download.txt.gz raus.

Ein "diff -u" auf diese 2 Ergebnisse ergibt Anhang anzeigen diff-find.txt.gz

(auch scheint die Box mit dem Image der selbst gebauten Toolchain nicht wirklich zu laufen: Reboot-Schleife)

 

[olistudent]

Die Optionen für die Download-Toolchain sind aus diesem Skript ersichtlich.

Eine Auswahl von "build toolchain for target" wählt einige Libraries mit aus:

config FREETZ_TARGET_TOOLCHAIN
	select FREETZ_LIB_libgmp
	select FREETZ_LIB_libmpfr
	select FREETZ_LIB_libmpc
	bool "Build binutils and gcc for target" if FREETZ_BUILD_TOOLCHAIN

Warum er hier angeblich gcc-3.4.6 als Target-Compiler verwendet muss ich erst untersuchen...

Gruß
Oliver

p.s. Ich kann das mit dem gcc-3.4.6 nicht nachvollziehen:

-rw-r--r-- 1 oliver oliver 2443816 Dez 28 09:49 mipsel_gcc-3.4.6.tar.lzma
-rw-r--r-- 1 oliver oliver 13444700 Dez 28 09:50 mipsel_gcc-4.6.3_uClibc-0.9.29.tar.lzma

 

[er13]

@Oliver: wie kommst Du darauf, dass gcc-3.4 als target compiler verwendet wird? In den beiden configs steht FREETZ_TARGET_COMPILER_GCC_4_6=y.

@Wiedmann: libuClibc-0.9.29.so ist wie Oliver schon geschrieben hat wegen FREETZ_TARGET_UCLIBC_REDUCED_LOCALE_SET größer. Du musst in Deinem custom-build diese einschalten. Ansonsten hast Du glaube ich Dich beim Vergleichen vertan (mipsel_gcc-3.4.6.tar.lzma als target-toolchain?). Zusätzlich wird die download-toolchain mit FREETZ_TOOLCHAIN_32BIT=y gebaut, d.h. die auf Deinem-System gebauten host-binaries können sich von den host-binaries der download-toolchain unterscheiden. Die target-binaries sollten aber in etwa gleich groß sein.

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.

 

[olistudent]

@Oliver: wie kommst Du darauf, dass gcc-3.4 als target compiler verwendet wird? In den beiden configs steht FREETZ_TARGET_COMPILER_GCC_4_6=y.

Aus den beiden Dateien die er aufgelistet hat. Aber da scheint er sich wirklich vertan zu haben...

Gruß
Oliver

 

[Wiedmann]

@Oliver: wie kommst Du darauf, dass gcc-3.4 als target compiler verwendet wird? In den beiden configs steht FREETZ_TARGET_COMPILER_GCC_4_6=y.
...
@Wiedmann: Ansonsten hast Du glaube ich Dich beim Vergleichen vertan (mipsel_gcc-3.4.6.tar.lzma als target-toolchain?).

Nach "make toolchain" landen genau 2 LZMA-Dateien in "./dl". Eine davon nennt sich "mipsel_gcc-3.4.6.tar.lzma" mit der Größe 2036860 Byte, im Gegensatz zu "mipsel_gcc-4.6.3_uClibc-0.9.29-freetz-r9637-shared-glibc.tar.lzma" und der Größe 8930569 Byte bei der Download-Toolchain. Ein Blick in "./source" lässt allerdings Vermuten, dass er zum Bau des Targets schon den 4.6.3 nimmt.

Die "mipsel_gcc-3.4.6-freetz-r9637-shared-glibc.tar.lzma" mit der Größe 2219302 Byte ist in beiden Fällen die Selbe.

@Wiedmann: libuClibc-0.9.29.so ist wie Oliver schon geschrieben hat wegen FREETZ_TARGET_UCLIBC_REDUCED_LOCALE_SET größer. Du musst in Deinem custom-build diese einschalten.

Ok, hab ich jetzt mal zusätzlich aktiviert und das Build gestartet. Kann dauern...

Zusätzlich wird die download-toolchain mit FREETZ_TOOLCHAIN_32BIT=y

Ist zwar in menuconfig nicht aktiv ausgewählt, aber macht bei meinem 32bit System natürlich Sinn.

Aus den beiden Dateien die er aufgelistet hat. Aber da scheint er sich wirklich vertan zu haben...

Wie gesagt, vor dem Build hab ich jeweils vohandene LZMA-Dateien gelöscht, und nach dem Build geschaut was da ist ("ls -l" copy 'n paste).

Die fehlenden Symlinks würden mich interessieren?

Hast du das mal verglichen? Bei der Download-Toolchain hab ich z.B. in "/build/modified/filesystem/lib" einen Symlink libcrypt.so->libcrypt.so.0, welcher bei der Build-Toolchain nicht vorhanden ist.

Solange die Binaries gegen libcrypt.so.0 oder libcrypt-0.9.29.so gelinkt sind wäre das natürlich kein Problem. Analog bei den anderen Dateien/Symlinks die nur in einem der Verzeichnisse vorhanden sind.

 

[olistudent]

Fehlen denn die Symlinks wirklich in deinem Toolchain-Verzeichnis?

oliver@Latitude:~/freetz/freetz-trunk/toolchain/build/mipsel_gcc-4.6.3_uClibc-0.9.29/mipsel-linux-uclibc/lib$ ls -l *.so |grep ".so.0"
lrwxrwxrwx 1 oliver oliver     10 Dez 28 09:44 libdl.so -> libdl.so.0
lrwxrwxrwx 1 oliver oliver      9 Dez 28 09:44 libm.so -> libm.so.0
lrwxrwxrwx 1 oliver oliver     11 Jun 16  2012 libnsl.so -> libnsl.so.0
lrwxrwxrwx 1 oliver oliver     15 Dez 28 09:44 libpthread.so -> libpthread.so.0
lrwxrwxrwx 1 oliver oliver     14 Jun 16  2012 libresolv.so -> libresolv.so.0
lrwxrwxrwx 1 oliver oliver     10 Dez 28 09:44 librt.so -> librt.so.0
lrwxrwxrwx 1 oliver oliver     16 Dez 28 09:49 libuClibc++.so -> libuClibc++.so.0
lrwxrwxrwx 1 oliver oliver     12 Dez 28 09:44 libutil.so -> libutil.so.0

Gruß
Oliver

 

[er13]

Nach "make toolchain" landen genau 2 LZMA-Dateien in "./dl". Eine davon nennt sich "mipsel_gcc-3.4.6.tar.lzma" mit der Größe 2036860 Byte, im Gegensatz zu "mipsel_gcc-4.6.3_uClibc-0.9.29-freetz-r9637-shared-glibc.tar.lzma" und der Größe 8930569 Byte bei der Download-Toolchain. Ein Blick in "./source" lässt allerdings Vermuten, dass er zum Bau des Targets schon den 4.6.3 nimmt.

Die "mipsel_gcc-3.4.6-freetz-r9637-shared-glibc.tar.lzma" mit der Größe 2219302 Byte ist in beiden Fällen die Selbe.

Irgendetwas bringst Du da durcheinander. Habe freetz-trunk extra frisch ausgecheckt, leeres dl-Verzeichnis angelegt, in der .config FREETZ_BUILD_TOOLCHAIN=y eingestellt und "make toolchain" aufgerufen. Ergebnis: zwei tar.lzma Dateien:

• mipsel_gcc-3.4.6.tar.lzma (2219429 bytes) - wie erwartet die kernel-toolchain
• mipsel_gcc-4.6.3_uClibc-0.9.29.tar.lzma (8918467 bytes) - wie erwartet die download-toolchain
• und die Symlinks sind auch alle vorhanden

Mit anderen Worten, alles wie erwartet. Entweder hast Du Dich vertan und einfach die falschen Dateien/Verzeichnisse verglichen oder Du hast irgendwelche Modifikationen vorgenommen, von denen Du uns nicht berichtet hast, die aber eben das von Dir beschriebene Verhalten verursachen. Ich tendiere eher zu eins, Du hast da was beim Vergleichen einfach durcheinander gebracht.

 

[Wiedmann]

Fehlen denn die Symlinks wirklich in deinem Toolchain-Verzeichnis?

Ich hab da:

cwiedmann:~/freetz-devel/toolchain/build/mipsel_gcc-4.6.3_uClibc-0.9.29/mipsel-linux-uclibc/lib$ ls -l *.so |grep ".so.0"
lrwxrwxrwx 1 cwiedmann cwiedmann     13 2012-12-28 12:34 libcrypt.so -> libcrypt.so.0
lrwxrwxrwx 1 cwiedmann cwiedmann     10 2012-12-28 12:34 libdl.so -> libdl.so.0
lrwxrwxrwx 1 cwiedmann cwiedmann      9 2012-12-28 12:34 libm.so -> libm.so.0
lrwxrwxrwx 1 cwiedmann cwiedmann     15 2012-12-28 12:34 libpthread.so -> libpthread.so.0
lrwxrwxrwx 1 cwiedmann cwiedmann     10 2012-12-28 12:34 librt.so -> librt.so.0
lrwxrwxrwx 1 cwiedmann cwiedmann     16 2012-12-27 19:30 libuClibc++.so -> libuClibc++.so.0
lrwxrwxrwx 1 cwiedmann cwiedmann     12 2012-12-28 12:34 libutil.so -> libutil.so.0

Wenn ich jetzt aber nach "/build/modified/filesystem/lib" gehe und ein:

ls -l | grep -E "libcrypt.so|libdl.so|libm.so|libpthread.so|librt.so|libuClibc++.so|libutil.so"

mache, bekomme ich nur:

lrwxrwxrwx 1 cwiedmann cwiedmann      18 2012-12-28 15:48 libcrypt.so.0 -> libcrypt-0.9.29.so
lrwxrwxrwx 1 cwiedmann cwiedmann      15 2012-12-28 15:48 libdl.so.0 -> libdl-0.9.29.so
lrwxrwxrwx 1 cwiedmann cwiedmann      14 2012-12-28 15:48 libm.so.0 -> libm-0.9.29.so
lrwxrwxrwx 1 cwiedmann cwiedmann      20 2012-12-28 15:48 libpthread.so.0 -> libpthread-0.9.29.so
lrwxrwxrwx 1 cwiedmann cwiedmann      15 2012-12-28 15:48 librt.so.0 -> librt-0.9.29.so

Mit der Download-Toolchain ist das dort:

lrwxrwxrwx 1 cwiedmann cwiedmann      13 2012-12-27 16:57 libcrypt.so -> libcrypt.so.0
lrwxrwxrwx 1 cwiedmann cwiedmann      18 2012-12-27 16:57 libcrypt.so.0 -> libcrypt-0.9.29.so
lrwxrwxrwx 1 cwiedmann cwiedmann      10 2012-12-27 16:57 libdl.so -> libdl.so.0
lrwxrwxrwx 1 cwiedmann cwiedmann      15 2012-12-27 16:57 libdl.so.0 -> libdl-0.9.29.so
lrwxrwxrwx 1 cwiedmann cwiedmann       9 2012-12-27 16:57 libm.so -> libm.so.0
lrwxrwxrwx 1 cwiedmann cwiedmann      14 2012-12-27 16:57 libm.so.0 -> libm-0.9.29.so
lrwxrwxrwx 1 cwiedmann cwiedmann      15 2012-12-27 16:57 libpthread.so -> libpthread.so.0
lrwxrwxrwx 1 cwiedmann cwiedmann      20 2012-12-27 16:57 libpthread.so.0 -> libpthread-0.9.29.so
lrwxrwxrwx 1 cwiedmann cwiedmann      10 2012-12-27 16:57 librt.so -> librt.so.0
lrwxrwxrwx 1 cwiedmann cwiedmann      15 2012-12-27 16:57 librt.so.0 -> librt-0.9.29.so

Mir fällt auch gerade auf, dass es nur beim Selbstbau ein Verzeichnis "/build/modified/filesystem/usr/lib/freetz" gibt?

Ok, hab ich jetzt mal zusätzlich aktiviert und das Build gestartet. Kann dauern...

So, ist etwas besser geworden. Das Kernel image ist jetzt nur noch 7472896 Bytes statt 7567104 Bytes. Aber immer noch mehr als 7153408 Bytes.
Die libuClibc-0.9.29.so ist jetzt aber zumindest gleich groß.

Habe freetz-trunk extra frisch ausgecheckt, leeres dl-Verzeichnis angelegt, in der .config FREETZ_BUILD_TOOLCHAIN=y eingestellt und "make toolchain" aufgerufen. Ergebnis: zwei tar.lzma Dateien:
und die Symlinks sind auch alle vorhanden

Wenn du jetzt die .config so wie oben angehängt unverändert ins Verzeichnis kopiert hättest, wäre es sogar vergleichbar gewesen.

Aber wo erwartet ihr die Symlinks? Mir ist bei denen halt aufgefallen, dass die in "/build/modified/filesystem/" nicht vorhanden sind.

 

[er13]

Mir fällt auch gerade auf, dass es nur beim Selbstbau ein Verzeichnis "/build/modified/filesystem/usr/lib/freetz" gibt?

So, ist etwas besser geworden. Das Kernel image ist jetzt nur noch 7472896 Bytes statt 7567104 Bytes. Aber immer noch mehr als 7153408 Bytes.

Hat Oliver oben schon geschrieben. In Deiner .config-build steht

FREETZ_LIB_libgmp=y
FREETZ_LIB_libmpfr=y
FREETZ_LIB_libmpc=y

Entweder auslagern oder nicht wundern, warum es größer ist.

Wenn du jetzt die .config so wie oben angehängt unverändert ins Verzeichnis kopiert hättest, wäre es sogar vergleichbar gewesen.

Kann ich auch machen, glaube aber nicht, dass es was ändern wird. Du hast da eindeutig Birnen mit Äpfeln verglichen (mipsel_gcc-3.4.6.tar.lzma vs. mipsel_gcc-4.6.3_uClibc-0.9.29-freetz-r9637-shared-glibc.tar.lzma).

 

[Wiedmann]

Hat Oliver oben schon geschrieben. In Deiner .config-build steht

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

Ausgehen tue ich ja wie gesagt von einer simplen Config (Boxauswahl, Replace Kernel + IPv6, remove Patches) mit dem normalen "download Toolchain" (also ohne weitere Einstellungen in advanced options). Als nächstes nehm ich die selbe Config, und sag nur noch zusätzlich "Build Toolchain" und "Build gcc/binutils".

Warum sind da jetzt die Voreinstellungen für die Builds anders, als wenn ich es fertig runterlade?
Bzw: Wo genau sind die Einstellungen im Wiki/Source dokumentiert, um genau die Downloadversion zu erreichen?