Ds26 heißt jetzt Freetz

[someone86]

ich erhalte beim kompilieren folgenden fehler:

/home/test/freetz-trunk/toolchain/build/gcc-4.2.1-uClibc-0.9.28/mipsel-linux-uclibc/usr/lib/libid3tag.la
cp -a /home/test/freetz-trunk/toolchain/build/gcc-4.2.1-uClibc-0.9.28/mipsel-linux-uclibc/usr/lib/libid3tag*.so* root/lib/
cp: Aufruf von stat für     „/home/test/freetz-trunk/toolchain/build/gcc-4.2.1-uClibc-0.9.28/mipsel-linux-uclibc/usr/lib/libid3tag*.so*****“ nicht möglich: Datei oder Verzeichnis nicht gefunden
make: *** [root/lib/libid3tag.so.0.3.0] Fehler 1

hmm ich dachte das wurde laut http://www.freetz.org/ticket/60 in Revision 1851 gefixt.

Ich habe 1994 ausgecheckt.

Edit: Sorry war mein Fehler hätte automake1.8 installieren sollen.

Gruß
someone86

 

[Silent-Tears]

/home/test/freetz-trunk/source/libid3tag-0.15.1b/missing: line 46: aclocal-1.8: command not found
[...]
/home/test/freetz-trunk/source/libid3tag-0.15.1b/missing: line 46: automake-1.8: command not found

Zumindest hast du nciht alles auf deinem System, was denn im Wiki steht.

 

[someone86]

Ich wolle nur mal anregen das es gut wäre wenn es am anfang einen check geben würde ob mal alles notwendige installiert hat. Wenn sowas möglich ist?

Gruß
someone86

 

[kriegaex]

Der müßte von Linux-Distribution zu Distribution anders aussehen und wäre relativ aufwendig zu machen. Die Intelligenz sitzt vor dem Computer, und wenn Du die Liste im Wiki durchgehst und nichts vergißt, hast Du auch kein Problem. Das Denken wollen wir Dir bewußt nicht abnehmen.

 

[balou1974]

Die Änderungen von 1992 auf 1994 sind ja gewaltig Ich vermute einer unserer Entwickler hat Überstunden abgefeiert - Nein im Ernst, es sieht so aus als wäre wieder vieles aktuallisiert worden. Wieder einmal Danke ans Team!

Gruss Manuel

 

[olistudent]

configure: checking for LZO Library and Header files...
checking lzo/lzo1x.h usability... yes
checking lzo/lzo1x.h presence... yes
checking for lzo/lzo1x.h... yes
checking for lzo1x_1_15_compress in -llzo2... yes
configure: checking for OpenSSL Crypto Library and Header files...
checking openssl/evp.h usability... yes
checking openssl/evp.h presence... yes
checking for openssl/evp.h... yes
checking for EVP_CIPHER_CTX_init in -lcrypto... no
configure: error: OpenSSL Crypto library not found.
make: *** [source/openvpn-2.1_rc7/.configured] Fehler 1

Sollte mit r1996 gefixt sein. Die Openssl-Libs wurden nicht gebaut.

MfG Oliver

 

[McNetic]

Also, ich finde die Idee mit dem Vorraussetzungen überprüfen gar nicht mal so schlecht. Ein einfaches

for program in make gcc g++; do
  which $program > /dev/null || { echo "required program '$program' was not found in path"; exit; }
done

kann für executables schon Wunder wirken, und die meisten Vorraussetzungen sind nunmal executables. Für die kleine Hand voll anderer Vorraussetzungen könnte man sich dann noch eine einfache Möglichkeit überlegen, den Library-Pfad zu durchsuchen. Wenn man dem Mechanismus nicht traut, kann man die Meldungen auch nur als Warnungen ausgeben und das exit weglassen...

Damit könnte man evtl. eine Menge überflüssiger Fragen vom Forum fernhalten, oder?

 

[Silent-Tears]

Die Änderungen von 1992 auf 1994 sind ja gewaltig Ich vermute einer unserer Entwickler hat Überstunden abgefeiert

*lach* Nö, sowas machen wir nebenher.

Dennoch: Danke.

LG

cinereous/Silent-Tears

 

[wengi]

<OFFTOPIC>

Die Intelligenz sitzt vor dem Computer, und wenn Du .....

Ein seit Jahren herrschender Irrglaube! :lol:
Sorry, aber das musste ich loswerden.
wengi
</OFFTOPIC>

 

[kriegaex]

Ein einfaches

for program in make gcc g++; do
  which $program > /dev/null || { echo "required program '$program' was not found in path"; exit; }
done

kann für executables schon Wunder wirken, und die meisten Vorraussetzungen sind nunmal executables.

Ja, auch wieder richtig. Wenn ich mal wieder Zeit habe... Schreib mal ein Ticket dazu, damit es nicht vergessen wird. Allerdings wäre eine Lösung mit Autoconf schon besser, nur kenne ich mich damit nicht aus. Es sind ja nicht nur Dateinamen zu prüfen, teilweise auch Versionen. Ich kann das heuristisch auch manuell hacken, aber eine Standardsoftware hätte schon ihre Vorteile.

 

[McNetic]

#93

Mit autoconf kenn ich mich auch nicht aus. Hatte auch schon daran gedacht, allerdings - das produziert viel Output, und das scheint grundsätzlich etwas zu sein, was den 'einfachen' User überfordert. Aber vielleicht wär das trotzdem die optimale Lösung.

 

[Silent-Tears]

Allerdings wäre eine Lösung mit Autoconf schon besser

autoconf hat einige Schwierigkeiten beim cross-compilen, von daher sollte man vielleicht doch einigermassen händisch die Sachen verwalten. So viele dependencies sind es ja nun irgendwie auch nicht, oder?

 

[McNetic]

Also, Probleme bezüglich des Cross-Compilings im autoconf sind doch für uns irrelevant - die Cross-Build-Umgebung bauen wir doch komplett selbst (bzw. laden sie runter). Bei den Vorraussetzungen geht es ja nur um die Vorraussetzungen für die Tools, die wir drumherum brauchen, also im Grunde einfache Paketabhängigkeiten bezüglich der benutzten Linux-Distribution.

So gesehen ist autoconf aber wirklich mit Kanonen auf Spatzen schiessen; wir wollen momentan ja nur sicherstellen, daß bestimmte Pakete vorhanden sind. Autoconf würde darüber hinaus ja auch noch versuchen, die diversen Abhängigkeiten 'irgendwie' zu erfüllen und somit die ganze Freetz-Distribution betriebssystemunabhängiger zu machen (wobei das in meinen Augen widersinnig ist, weil man sich dann eben autoconf-abhängig macht - ob das besser ist, bezweifle ich mal).

Ergo: Die simpelste Lösung scheint mir momentan die Beste zu sein.

 

[RalfFriedl]

Änderung der .config für r1994

In SVN 1994 wurde auch die Konfiguration von DS_ nach FREETZ_ umgestellt. Wer seine alte .config weiter verwenden will, kann mit diesem sed-Kommando die .config anpassen.

sed -i -e 's/DS_/FREETZ_/g' .config

Wer trotzdem Probleme hat, sollte komplett mit einem neuen Checkout anfangen.

 

[balou1974]

Ich habe den möglicherweise subjektiven Eindruck das die Images seit der Rev. 1994 deutlich kleiner werden, kann das sein? (sie funktionieren klaglos...)


Gruss Manuel

 

[cuma]

Klar, wahscheinlich hast du eine .config erstellt und damit nur sinnvolle Dinge ausgewählt

 

[buergernb]

Hi,

hab grad mal frisch ausgecheckt (2004) und nun beim MAKE-Prozess folgende Fehlermeldung erhalten:

applying patch file ./patches/440-storage_dont_kill_samba.sh
  alter /etc/hotplug/storage: dont kill smbd (if found)
    applying patch file ./patches/cond/storage_dont_kill_smbd.patch
    patching file etc/hotplug/storage
    Hunk #1 FAILED at 70.
    Hunk #2 succeeded at 254 with fuzz 1 (offset 1 line).
    Hunk #3 succeeded at 296 with fuzz 1 (offset 10 lines).
    1 out of 3 hunks FAILED -- saving rejects to file etc/hotplug/storage.rej
    ----------------------------------------------------------------------
ERROR: modpatch: Error in patch-file ./patches/cond/storage_dont_kill_smbd.patch
make: *** [firmware-nocompile] Fehler 2

Achso, "make clean" habe ich natürlich vorher ausgeführt.
Hab ich wieder was falsch gemacht oder ist das ein "richtiger" Fehler?


BuergerNB

 

[cuma]

Lag am samba, ich habs gefixt. Lad es bitte neu runter, du kannst es einfach drüber auspacken. Dirclean sollte nicht erforderlich sein

 

[buergernb]

Hi cuma,

hab den Beitrag vorher gerade bearbeitet, weil ich das ganze auch ohne deine Patches probiert habe und den gleichen Fehler bekommen habe.
"make clean" auch da vorher ausgeführt.

BuergerNB

 

[cuma]

Die Datei "patches/440-storage_dont_kill_samba.sh" ist aber nicht Bestandteil vom svn. Ich konnte den Fehler reproduzieren und wie gesagt gefix. > Post #559