4. Shared Libraries mit gelinkter Static Librarie compilieren??

Shared Libraries mit gelinkter Static Librarie compilieren??

  • N

    Hi,

    ich bin auf einer x86_64bit Architektur
    und will folgendes machen:

    gcc -fPIC -m64 -c foo.c bar.c

gcc -shared -m64 foo.o bar.o static.a -o shared.so

    (gcc version 4.1.1)

    bekomme dann einen Fehler der Art:

    static.a  (...) can not be used when making 
a shared object; recompile with -fPIC

    nun kann ich static.a nicht "recompilen" da ich den code nicht hab.
    Brauche aber die shared.so als .so

    kann man da irgendwas machen???

    ps: auf der 32bit Maschine hat das irgendwie geklappt aber da hat der auch vorher nicht so auf die -fPIC Flags bestanden 🙂

    0
  • J

    Eine schlechte und eine gute Nachricht:

    Erst einmal die schlechte Nachricht:
    Man kann unter Linux nicht mit statischen und dynamischen Libraries zusammen linken. Das ist unabhängig, ob 32 oder 64 Bit.

    Jetzt die gute Nachricht: Es gibt eine Lösung.

    Ich hatte das gleiche Problem (Linux RedHat 8.0, Fedora FC3) im Zusammenhang mit Java-Code, JNI und eigenen statischen Libraries und habe es dort einfach folgendermaßen gelöst (geschickterweise automatisch über einen Makefile):

    Alle benötigten Objekt-Module mit "ld -x" aus der statischen Library extrahieren und damit über "ld -o -shared" eine neue dynamische Library anlegen. Damit funktionierst es unter diversen Unix/Linux-Varianten.

    Reicht das als Grundidee? Sonst helfe ich gerne weiter...

    0
  • N

    Hi danke für den Tipp

    Mit "ld -x ***.a" weiß ich nicht wie ich die static libary entpacken soll aber mit "ar -x ***.a" geht es.
    Leider bringt mich das auch nicht viel weiter da wenn ich nun die .o Dateien neu linken will (mit "ld -shared *.[io] -o ***.so") ich einen ähnlichen Fehler bekomme.

    ld: ***.o: relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
    0
  • J

    nichtweise schrieb:

    Mit "ld -x ***.a" weiß ich nicht wie ich die static libary entpacken soll aber mit "ar -x ***.a" geht es.

    ... sorry, mein Fehler. Es muss natürlich "ar -x" heißen.

    Und Du bist offenbar nicht allein. Deine Fehlermeldung ist mir zwar unbekannt, aber mit Google bekommt man diverse Hinweise, z.B.:
    http://www.gentoo.org/proj/en/base/amd64/howtos/index.xml?part=1&chap=3

    Da hier etliche Leute ähnliche Probleme hatten, solltest Du auf diesen Weg hoffentlich weiterkommen.

    0
  • J

    ... so ich habe selbst mal ein wenig im Internet recherchiert, weil mich das Problem interessiert.

    Die angesprochene Ausgangs-Problematik hat weniger etwas mit shared libraries zu tun, sondern mit der Option -fPIC (für Position Independent Code)

    Offenbar hast Du ein AMD64 System, hier wird bei shared libraries die Option -fPIC beim Compile-Lauf zwingend benötigt. Da Du aber den Quell-Code nicht hast, kannst Du keinen neuen Compile durchführen. Daraus folgt, dass Du keine shared library bilden kannst.

    Es sieht wohl so aus, als ob Du (ausschließlich) mit "normalen" statischen Libraries arbeiten musst.

    0
  • N

    jox schrieb:

    Es sieht wohl so aus, als ob Du (ausschließlich) mit "normalen" statischen Libraries arbeiten musst.

    Jo so sieht es aus 😞

    Mal sehen was ich nun mache. Brauche eigentlich ne Shared Library um sie in Maple einzubinden.

    Aber vielen vielen Dank für deine Bemühungen.

    Gruß nichtweise

    0
  • J

    Hallo nichtweise,

    meinst Du maple für mathematische Funktionen?

    Wer verursacht den Fehler?

    ld: ***.o: relocation R_X86_64_32 against `a local symbol' can not be used ...

    Bei der kompletten Fehlermeldung (i.d.R. Zeile danach) wird noch angegeben, welches Modul oder welche Library Probleme macht. Es wäre gut, wenn Du mal die komplette Fehlermeldung posten würdest. Wenn man herausbekommt, dass es an der maple-Library liegt, kann man dort bei den Entwicklern mal nachfragen.

    Gibt es für maple tatsächlich eine Library mit 64 Bit Unterstützung (die von Dir auch benutzt wird)? Ich kenne das von anderen Maschinen, wo es z.B. für externe Libraries welche für 32 Bit und 64 Bit gibt. Übrigens, die 32 Bit Version muss nicht zwingend entscheidend langsamer sein, siehe
    http://www.mapleprimes.com/blog/dave-l/maple-10-and-64bit-linux-part-1

    Überlegen wir mal, was es noch für Alternativen gibt:

    - Dein Program mit 32-Bit Option übersetzen bzw. binden (Du hattest ja gesagt, früher hat es mit 32 Bit funktioniert).

    - Falls es an maple liegt, alle maple-Module in eine statische Library packen, mittels: "ar -x ... und "ld -o *.a ..." (falls das überhaupt unktioniert)

    - Eine neue Schnittstelle zu maple, z.B. über ein eigenständiges Programm (rpc-Call, eigener Server, popen()-Aufruf). Ist natürlich langsamer und komplexer.

    P.S.: Ich schätze mal, Du hast jetzt 'nen neuen Rechner mit 64 Bit und wolltest mal "auf die Schnelle" Deine alten Programme neu zusammenbauen ... 😉

    0
  • N

    jox schrieb:

    meinst Du maple für mathematische Funktionen?

    Ja ich denke wir meinen beide das Gleiche

    jox schrieb:

    Wer verursacht den Fehler?

    ld: ***.o: relocation R_X86_64_32 against `a local symbol' can not be used ...

    Bei der kompletten Fehlermeldung (i.d.R. Zeile danach) wird noch angegeben, welches Modul oder welche Library Probleme macht. Es wäre gut, wenn Du mal die komplette Fehlermeldung posten würdest. Wenn man herausbekommt, dass es an der maple-Library liegt, kann man dort bei den Entwicklern mal nachfragen.

    Der Fehler hat nichts mit Maple zu tun.

    mit:

    nichtweise schrieb:

    Brauche eigentlich ne Shared Library um sie in Maple einzubinden.

    wollte ich nur sagen das dies:

    jox schrieb:

    Es sieht wohl so aus, als ob Du (ausschließlich) mit "normalen" statischen Libraries arbeiten musst

    keine Lösung für mich darstellt.

    Ich kann mal im groben umreißen was das alles soll:

    In Maple gibt es die Möglichkeit über den Befehl "define_external" auf Funktionen in einer DLL Datei(unter Windows) oder einer Shared Library(unter UNIX) zuzugreifen. Jenes wollte ich nun machen und dazu eine Shard Library erzeugen welche auf Funktionalität einer statischen (3-Party) Bibliothek zurückgreift. Die (3-Party) Bibliothek ist nicht von Maplesoft oder so, wieß gar nicht so genau von wem die ist.

    Naja wo wir somit beim altbekannten Problem wären.

    Habe nun erstmal alles ausgebaut was auf diese (3-Party) Bibliothek zurückgreifen wollte, und kann mich anderen Problemen zuwenden.
    (Werde warscheinlich auch wieder auf 32bit wechseln)

    Danke nochmal

    Gruß nichtweise

    0
Anmelden zum Antworten