Discussion :

[Alain B.]

Bonjour,

D'abord je pose le décors :
HPUX11
Oracle 9.2.0.3 et 9.2.0.6.
OS et Oracle gérés par mon client.

J'ai une application 'C/ProC' compilée il ya quelque temps et qui tourne bien.
Pour les besoins d'une modification soft je recompile, sans avoir modifié quoi que ce soit, ni sources, ni makefiles, ni environnement.
Et à l'execution paf :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/usr/lib/pa20_64/dld.sl: Unable to find library 'libwtc9.sl'.

Aprés un moment de solitude, je trouve la solution : définir la variable LD_LIBRARY_PATH et la faire pointer sur le repertoire des lib oracle qui contient 'libwtc9.sl'.

La ou je m'interroge : Comment on en est arrivé la ?
J'ai l'hypothese suivante :

Au depart mes executables etaient (et sont toujours ) compilés/linkés en 'statique', incluant à l'époque les librairies Oracle 9.2.0.3 en statique elles aussi.

Arrive mon client qui migre en 9.2.0.6 et la je suppose que les lib oracle ne sont plus statiques mais dynamiques.

Mes executables, pas recompilés, continuent à tourner avec leur lib 9.2.0.3 incorporées à la compile précedente.

Maintenant si je compile j'inclus les nouvelles lib 9.2.0.6 qui sont dynamiques, et sans le LD_LIBRARY_PATH paf la lib


Est ce que mon raisonnement se tient ?
Avez vous d'autes explications ?

[LeoAnderson]

Pour savoir si ton raisonnnement tient la route (ce dont je doute fortement vu que tu restes dans la même release, seul le niveau d'upgrade changeant), il te suffit de faire un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

$ file {NOM_DU_PROGRAMME}

si la réponse contient ou non "dynamically linked", tu seras fixé.

Pour connaitre les librairies utilisées, la commande ldd est faite pour ça.

Je suis plus persuadé que le .profile positionnait le LD_LIBRARY_PATH et qu'il a été modifié (peut-être que le .profile utilisateur n'a pas été modifié mais celui de /etc si ! )

[Alain B.]

Je suis plus persuadé que le .profile positionnait le LD_LIBRARY_PATH et qu'il a été modifié (peut-être que le .profile utilisateur n'a pas été modifié mais celui de /etc si ! )

J'ai vérifié sur d'autres sites du même type, même soft même client etc, et cela tourne SANS LD_LIBRARY_PATH.

Quels changements, liés à cette migartion mineur, peut necessiter la définition de cette variable ?

[orafrance]

LIBPATH ou CLASSPATH peut-être

[orafrance]

Ha bah non... Metalink est notre ami :

Precompilers - Version: 9.2.0.6.0
This problem can occur on any platform.
Symptoms

Upon setting up a new box with a cobol compiler, users now receive the following error
when using Pro*COBOL:

/usr/lib/pa20_64/dld.sl Unable to find library 'libcobrts64.sl'

Cause
Permissions on <full path>/mfcobol are too restrictive. When permissions are too restrictive
the libcobrts64.sl library cannot be found.
Solution

To implement the solution, issue the following commands:

$ su - root
# cd [location where cobol is at]
# chmod -R 755 mfcobol

[LeoAnderson]

J'ai une application 'C/ProC' compilée il ya quelque temps et qui tourne bien.

donc ta note sur le cobol....

et que donnent les commandes file et ldd ?

[Alain B.]

Je pense avoir trouvé :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
chatr opt/oracle/product/9.2.0.6/lib//libclntsh.sl.9.0:
opt/oracle/product/9.2.0.6/lib//libclntsh.sl.9.0:
         64-bit ELF shared library
         shared library dynamic path search:
             LD_LIBRARY_PATH    enabled  first
             SHLIB_PATH         enabled  second
             embedded path      enabled  third  /b/s425/lib
...
...

Sur n'importe quel autre site ca donne plustot :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
chatr opt/oracle/product/9.2.0.6/lib//libclntsh.sl.9.0:
opt/oracle/product/9.2.0.6/lib//libclntsh.sl.9.0:
         64-bit ELF shared library
         shared library dynamic path search:
             LD_LIBRARY_PATH    enabled  first
             SHLIB_PATH         enabled  second
             embedded path      enabled  third  /opt/oracle/product/9.2.0.6/lib
...
...

J'en conclu que le gars qui a installé les binaires s'est un peu fourvoyé et a du oublié la phase relink..
Et comme l'appli n'a pas ete recompilée apres le patch, elle utilise toujours les libs opt/oracle/product/9.2.0.2/lib qui sont correctement configurées.