You are not logged in.

Anzeigen

MLDonkey für Unslung 5.5 compiliern (scheitert beim Start)

nslu2-info.de ist ein privates Projekt von mir, welches jeden Monat aus eigener Tasche finanziert wird. Mit einer freiwilligen Spende wird der Erhalt und der weitere Ausbau dieses Forums unterstützt. Um mich beim Erhalt des Forums zu unterstützen, kannst Du entweder via Flattr oder Paypal spenden. Ich bedanke mich schon jetzt bei allen Unterstützern.

vbherodes

Beginner

  • "vbherodes" started this thread

Posts: 2

  • Send private message

1

Saturday, March 4th 2006, 9:51am

MLDonkey für Unslung 5.5 compiliern (scheitert beim Start)

Hallöchen,

ich habe schon mehrere Quellen zum Thema gelesen und beschäftige mich seit ca. 1 Woche damit auf irgendeine Art und Weise einen funktionsfähigen MLdonkey auf der Box zu compilieren.

Meine bisherigen Erfahrungen ein wenigen Steps:

- mldonkey-2.7.4.tyr.bz2 herunter geladen
- entpackt
- ./configure liefert erst mal eine Fehlermeldung, dass er libz nicht finden kann.
- über Stunden gegoogelt, folgendes gefunden:
export CPPFLAGS=I-/opt/include
export LDFLAGS=-L/opt/lib
- ./configure => OK funzt !
- make
*rödel rödel rödel (ca 1 Stunde)*
- ein paar Warnungen (aber die machen wahrscheinlich den Stress)
- es wird tatsächlich ein mlnet Binary erzeugt, allerdings beim starten stürzt es ab mit segmentation fault!


-> gegoogelt, die Erkenntnisse:
- es gibt wohl ein Problem mit der CryptoPP.?? welche wohl nicht korrekt auf Big- oder Little-Endian prüft und deshalb was versaubeutelt.
- es gibt ein Patch-File 4657.patch (http://savannah.nongnu.org/patch/?func=detailitem&item_id=4657), welche aber nicht zu dieser Version passt (logisch, es hat sich warhscheinlich genügend geändert :-))
- von Hand auseinander zu klamüsern, was sich der "Patcher" gedacht hat macht glaub ich wenig Sinn (und kostet wohl EXTREM viel Zeit), da sich der Code evtl komplett geändert hat.
- Es kommen beim compilieren Warnmeldungen , dass ein Pointertyp nicht passt.

-> versucht mit gdb was zu finden, der meckter folgendes an:

(gdb) start
Breakpoint 1 at 0x2c019c
Starting program: /download/move/mldonkey-2.7.4/mlnet
0x002c019c in main ()
(gdb) step
Single stepping until exit from function main,
which has no line number information.
2006/03/04 09:37:56 Starting MLDonkey 2.7.4 ...
2006/03/04 09:37:56 Language EN, locale ANSI_X3.4-1968, ulimit for open files 1024
2006/03/04 09:37:56 MLDonkey is working in /user/.mldonkey

Program received signal SIGSEGV, Segmentation fault.
0x002c58c4 in caml_string_equal ()
(gdb)


-> nächster Ansatz -> crosstool
- momentan breche ich mir einen ab das Crosstool - Geraffel zum laufen zu bringen, aber ich glaube, dass es das Problem nicht lösen wird.


Habt Ihr diesbezüglich schon Erfahrungen gemacht?

(Ich möchte keine Diskussion auslösen über ein für und wieder von mldonkey!, es ist für mich die beste Wahl!)
Ich denke einige würden den mldonkey schon gerne mal antesten.
Wenn jemand dabei ist, der mit solchen Problemen mehr Erfahrung hat als ich (und das ist nicht schwer J), bitte ich Ihn um Hilfe.

Vielen Dank bereits im Voraus.
Anzeigen

Eiffel

Professional

Posts: 619

Occupation: SAP Anwendungsbetreuer

  • Send private message

2

Tuesday, March 7th 2006, 2:12pm

hm hatte segmentation fault nicht was mit nem speicher addressierungs problem zu tun ? evtl musst du mldonkey so compilieren das es maximal 16mb ram versucht zuaddressiern oder sowas
Anzeigen

thomas2099

Beginner

Posts: 6

wcf.user.option.userOption65: anderes

  • Send private message

3

Friday, March 10th 2006, 12:51pm

kleiner tip nimm debian(LE) als image. da gibt es mldonkey schon vorkompiliert. als package zum installieren. empfehlen kann ich version 2.7.1 das aktuellste package läuft recht unstabil.
habe das selbstkompilieren inzwischen aufgegeben ;)

vbherodes

Beginner

  • "vbherodes" started this thread

Posts: 2

  • Send private message

4

Friday, March 31st 2006, 10:44pm

Momentan bin ich auf einem guten Weg.

Ich habe de NUSCHL (NSLU) soweit, dass ich ein gentoo chrooten Kann mit GLIBC.(da sucht man sich dumm, bis man dann einezeimlich alte Gentoo Stage 3 für Arm findet, wo glibc statt uclibc verwendet wird)

Darauf habe ich ein aktelle OCAML compilieren lassen und dann einen MLdonkey. Der hat zwar irgendetwas gemeckert, allerdings läuft das binary stressfrei und auch schon im dauertest (naja 2 Tage) stabil durch.

ALLERDDINGS ist es mit den 32 MB RAM echt eng im NUSCHL und ich werde wohl das RAM Upgrade noch durchführen müssen (geplant sind 128 MB).

Dann sollte eigentlich alles stressfrei und ohne Dauerswappen laufen.

Wer genaueres wissen will, meldet sich einfach :-)

MfG

Social bookmarks