errata: Déjà, lors de la compilation, gcc vérifie que le symbolique existe dans le .so (ou alors je me trompe).
oui : a la compilation, GCC ne verifie que le prototype des dites fonctions dans les headers divers ... tandis que le linker ira lui verifier la definition de la fonction dans le LD_LIBRARY_PATH ou les -Lmypath
note qu il est possible de linker contre ./tata.so, tandis que l execution prendra tata.so ailleurs ... c est ce qui permet d avoir dans un gros projet le linkage des applicatifs des que les librairies sont compilees, et de faire les installs des applis+libs PLUS TARD.
Dans mon cas, cela engendre parfois des problemes de versioning, quand la version ./ et la version /usr different, mais ordinairement, ce probleme ne devrait pas arriver.
Ceci parce que ld cherche dans les '-L', tandis que le linker de Linux cherche les chemins dans /etc/ld.so.conf (de memoire).
Bref, je trouve ca assez drole de dev une appli qui a a la fois des applicatifs et des libs.
[^] # Re: Euh ... moi je ne vois que des avantages :-)
Posté par doublehp . En réponse au journal Fonctionnement du linker dynamic sous linux. Évalué à 0.
oui : a la compilation, GCC ne verifie que le prototype des dites fonctions dans les headers divers ... tandis que le linker ira lui verifier la definition de la fonction dans le LD_LIBRARY_PATH ou les -Lmypath
note qu il est possible de linker contre ./tata.so, tandis que l execution prendra tata.so ailleurs ... c est ce qui permet d avoir dans un gros projet le linkage des applicatifs des que les librairies sont compilees, et de faire les installs des applis+libs PLUS TARD.
Dans mon cas, cela engendre parfois des problemes de versioning, quand la version ./ et la version /usr different, mais ordinairement, ce probleme ne devrait pas arriver.
Ceci parce que ld cherche dans les '-L', tandis que le linker de Linux cherche les chemins dans /etc/ld.so.conf (de memoire).
Bref, je trouve ca assez drole de dev une appli qui a a la fois des applicatifs et des libs.