Forum Programmation.c++ compilation d'une librairie .so recalcitrante

Posté par  .
Étiquettes :
0
12
fév.
2008
bonsoir,


je travail sur une librairie depuis quelque mois, j'était sur une ubuntu 32 bit jusqu'il y a quelque jour où je suis passé sur une 64.
Depuis ce passage en 64 bit , je n'arrive plus à compiler cette lib, pourtant c'est exactement le même code...
j'ai voulu la compilé en 64bits avec l'option -m64 mais gcc m'as retourné cela : (j'utilise Eclipse)

**** Build of configuration Debug for project Lib ****

make -k all
Building target: libLib.so
Invoking: GCC C++ Linker
g++ -m64 -shared -o"libLib.so" ./Source/Lib.o -lGLEW -lglut
/usr/bin/ld: ./Source/Lib.o: relocation R_X86_64_32S against `x1a0' can not be used when making a shared object; recompile with -fPIC
./Source/Lib.o: could not read symbols: Bad value
collect2: ld a retourné 1 code d'état d'exécution
make: *** [libLib.so] Erreur 1
make: La cible « all » n'a pas pu être fabriquée à cause d'erreurs.
Build complete for project Lib

j'ai donc rajouté -fPIC mais ça n'a rien donné....

ensuite je me suis mis a la recompiler en 32 bits, donc cette fois ci avec l'option -m32 : j'ai eu une impossibilité de compiler (je posterai le message d'erreur demain , je n'ai pas la machine sous la main).
D'après moi c'est parceque les librairies libglew et libglut sont en 64bits et que j'essais de compiller la lib en 32.

j'ai penser installer libglew et libglut en version 32 bits mais je n'ai pas trouvé les paquet dans les dépôts...

Quelqu'un a t'il des pistes pour que je puisse compiler tout ça ??

  • # libtool

    Posté par  . Évalué à 3.

    Si tu veux compiler une librairie "proprement" (enfin, sans te prendre la tête), pourquoi n'utilises-tu pas libtool ?

    Sinon, pour ton info, une lib se compile toujours avec -fPIC. T'aurais le résultat "qui n'a rien donné" ?...

    • [^] # Re: libtool

      Posté par  . Évalué à 1.

      salut , merci de ta réponse ,

      j'ai donc installé libtool avec un apt-get install , mais comment s'en servir ??? (j'ai lu le man , mais ça ma pas trop aidé...)

      • [^] # Re: libtool

        Posté par  . Évalué à 1.

        j'ai apparemment réussie a compiler cette bibliothèque avec libtool en suivant ce document ftp://ftp.laas.fr/pub/ii/matthieu/make-trans.pdf

        donc je fais un sudo libtool --mode=link cc -rpath /usr/local/lib -o libLib.la Lib.lo && sudo libtool --mode=install install -c libLib.la /usr/local/lib/ && sudo libtool --mode=install install -c libLib.la /usr/local/lib/ && sudo ldconfig
        ce qui m'étonne c'est que je link pas (explicitement ) les librairies glut et glew... c'est normal ?? c'est libtool qui fais tout?, ou alors je m'y suis mal pris?

        • [^] # Re: libtool

          Posté par  . Évalué à 2.

          Je ne connais pas si bien que ca libtool, et je ne me suis jamais penché sur les problemes 32/64bits, donc je ne pourrais pas vraiment t'aider la dessus ...

          Mais généralement, oui libtool s'occupe de tout. C'est juste un "wrapper" autour des outils classiques, qui permet d'éviter de se prendre la tete. Donc oui, peut-etre qu'il fait tout tout seul. Enfin j'ai pas regardé en détail, mais faudrait peut-etre que tu rajoutes les -lglut -lglew lors du libtool --mode=link ? Ensuite, je ne pense pas que tu aies besoin de sudo en dehors du --mode=install.

          En tous cas je pense que google pourra mieux t'aider que moi maintenant que je t'ai filé la piste ...

          • [^] # Re: libtool

            Posté par  . Évalué à 2.

            merci beaucoup

            • [^] # Re: libtool

              Posté par  . Évalué à 2.

              De rien.

              D'ailleurs, si tu veux un peu plus d'explication sur l'option -fPIC (de mémoire) : PIC veut dire Position Independant Code, ce qui veut dire en gros que ta lib pourra etre "relocaté" (hou le sale anglicisme) n'importe où dans l'espace mémoire. Comme une lib est utilisée par plein de programmes différents ayant des "layout" de la mémoire assez différent, il faut générer du code dont les adresses puissent être modifiée, afin de placer cette lib à n'importe quel endroit dans la mémoire. D'où le "position independant" : on peut la bouger de place sans problème.
              Ce que ça change dans le code, c'est que certaines adresses ne seront maintenant plus codées "en dur", mais seront dynamiques. Forcément, tu perds un peu en perf, mais tu gagnes en flexibilité. Les programmes n'en ont pas besoin car eux, ils sont toujours au même endroit, et c'est aux libs de s'adapter.

              • [^] # Re: libtool

                Posté par  . Évalué à 1.

                bonjour ,
                merci pour ces précisions

                avec libtool tout se passe apparemment bien que ce soit pour compiler en 64 ou en 32.
                très bon outils , évite pas mal de prise de tête.

                est ce que les lib .a on aussi cette perte de perf?

                • [^] # Re: libtool

                  Posté par  . Évalué à 2.

                  Mhhh, les .a sont bien les libs a lier statiquement ?
                  Dans ce cas, non, puisque que toutes les adresses sont fixées lors du linkage (statique).
                  Enfin bon, "perte de perf", j'avoue que c'est une considération peut-etre trop importante de ma part, aujourd'hui tout est compilé en lib partagée et donc en PIC. Les pertes de perf sont minimes je pense, aux vues de l'avantage que tu gagnes en souplesse (par exemple ta lib ne sera pas dupliquée en mémoire si elle est utilisée par plusieurs programmes, ce qui n'est pas le cas si tu la lies statiquement).
                  En tous cas, je n'ai jamais vu la perte de perf comme un argument contre les libs partagées : c'est assumé par tout le monde comme étant négligeable (un peu comme quand tu parles de la MMU : plus personnes ne remet en cause les pertes de perfs du a la traduction des adresses de la MMU, tellement ca apporte en sécurité et en souplesse. Meme si des chercheurs de chez MS ont montré des gains de 20% dans certains cas quand tout l'OS tourne en ring 0, en faisant leurs recherches sur l'OS du futur (je n'ai plus le nom en tete)).

                  • [^] # Re: libtool

                    Posté par  . Évalué à 1.

                    bonjour,
                    j'ai l'impression que le fait que ce soit compilé en librairie cause une grosse perte de perf , je m'explique : lorsque je compile mon code en exécutable j'ai des performance deux fois plus rapide que si je compile une librairie et que je crée un exécutable appelant celle ci,
                    comment pourrais-je améliorer les perf de la librairie?

                    • [^] # Re: libtool

                      Posté par  . Évalué à 2.

                      Tu aurais des chiffres concrets ?
                      Généralement, avec une lib partagée, tu perds pas mal de temps au démarrage de l'application, lors du linkage dynamique. Mais apres ca, les perfs deviennent a peu pres équivalentes. Une différence du simple au double n'est pas normale.

  • # ./Source/Lib.o

    Posté par  . Évalué à 2.

    Il faut qu'il soit compilé en 64 bits...

    On ne peu pas mélanger des objets 32 et 64.

    • [^] # Re: ./Source/Lib.o

      Posté par  . Évalué à 1.

      Bonjour , merci de vos réponses.

      Donc quand je compille en 32bit, eclipse me fait:Building target: libLib.so
      Invoking: GCC C++ Linker
      g++ -m32 -shared -o"libLib.so" ./Source/Lib.o -lGLEW -lglut
      /usr/bin/ld: skipping incompatible /usr/bin/../lib/libGLEW.so when searching for -lGLEW
      /usr/bin/ld: skipping incompatible /usr/bin/../lib/libGLEW.a when searching for -lGLEW
      /usr/bin/ld: skipping incompatible /usr/lib/libGLEW.so when searching for -lGLEW
      /usr/bin/ld: skipping incompatible /usr/lib/libGLEW.a when searching for -lGLEW
      /usr/bin/ld: cannot find -lGLEW
      collect2: ld a retourné 1 code d'état d'exécution
      make: *** [libLib.so] Erreur 1
      make: La cible « all » n'a pas pu être refabriquée à cause d'erreurs.
      Build complete for project Lib

      quand je compille en 64bit , j'ai :
      **** Build of configuration Debug for project Lib ****

      make -k all
      Building target: libLib.so
      Invoking: GCC C++ Linker
      g++ -m64 -shared -o"libLib.so" ./Source/Lib.o -lGLEW -lglut
      /usr/bin/ld: ./Source/Lib.o: relocation R_X86_64_32S against `x1a0' can not be used when making a shared object; recompile with -fPIC
      ./Source/Lib.o: could not read symbols: Bad value
      collect2: ld a retourné 1 code d'état d'exécution
      make: *** [libLib.so] Erreur 1
      make: La cible « all » n'a pas pu être refabriquée à cause d'erreurs.
      Build complete for project Lib

      donc je rajoute l'option -fPIC : **** Build of configuration Debug for project Lib ****

      make -k all
      Building target: libLib.so
      Invoking: GCC C++ Linker
      g++ -m64 -fPIC -shared -o"libLib.so" ./Source/Lib.o -lGLEW -lglut
      /usr/bin/ld: ./Source/Lib.o: relocation R_X86_64_32S against `x1a0' can not be used when making a shared object; recompile with -fPIC
      ./Source/Lib.o: could not read symbols: Bad value
      collect2: ld a retourné 1 code d'état d'exécution
      make: *** [libLib.so] Erreur 1
      make: La cible « all » n'a pas pu être refabriquée à cause d'erreurs.
      Build complete for project Lib

      peut être ça peut aidé , les includes de mon code :
      #include <stdio.h>
      #include <libio.h>
      #include <stdlib.h>
      #include <string.h>
      #include <math.h>


      #include <time.h>
      #include <sys/timeb.h>

      #include <GL/glew.h>
      #include <GL/glut.h>
      #include <GL/glx.h>

      #ifdef ACML
      #include </opt/acml4.0.1/gfortran64_mp_int64/include/acml.h>
      //#include </opt/acml3.6.1/gfortran64_mp/include/acml.h> //3.6 en 64 multiproc
      #endif



      #include <sys/types.h>
      #include <sys/stat.h>
      #include <unistd.h>

      je ne défini pas ACML

      • [^] # incompatibilité 32/64

        Posté par  . Évalué à 3.

        pour les erreurs avec la compilation en 32 bits, c'est bien un probleme d'incompatibilité :

        /usr/bin/ld: skipping incompatible /usr/bin/../lib/libGLEW.so when searching for -lGLEW

        En gros, tu libGLEW.so est en 64 bits, donc ld ne peut pas l'utiliser pour linker sur du code 32 bits.

        Sinon, question bete, tu fais un make clean entre tes essais ? Pour ne pas te retrouver avec certains .o en 32 bits, d'autres en 64 ...

        • [^] # Re: incompatibilité 32/64

          Posté par  . Évalué à 1.

          merci de cette reponse rapide .
          effectivement je clean bien tout le projet à chaque fois que je recompile.

          Comment installer sur ma 64bits ces librairie 32bits pour que je puisse compiller la mienne??

          • [^] # Re: incompatibilité 32/64

            Posté par  . Évalué à 2.

            Désolé, je ne connais pas assez bien ta distribution pour répondre si, comme tu l'as écrit, tu n'as pas trouvé de paquets. En revanche, il reste toujours possible de les compiler toi meme à partir des sources (probablement disponibles sur le web), en utilisant -m32

            • [^] # Re: incompatibilité 32/64

              Posté par  . Évalué à 2.

              Le -fPIC que tu as rajouté, tu l'as mis au link, il faudrait le mettre à la compilation, je pense que cela viens de là. (et vire le -m64, vu que cela n'a pas aidé, il est normalement automatique et sera source de problèmes plus tard quand tu compilera en 32... e que tu te rendra compte que tu as oublié de l'enlever)

              • [^] # Re: incompatibilité 32/64

                Posté par  . Évalué à 2.

                merci , effectivement c'est ballot....
                une fois l'option -fPIC dans à la compilation , ça se compile

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.