gcc linker et symboles non necessaires.

gcc linker et symboles non necessaires. - C++ - Programmation

Marsh Posté le 02-07-2009 à 14:00:34    

Ayant des problemes de linkage ces jours ci, je m amuse a faire des exemples minimaux pour comprendre un peu mieux ce qui se passe. Mon reel probleme est que je cherche a compiler un .so qui linke une archive .a tierce, et que je cherche a comprendre pourquoi je suis oblige d utiliser a la compil du .so -Wl,--whole-archive  XXX.a  -Wl,--no-whole-archive pour que les symboles de XXX.a soient definis dans le .so.
 
J ai cru comprendre que whole-archive copiait complement l archive .a dans le .so ainsi que les symboles, ce qui implique que le comportement par defaut de g++ est de ne linker que ce dont il a besoin. Or sur un exemple minimal j ai trouve le contraire.
Ma question est la suivante : Dans l exemple suivant comment forcer gcc a n exporter que les symboles definis dans b.cpp avec leurs eventuelles dependances dans a.cpp mais pas les autres symboles de a.cpp (ici a2.cpp que j aurai voulu ne pas avoir dans libb.so) ?
 
En gros je voudrais modifier le makefile suivant pour que source.cpp gueule et me file un undef sur a2()
 
 
Merci.
 
 

EDIT :
En creant un fichier a2.cpp qui contient a2(), la fonction n est plus copiee et on obtient bien un undefined sur a2() au linkage de source.cpp
Donc j en deduis que le linker procede par .o et non pas par symbole pour savoir qui copier.


 
 
a.cpp

Code :
  1. #include <iostream>
  2. void a(){
  3. std::cout<<"hello world"<<std::endl;
  4. }
  5. void a2(){
  6. std::cout<<"hello world2"<<std::endl;
  7. }


 
b.cpp

Code :
  1. void a();
  2. void b() {
  3. a();
  4. }


 
source.cpp

Code :
  1. void a2();
  2. void b();
  3. int main(int argc, char**argv)
  4. {
  5. a2();
  6. b();
  7. return 0;
  8. }


 
 
Makefile  

Code :
  1. all : a b c
  2. a :
  3. g++ -c -fPIC -o liba.a a.cpp -I.
  4. b :
  5. g++ -shared -fPIC -o libb.so  b.cpp liba.a -I.
  6. c :
  7. g++ -o app  source.cpp libb.so -I.


Message édité par chewif le 02-07-2009 à 14:24:56
Reply

Marsh Posté le 02-07-2009 à 14:00:34   

Reply

Marsh Posté le 02-07-2009 à 14:30:46    

La granularite est normalement le fichier (donc si tu as un symbole d'un fichier, tu les as tous).  Mais gcc a une option pour avoir une granularite plus fine (-ffunction-section ou qqch de proche).


---------------
The truth is rarely pure and never simple (Oscar Wilde)
Reply

Marsh Posté le 02-07-2009 à 14:39:40    

k merci.
En plus je pense avoir trouve la raison de mon probleme avec whole-archive.
 
quand je fais nm sur un des symboles de  XXX.a je trouve


                 U taucs_ccs_free
00000000000000f0 T taucs_ccs_free
                 U taucs_ccs_free
                 U taucs_ccs_free
                 U taucs_ccs_free
                 U taucs_ccs_free
                 U taucs_ccs_free
                 U taucs_ccs_free
                 U taucs_ccs_free
                 U taucs_ccs_free
                 U taucs_ccs_free
                 U taucs_ccs_free
                 U taucs_ccs_free
                 U taucs_ccs_free


 
 
J en deduis qu il y a dans l archive un tas de .o pour lesquels le symbole n est pas resolu.
Du coup quand mon .so tente de linker le symbole dans  XXX.a il tombe sur le undef d un des .o (surement le premier liste par nm) au lieu du code.
D ou la necessite d utiliser whole-archive pour qu il trouve ses petits.
 
J ai finalement decide de compiler XXX.a dans XXX.so puis de linker dynamiquement  histoire de voir si ca resout les choses..  

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed