Erstellt vor 6 Jahren

Zuletzt geändert vor 6 Jahren

#1999 new enhancement

Freetz unter FreeBSD (PC-BSD, *BSD) bzw. Debian GNU/kFreeBSD benutzen

Erstellt von: Wiedmann Verantwortlicher:
Priorität: normal Meilenstein: freetz-future
Komponente: build-system Version: devel
Stichworte: Beobachter:
Product Id: Firmware Version:

Beschreibung

Hallo Freetz,

da ich (normal) nirgends Linux hab, habe ich mir das Buildsystem so angepasst, dass es native sowohl unter Linux, als auch unter FreeBSD (PC-BSD, *BSD) bzw. Debian GNU/kFreeBSD funktioniert.

(Theoretisch ist dieser Ansatz hier auch für OS-X gültig. Hab nur gerade keinen Zugriff auf einen Mac)



Als Vorbereitung sind unter FreeBSD folgende Ports/Pakete zu installieren:

  • automake
  • bash
  • bison
  • gawk
  • gmake
  • gsed
  • intltool
  • libtool
  • p5-String-CRC32
  • python27
  • subversion
  • unix2dos
  • unzip
  • wget
  • Sofern man AVM-Tagging benutzen möchte:
    • ImageMagick oder ImageMagick-nox11 oder GraphicsMagick
  • Bei FreeBSD ≤ 8.0 noch:
    • xz

Bei Debian GNU/kFreeBSD kann man sich an Installation der benötigten Pakete (Ubuntu) halten.


In seinem Homedir macht man dann ein:

svn co http://svn.freetz.org/trunk freetz-devel -r 9960
cd freetz-devel

In dieses Verzeichnis kopiert man dann den angehängten Patch.

Mit Subversion ≥1.7 macht man dann ein:

svn patch bsd_compat.patch

Mit Subversion < 1.7 (1.6.x) ein:

patch -p0 < bsd_compat.patch
svn add BSDmakefile
svn add make/busybox/patches/400-bsd_compat.busybox.patch
svn add make/libs/ncurses/patches/140-tic_path.ncurses.patch
svn add make/libs/uclibcxx/patches/305-scripts_shell.uclibcxx.patch
svn add make/libs/uclibcxx/patches/500-gmake.uclibcxx.patch
svn add make/linux/patches/2.6.13.1/9999-2.6.13.x-branch.gettext.patch
svn add toolchain/make/target/uclibc/0.9.29/565-utils_bsd_compat.patch
svn add tools/config.guess
svn propset svn:executable tools/config.guess
svn add tools/link_gnuutils
svn propset svn:executable tools/link_gnuutils
svn add tools/make/patch.mk
svn add tools/make/patches/105-fakeroot-scripts.fakeroot.patch
svn add tools/make/patches/115-bsd_compat.squashfs.patch
svn del tools/make/patches/115-osx.squashfs.patch
svn add tools/make/patches/220-bsd_compat.squashfs3.patch
svn del tools/make/patches/220-osx.squashfs3.patch
svn add tools/make/patches/230-fnm_extmatch.squashfs3.patch
rm tools/make/patches/400-bsd_compat.busybox.patch
ln -s ../../../make/busybox/patches/400-bsd_compat.busybox.patch tools/make/patches/400-bsd_compat.busybox.patch
svn add --force tools/make/patches/400-bsd_compat.busybox.patch
svn add tools/make/patches/bash.sfk.patch
svn add tools/make/patches/bsd_compat.sstrip.patch
printf '%s\n' gnuutils `svn propget svn:ignore tools` | sort -u > .ignore
svn propset -F .ignore svn:ignore tools
rm .ignore


Nun ein:

svn up

und schauen ob es Konflikte gibt. In dem Fall hier melden…


Als nächstes macht man ein:

make menuconfig

Dort wählt man aus

  • Level of user competence ⇒ Expert
  • Hardware type
  • evtl. Compile image for "alien" hardware
  • nach Bedarf:
    • IPv6 support
    • Replace kernel
  • unter Toolchain options:
    • Toolchains ⇒ Build own toolchains
    • Use reduced set of locales
    • Build binutils and gcc for target
    • Sofern man kein IPC auf dem System aktiviert hat:
      • Build fakeroot with TCP

Jetzt mit 2x exit rausgehen und die Config abspeichern.


Als nächstes ein:

make toolchain

Nach ein paar Kaffees befinden sich dann zwei *.lzma-Dateien in dl/.


Wer möchte patched jetzt noch "toolchain/make/download-toolchain.mk":

Index: toolchain/make/download-toolchain.mk
===================================================================
--- toolchain/make/download-toolchain.mk        (Revision 9960)
+++ toolchain/make/download-toolchain.mk        (Arbeitskopie)
@@ -15,7 +15,7 @@
 KERNEL_TOOLCHAIN_MD5:=$(KERNEL_TOOLCHAIN_MD5_$(KERNEL_TOOLCHAIN_ID))

 KERNEL_TOOLCHAIN_VERSION:=$(or $(KERNEL_TOOLCHAIN_VERSION_$(KERNEL_TOOLCHAIN_ID)),r9637)
-KERNEL_TOOLCHAIN_SOURCE:=$(TARGET_ARCH)_gcc-$(KERNEL_TOOLCHAIN_GCC_VERSION)-freetz-$(KERNEL_TOOLCHAIN_VERSION)-shared-glibc.tar.lzma
+KERNEL_TOOLCHAIN_SOURCE:=$(TARGET_ARCH)_gcc-$(KERNEL_TOOLCHAIN_GCC_VERSION).tar.lzma


 TARGET_TOOLCHAIN_ID:=$(TARGET_ARCH)_$(TARGET_TOOLCHAIN_GCC_VERSION)_$(TARGET_TOOLCHAIN_UCLIBC_VERSION)
@@ -27,7 +27,7 @@
 TARGET_TOOLCHAIN_MD5:=$(TARGET_TOOLCHAIN_MD5_$(TARGET_TOOLCHAIN_ID))

 TARGET_TOOLCHAIN_VERSION:=$(or $(TARGET_TOOLCHAIN_VERSION_$(TARGET_TOOLCHAIN_ID)),r9637)
-TARGET_TOOLCHAIN_SOURCE:=$(TARGET_ARCH)_gcc-$(TARGET_TOOLCHAIN_GCC_VERSION)_uClibc-$(TARGET_TOOLCHAIN_UCLIBC_VERSION)-freetz-$(TARGET_TOOLCHAIN_VERSION)-shared-glibc.tar.lzma
+TARGET_TOOLCHAIN_SOURCE:=$(TARGET_ARCH)_gcc-$(TARGET_TOOLCHAIN_GCC_VERSION)_uClibc-$(TARGET_TOOLCHAIN_UCLIBC_VERSION).tar.lzma

 $(KERNEL_TOOLCHAIN_DIR):
        @mkdir -p $@

Ermittelt die Checksummen:

md5 dl/*.lzma

und trägt diese Zwei noch passend in "toolchain/make/download-toolchain.mk" ein.

Damit könnte man in make menuconfigToolchain options wieder Download and use precompiled toolchains einstellen. Bzw. werden dann die so erstellen Dateien auch nach einem make distclean benutzt.

Es wäre natürlich schöner, wenn es dazu auch einen offiziellen Weg gäbe. Auch sollte das Make von selber bemerken, dass es für das aktuelle System keine Toolchain zum Downloaden gibt. Sonst wird immer eine Toolchain für ein x86-linux runtergeladen.


Damit wäre alles soweit bereit, um gemäß der Dokumentation seine Firmware zu bauen:

  • auswählen der Pakete und Patche
    • make menuconfig
  • erstellen der Firmware
    • make

Getestet ist das bei mir mit den Firmwares für W701V_7170, W900V_7170, 7270_V2, replace Kernel, IPv6 und den Paketen Dnsmasq, Openntpd, Samba, Iptables.

Sollte es Probleme mit anderer Hardware/Paketen geben, hier melden.


So, jetzt hoffe ich das ich nichts vergessen habe und wünsche gutes Gelingen :-)

Fragen und Rückmeldungen dann gerne wieder hier.

Anhänge (1)

bsd_compat.patch (149.3 KB) - hinzugefügt von Wiedmann vor 6 Jahren.
letzter Upload wurde nicht vollständig übertragen

Alle Anhänge herunterladen als: .zip

Änderungshistorie (17)

comment:1 Antwort: Geändert vor 6 Jahren durch roadman17

Ich werde das mal bei Gelegenheit auf einem Mac testen.
Da du kein Mac-System zum Testen hast, weise ich dich mal auf das PureDarwin-Projekt hin (http://www.puredarwin.org/). Ist aber wahrscheinlich nur zum Testen etwas zu aufwändig.

Ich habe mal so einen ähnlichen Patch erstellt (http://www.ip-phone-forum.de/showthread.php?t=254897). Deiner sieht aber vollständiger und auch sauberer aus. Für den Linux-Kernel musste ich auf meinem Mac-System noch Elf-Header-Dateien ergänzen.
Für die ucblibc-utils, die du auskommentiert hast, habe ich ein paar Header-Dateien ergänzt.

comment:2 als Antwort auf: ↑ 1 ; Antwort: Geändert vor 6 Jahren durch Wiedmann

Replying to roadman17:

Ich werde das mal bei Gelegenheit auf einem Mac testen.

Ich habe mal so einen ähnlichen Patch erstellt (http://www.ip-phone-forum.de/showthread.php?t=254897).

Yup, den hab ich auch gesehen. Der MAC-Kernel (XNU) stammt ja vom FreeBSD-Kernel ab und hat auch ein BSD-Userland. Daher die Idee das es mit OS-X so gehen könnte.

GNU find, GNU coreutils, GNU getopt sollten nicht mehr nötig sein. Ansonsten, wenn installiert, werden aber auch dafür passende Links erzeugt.

Ist das richtig, dass die beim MAC in "/opt/local/bin" landen?


Replying to roadman17:

Für die ucblibc-utils, die du auskommentiert hast, habe ich ein paar Header-Dateien ergänzt.

Yup, nur sind die uclibc-utils im Staging-Step gar nicht nötig. Für's Target werden sie ja dann erstellt.

comment:3 Antwort: Geändert vor 6 Jahren durch cuma

Doch etwas umfangreicher als erwartet… Das ganze funktioniert dann auch noch mit Linux?

comment:4 Antwort: Geändert vor 6 Jahren durch er13

@Wiedmann: "self-built-as-download-toolchain" baue ich ein (hast Du glaube ich schon in irgendeinem ippf-thread gefragt). Ich verwende seit langem dieselbe Methode wie die von Dir beschriebene, wird mal Zeit diese ordentlich umzusetzen.

Ansonsten habe ich mir schon immer gewünscht unter dem Vorwand "freetz auf Mac zu portieren" von einem spendierfreudigen freetz-User mal für ein paar Wochen ein Mac auszuleihen ;-)

Zuletzt geändert vor 6 Jahren von er13 (vorher) (Diff)

comment:5 als Antwort auf: ↑ 2 ; Antwort: Geändert vor 6 Jahren durch roadman17

Replying to Wiedmann:

Ist das richtig, dass die beim MAC in "/opt/local/bin" landen?

Die GNU-Werkzeuge landen dort, wenn du sie mit MacPorts installierst. Mit Homebrew landen sie aber standardmäßig in /usr/local/bin oder in einem selbst gewählten Verzeichnis. Deshalb sollte der Pfad durchsucht werden.

comment:6 als Antwort auf: ↑ 3 Geändert vor 6 Jahren durch Wiedmann

Replying to cuma:

Doch etwas umfangreicher als erwartet…

Sieht glaub nur so aus… [läster] Würden sich die Linuxer mehr an IEEE Std 1003.1 halten, wäre das gar nicht so ein Akt. ;-) [/läster]


Replying to cuma:

Das ganze funktioniert dann auch noch mit Linux?

Yup. Das ist ja der Plan, dass es einfach portabel ist.

Im Grunde kann man das glaub in 5 Hauptbereiche unterteilen.

Ein Teil sind einfach Patche für die Hosttools mit i.d.R. "#ifndef __linux__", wo die Linux-Header vom Rest abweichen. Gerade bei der Byte-Reihenfolge, Elf, oder wo man von der glibc ausgeht. Beim Kernel gibt es dann noch einen (Upstream-)Patch, damit kconfig gebaut werden kann, ohne das die (g-)libc gettext beinhalten muss. Was unter Umständen auch bei Linux der Fall sein kann.

Ein weiterer Teil ist, dass Kommandos wie find, tar, cp usw. Posix-Kompatibel eingesetzt werden. Linuxer haben da irgendwie die Angewohnheit, wie selbstverständlich die GNU-Erweiterungen zu benutzen *g*.
So zum Testen/Üben der Shellbefehle, kann ein Linuxer ja meist mal "—posix" anhängen, um zu schauen ob er kompatibel ist. "stat" muss man generell ersetzten. Ebenso benutzen von "/proc". Zu diesem Bereich zählt auch die schon besprochene Anpassung von "scriptpatcher.sh" (getopt → getopts).

Bei den ganzen Scripten wurde der Shebang (und die Shell für's Makefile) auf "/usr/bin/env bash" gesetzt, weil ja eigentlich nur bei Linux die Bash in "/bin" ist ("/bin" wäre bei mir auch schreibgeschützt. Also nichts mit Symlink). Normal kann man da ja nur eine "sh" erwarten. Da die Bash aber ja normal im Pfad ist, bleibt man mit "/usr/bin/env bash" portabel. Das Selbe für Perl.

Dann gibt es jetzt ein Script "tools/link_gnuutils", aufgerufen durch das Makefile, was mind. für "gmake", gsed, und gawk", Links im Verzeichnis "tools/gnuutils" unter dem Namen make, sed und awk erzeugt.
Es wurde im Makefile und den Scripten auch dafür gesorgt, dass "tools/gnuutils" an erster Stelle im Pfad steht.
Das "BSDmakefile" sorgt einfach dafür, dass man auch bei BSD einfach, wie in der Freetz-Doku angegeben, z.B. "make menuconfig" benutzen kann, und nicht "gmake menuconfig" nehmen muss.

Als letztes gibt es dann noch was zu ncurses (für z.B. Samba) und GNU patch zu erwähnen:

  • Mit BSD patch wären die Änderungen zu umständlich, also bleibt GNU patch. Allerdings ist GNU patch 1.6.1 die letzte Version, mit der Freetz funktioniert. Also baue ich das auf jeden Fall selber (liegt dann in "tools/gnuutils") und benutze nicht das patch vom System.
  • um das ncurses für das Target (Box) zu bauen, brauch man das "tic" vom Hostsytem für die terminfo-Datenbank. Allerdings kann Freetz nur damit umgehen, wenn die terminfo-Datenbank keine Hashed-DB ist, sondern verzeichnisorientiert. Bei "tic" ist es aber so, dass wenn es im Host mit Unterstützung für Hashed-DB gebaut wurde, auch nur diese Erzeugen kann. Als baue ich bei Bedarf auch "tic" selber, ohne "Hashed-DB. Liegt dann ebenfalls in "tools/gnuutils".
Zuletzt geändert vor 6 Jahren von Wiedmann (vorher) (Diff)

comment:7 als Antwort auf: ↑ 5 Geändert vor 6 Jahren durch Wiedmann

Replying to roadman17:

Replying to Wiedmann:

Ist das richtig, dass die beim MAC in "/opt/local/bin" landen?

Die GNU-Werkzeuge landen dort, wenn du sie mit MacPorts installierst. Mit Homebrew landen sie aber standardmäßig in /usr/local/bin oder in einem selbst gewählten Verzeichnis. Deshalb sollte der Pfad durchsucht werden.

Oki, grundsätzlich sollte man jetzt ja nur noch gmake, gsed und gawk benötigen, wo es dann auch wichtig ist, dass man sie über make, sed und awk aufrufen kann. Gesucht werden die i.M. in "/usr/local/bin" und "/opt/local/bin" und dann dafür die passende Links erstellt.

Zuletzt geändert vor 6 Jahren von Wiedmann (vorher) (Diff)

comment:8 als Antwort auf: ↑ 4 Geändert vor 6 Jahren durch Wiedmann

Replying to er13:

@Wiedmann: "self-built-as-download-toolchain" baue ich ein (hast Du glaube ich schon in irgendeinem ippf-thread gefragt). Ich verwende seit langem dieselbe Methode wie die von Dir beschriebene, wird mal Zeit diese ordentlich umzusetzen.

Yup. Das wäre cool.

Replying to er13:

Ansonsten habe ich mir schon immer gewünscht unter dem Vorwand "freetz auf Mac zu portieren" von einem spendierfreudigen freetz-User mal für ein paar Wochen ein Mac auszuleihen ;-)

Bis vor einiger Zeit hatte ich praktischerweise SSH-Zugriff auf'n Mac im RZ für manche Tests. Ist jetzt aber leider auch weggefallen.
Und VMWare macht auf meinem Notebook hier auch nicht wirklich Spaß. Sonst könnte man darin ja mal was auf OS-X testen.

comment:9 als Antwort auf: ↑ description Geändert vor 6 Jahren durch Wiedmann

Replying to Wiedmann:

Mit Subversion ≥1.7 macht man dann ein:

Mit Subversion < 1.7 (1.6.x) ein:

svn propset svn:executable tools/config.guess
svn propset svn:executable tools/link_gnuutils

Das ich das auch immer vergesse :-/. "svn:executable" tut zwar bei einem Checkout nach einem Commit, aber nicht beim Patch. Man sollte diese zwei Dateien dann auch noch ausführbar machen:

chmod 755 tools/config.guess
chmod 755 tools/link_gnuutils

comment:10 Geändert vor 6 Jahren durch cuma

  • Meilenstein auf freetz-future gesetzt
  • Typ von addition nach enhancement geändert

comment:11 Antwort: Geändert vor 6 Jahren durch roadman17

Wie es scheint, wurde dein letzter Patch nicht vollständig hochgeladen.
Außerdem lässt sich Freetz damit auch nicht unter OSX verwenden.

Durch "schlechte" Parameter (wahrscheinlich -c) funktioniert patch nicht.

Malformed Mach-o file

Busybox lässt sich nicht bauen (SIGWINCH, STRCHRNUL).

Nach Beheben dieser Fehler geht es aber auch nicht weiter.
Das Bauen von fakeroot endet mit

ld: symbol(s) not found for architecture x86_64

Danach habe ich aufgehört, da es auch an dem unvollständigen Patch liegen könnte.
Ich denke aber, dass keine großen Anpassungen für OSX notwendig sind, und dein Patch somit eine große Hilfe für eine nahezu vollständige Portierung darstellt.

Zuletzt geändert vor 6 Jahren von roadman17 (vorher) (Diff)

Geändert vor 6 Jahren durch Wiedmann

letzter Upload wurde nicht vollständig übertragen

comment:12 als Antwort auf: ↑ 11 Geändert vor 6 Jahren durch Wiedmann

Replying to roadman17:

Wie es scheint, wurde dein letzter Patch nicht vollständig hochgeladen.

Tatsache. Jetzt ist er aber komplett oben.


Durch "schlechte" Parameter (wahrscheinlich -c) funktioniert patch nicht.

Malformed Mach-o file

Den hab ich nicht ganz verstanden. Wenn patch ausgeführt wird (wie ist das dann vorher gegangen?), oder beim bauen?


Busybox lässt sich nicht bauen (SIGWINCH, STRCHRNUL).

Nach Beheben dieser Fehler geht es aber auch nicht weiter.

Ah, scheint so der MAC braucht da noch ein "#define _DARWIN_C_SOURCE 1" in "scripts/kconfig/mconf.c"? Nach "man 5 compat" kommt das aber noch auf die OSX-Version drauf an?


Das Bauen von fakeroot endet mit

ld: symbol(s) not found for architecture x86_64

Danach habe ich aufgehört, da es auch an dem unvollständigen Patch liegen könnte.

Da war glaub für fakeroot nichts mehr dabei.

Da hattest aber du glaub keinen Patch dafür drin? Ansonsten hab ich da nur noch den "tools/make/patches/105-fakeroot-scripts.fakeroot.patch". Den kannst mal weglassen.

(Die 2 Dateien von oben hast ausführbar genacht?)

comment:13 Geändert vor 6 Jahren durch roadman17

Warum patch sich nicht kompilieren lässt, weiß ich leider nicht. Manuell von der Kommandozeile mit den gleichen Parametern funktioniert es nämlich.
In der aktuellen git-Version von busybox wird _DARWIN_C_SOURCE schon gesetzt. Das ist aber erst mit neueren OSX-Versionen notwendig geworden.
Warum sich fakeroot sich plötzlich nicht mehr bauen lässt, untersuche ich dann noch. Wahrscheinlich werde ich Freetz zum Vergleich noch mal mit meinen Patchen bauen.
Ich werde dann irgendwann den Patch anpassen und hier anhängen.

So wichtig ist eine Unterstützung von OSX vorerst ja nicht. In diesem Ticket geht ja auch primär um FreeBSD.

comment:14 Geändert vor 6 Jahren durch er13

In 9983:

menuconfig:

  • add support for override options for download toolchains
  • refs #1939
  • refs #1999

From now on one can build his own toolchains and use them as download toolchains by overriding the corresponding options under "Override options/Override precompiled toolchain options":

  1. activate "Toolchain options/Build own toolchains"
  2. set toolchain related options to the desired ones under "Toolchain options"
  3. (optional) make your own modifications under $(freetz_root)/toolchain
  4. call "make KTV=freetz-${MY_VERSION}-${MY_SUFFIX} TTV=freetz-${MY_VERSION}-${MY_SUFFIX} toolchain"
  5. wait the build to complete
  6. (optional) upload created download toolchain files to some site

The toolchains created in steps above can then be reused:

  1. activate "Toolchain options/Download and use precompiled toolchains"
  2. activate "Override options/Override precompiled toolchain options"
  3. set version/suffix/md5/download-site values to the values used in the steps above
  1. adjust gcc/uClibc versions under "Toolchain options", set them to the same values as in step 2

comment:15 Geändert vor 6 Jahren durch er13

In 9989:

  • make "IPv6 support" selectable in FREETZ_DL_TOOLCHAIN_OVERRIDE mode (aka self-built toolchain as download-toolchain). The (expert) user is solely responsible for its proper configuration according to the setting used while building the download-toolchain used.
  • refs r9983, refs #1939, refs #1999

comment:16 Geändert vor 6 Jahren durch roadman17

@Wiedmann
Der Fehler "Malformed Mach-o file" kam bei von einer defekten Version von install. "install -s" hat dann das Binary unbrauchbar gemacht. Vorerst habe ich die Option -s entfernt.

Die von Homebrew installierten binutils haben den Kompiliervorgang gestört. Ich habe diese deinstalliert und er kommt nun bis busybox.

Die Logdateien bringen nun nichts mehr und können gelöscht werden, nur habe ich gerade nicht gesehen wie das geht.
Wenn ich busybox und sstrip von meiner funktionierenden Freetz-Installation verwende, kann ich die Toolchain bauen.

Zuletzt geändert vor 6 Jahren von roadman17 (vorher) (Diff)
Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.