[WHY]lib-elf.so.1 error

02/10/2012 18:18 lakus124#1
Hallo epvp,

Hier für euch ein kleines [WHY?] wegen dem lib-elf.so.1 error
Da viele ein Problem damit haben (vermehrt bei 64bit systemen) z.b. die game file revision 2019 oder 2089 einzubauen und dabei diesen error bekommen, möchte ich euch erklären woran dies liegt.

Die Gamefiles wurden auf Freebsd systemen kreeirt und sind auch nur für diese gedacht.
Eine Gamefile (oder auch ein anderer Core von den serverfiles) benötigt eine symbol tabelle, die nur auf freebsd systemen zu finden ist.

Kopiert man nun die gamefile von freebsd auf ein Windowssystem und läd sie dann auf ein anderes wieder hoch geht diese symbol tabelle verloren und die Game ist bis auf manche Ausnahmefälle unbrauchbar.

Packt man aber die gamefile vorher in ein tar.gz oder tar.bz2 archiv, passiert dies nicht und mann kann die gamefile 100 prozentig benutzen.

Dieser Thread ist auch dazu da um epvpler die gamefile releases machen darum zu bitten diese vorher in ein solches Archiv zu verpacken und erst dann hochzuladen
02/10/2012 18:35 A_Flashstyler#2
Quote:
Originally Posted by lakus124 View Post
Hallo epvp,

Hier für euch ein kleines [WHY?] wegen dem lib-elf.so.1 error
Da viele ein Problem damit haben (vermehrt bei 64bit systemen) z.b. die game file revision 2019 oder 2089 einzubauen und dabei diesen error bekommen, möchte ich euch erklären woran dies liegt.

Die Gamefiles wurden auf Freebsd systemen kreeirt und sind auch nur für diese gedacht.
Eine Gamefile (oder auch ein anderer Core von den serverfiles) benötigt eine symbol tabelle, die nur auf freebsd systemen zu finden ist.

Kopiert man nun die gamefile von freebsd auf ein Windowssystem und läd sie dann auf ein anderes wieder hoch geht diese symbol tabelle verloren und die Game ist bis auf manche Ausnahmefälle unbrauchbar.

Packt man aber die gamefile vorher in ein tar.gz oder tar.bz2 archiv, passiert dies nicht und mann kann die gamefile 100 prozentig benutzen.

Dieser Thread ist auch dazu da um epvpler die gamefile releases machen darum zu bitten diese vorher in ein solches Archiv zu verpacken und erst dann hochzuladen
Ist das so?
02/10/2012 18:39 lakus124#3
Jop
02/10/2012 19:53 Computerfreek#4
Komm schon, es tut wirklich schon weh so einen Scheiß zu lesen.
Wenn du keine Ahnung hast dann behalt deine von Grund auf falschen Aussagen bei dir.. Die Community ist schon doof genug, wir müssen die Leute nicht noch mehr verblöden.
02/10/2012 20:37 ~LuckyStrike~#5
Ja meines wissens nach wurden die Metin2 Files mit FreeBSD betrieben von der Gameforge
aber was zur Hölle sollte denn von den Files auf irgendeine Struktur von FreeBSD
zugreifen wollen ? Richtig - Nichts!

Sie sind Betriebsunabhängig ;)
Man kann so auf Debian, Ubuntu, FreeBSD u.s.w. nutzen wenn
man weiß wie ist das kein Aufwand. Also erzähl nicht so einen Stuss
wie mein vorposter schon sagte wenn du keine Ahnung hast oder
nur billige andeutungen ohne Beweise! Computerfreek sagte es bereits
schon und ich sags nochmal wir haben schon genug dummys hier
das heißt jetzt nicht das wir hervorhebend sind nur weil wir was können
was andere in der Community nicht können aber damit verblödest du
echt jeden neuling oder bereits fortgeschrittenen die von sowas noch
keine Ahnung haben.

Unterlass sowas einfach falsche Vermutungen ohne Beweise kannst
du für dich behalten wenn du dir nicht sicher bist!
02/10/2012 21:31 lakus124#6
Euer Wort in Gottes Namen, beweisen kann ich es EUCH nicht ich kann euch nur sagen, dass bei mir jede gamefile die vorher auf einem Windows dateisystem platz gefunden hat auf meinem root nicht läuft. Jedoch die gleiche game gepackt und dann hochgeladen läuft komischerweise . Bei mir hat noch keine aus epvp geladene game funktioniert. Bei mir funktionieren komischerweise nur Games die gepackt direkt von anderen Rootservern kommen. Übrigens finde ich nich schön wenn ihr posts bringt mit dem inhalt du hast doch keine ahnung ohne mir das gegenteil zu beweisen

Achso luckystrike : ich bin mir da ganz sicher ich soll dir das beweisen? beweis du mir das gegenteil zu meinem post und ich lass ihn closen
02/10/2012 23:12 Computerfreek#7
Wo sind denn bei dir die Beweise?
Hier hast du meine Begründung die du doch hoffentlich verstehst:

Das war du evtl. meinen könntest, ist die Import-Tabelle.
In ihr stehen - mal auf "einfach" gesagt - die Funktionen aus den Systemdateien (Libs in diesem Fall) welche im Core gebraucht werden.
Diese werden beim compilieren in den Core geschrieben.. Und da die Gamedatei anscheinend auf FreeBSD 7 (oder 6?) compiliert wurde, ist diese auch an das System gebunden - zumindest an die Libs (welche dann wieder untergeordnete Abhängigkeiten haben). Die IAT (Import Adress Table) lässt sich auch im nachhinein nur schwer ändern..
02/11/2012 01:55 Mashkin#8
@TE: Blödsinn! Falschinformation!

Es stimmt, dass die gamefile im Format ELF kompiliert wurde.
Und es stimmt auch, dass FreeBSD eines der wenigen Betriebssysteme mit ELF-Unterstützung ist.
Aber das Format der ausführbaren Datei ist beim Speichern und Übertragen völlig egal.
Soweit ich weiß wird die Symboltabelle bei ELF-Binaries direkt in der Datei gespeichert.

Das geschilderte Problem ist mir bis jetzt ausschließlich bei 64bit-Systemen vorgekommen.
Das liegt daran, dass auf 64bit-Systemen auch nur die mit 64bit-Datentypen kompilierten Bibliotheken vorliegen und diese nuneinmal teilweise inkompatibel zu 32bit-Datentypen (wie in der gamefile) sind.

Dieses Problem lässt sich aber simpel beheben, siehe dazu meinen Guide:
[Only registered and activated users can see links. Click Here To Register...]
02/11/2012 02:23 Computerfreek#9
Quote:
Originally Posted by M@shkin View Post
@TE: Blödsinn! Falschinformation!

Es stimmt, dass die gamefile im Format ELF kompiliert wurde.
Und es stimmt auch, dass FreeBSD eines der wenigen Betriebssysteme mit ELF-Unterstützung ist.
Aber das Format der ausführbaren Datei ist beim Speichern und Übertragen völlig egal.
Soweit ich weiß wird die Symboltabelle bei ELF-Binaries direkt in der Datei gespeichert.

Das geschilderte Problem ist mir bis jetzt ausschließlich bei 64bit-Systemen vorgekommen.
Das liegt daran, dass auf 64bit-Systemen auch nur die mit 64bit-Datentypen kompilierten Bibliotheken vorliegen und diese nuneinmal teilweise inkompatibel zu 32bit-Datentypen (wie in der gamefile) sind.

Dieses Problem lässt sich aber simpel beheben, siehe dazu meinen Guide:
[Only registered and activated users can see links. Click Here To Register...]
Eines der wenigen Betriebssysteme? Ganz *nix basiert auf ELF soweit ich mich erinnern kann. Das einzige wirkliche 'Problem' sollten die Libs sein die eben nicht den ursprünglichen Versionen gleichen.
Recompilen auf dem jeweiligen System sollte ausreichen - vorausgesetzt wir hätten den Source ;D
Btw die "Symboltabelle" aka Import Tabelle aka IAT wird immer (meine ich) direkt in der Binary gespeichert.
02/11/2012 02:48 Mashkin#10
Quote:
Originally Posted by Computerfreek View Post
Eines der wenigen Betriebssysteme? Ganz *nix basiert auf ELF soweit ich mich erinnern kann. Das einzige wirkliche 'Problem' sollten die Libs sein die eben nicht den ursprünglichen Versionen gleichen.
Recompilen auf dem jeweiligen System sollte ausreichen - vorausgesetzt wir hätten den Source ;D
Btw die "Symboltabelle" aka Import Tabelle aka IAT wird immer (meine ich) direkt in der Binary gespeichert.
Soweit ich weiß basieren überwiegende Teile diverser *nix-Systeme noch auf dem a.out-Format

Was die Symboltabelle angeht:
Ich meine zu wissen, dass Kernel Objects (Module, "kld") getrennte Symbol-Dateien besitzen.

Die Libs's für 32bit- und "Alt-"Software kann man leicht nachinstallieren bzw. per Symlinks verknüpfen.
Dass die gamefile überhaupt ein Problem mit den Lib-Versionen hat liegt ohnehin an der unsauberen Einbindung: Normalerweise lädt man Bibliotheken über die versionsunabhängigen Symlinks (z.B. "libc.so") anstatt über die itterierenden Versionen ("libc.so.5").