J'ai un problème avec un soft unix scientifique (basé sur IDL) et qui
utilise pour certaines entrées/sorties des "Shared Objects", des .so qui
n'existent pas dans OS X justement (bien expliqué dans les notes
developer). J'ai le source en c de ce programme et gcc 3.1 (avec la
bonne option qui va bien -no-cpp-precomp pour les compilations
difficiles - j'ai donné avec MatLab 6.5 et les MEX files) et ma question
est, une fois compilé, par quoi et comment remplace-t-on ces ".so"
"Shared objects" ??? Une lib normale ".a" va-t-elle bien ou faut-il des
"exoticités" type dylib, etc. (auxquelles je ne comprends rien...) ???
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Paul GABORIT
À (at) Tue, 12 Aug 2003 12:59:35 +0200, ldame écrivait (wrote):
J'ai un problème avec un soft unix scientifique (basé sur IDL) et qui utilise pour certaines entrées/sorties des "Shared Objects", des .so qui n'existent pas dans OS X justement (bien expliqué dans les notes developer). J'ai le source en c de ce programme et gcc 3.1 (avec la bonne option qui va bien -no-cpp-precomp pour les compilations difficiles - j'ai donné avec MatLab 6.5 et les MEX files) et ma question est, une fois compilé, par quoi et comment remplace-t-on ces ".so" "Shared objects" ??? Une lib normale ".a" va-t-elle bien ou faut-il des "exoticités" type dylib, etc. (auxquelles je ne comprends rien...) ???
Cela dépend de la manière dont le programme utilise ces "Shared objects".
Si ce sont de simples bibliothèques dynamiques, c'est au moment de l'édition des liens (le 'link') que ça doit poser problème car il cherche des bibliothèques dont l'extensions est '.dylib' (pour "Dynamic Library"). Il faut donc modifier les makefile pour produire les bonnes extensions. Il se peut aussi que la fabrication de ces bibliothèques dynamiques soit piloté par 'libtool'. Dans ce cas, il y a peut-être pour chacune un fichier '.la' contenant le nom de l'extension à utiliser ou des 'flags' à modifier dans le makefile pour la génération des fichier '.la'.
Si ce sont des modules chargés lors de l'exécution (pas au lancement mais au besoin - comme des plugins), c'est un autre problème. Il faut déjà savoir par quel mécanisme le programme veut se lier dynamiquement à ces modules (dlopen par exemple) et comment il fait pour trouver ceux qui sont disponibles. Là, il faudrait en savoir un peu plus pour répondre.
Pourquoi ne pas donner le nom de programme ? Il est peut-être déjà porté sur MacOS X.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Remove '.OOO' from e-mail address - Supprimez '.OOO' de l'adresse e-mail
À (at) Tue, 12 Aug 2003 12:59:35 +0200,
ldame <luc.dame@aerov.jussieu.fr> écrivait (wrote):
J'ai un problème avec un soft unix scientifique (basé sur IDL) et qui
utilise pour certaines entrées/sorties des "Shared Objects", des .so qui
n'existent pas dans OS X justement (bien expliqué dans les notes
developer). J'ai le source en c de ce programme et gcc 3.1 (avec la
bonne option qui va bien -no-cpp-precomp pour les compilations
difficiles - j'ai donné avec MatLab 6.5 et les MEX files) et ma question
est, une fois compilé, par quoi et comment remplace-t-on ces ".so"
"Shared objects" ??? Une lib normale ".a" va-t-elle bien ou faut-il des
"exoticités" type dylib, etc. (auxquelles je ne comprends rien...) ???
Cela dépend de la manière dont le programme utilise ces "Shared objects".
Si ce sont de simples bibliothèques dynamiques, c'est au moment de l'édition
des liens (le 'link') que ça doit poser problème car il cherche des
bibliothèques dont l'extensions est '.dylib' (pour "Dynamic Library"). Il faut
donc modifier les makefile pour produire les bonnes extensions. Il se peut
aussi que la fabrication de ces bibliothèques dynamiques soit piloté par
'libtool'. Dans ce cas, il y a peut-être pour chacune un fichier '.la'
contenant le nom de l'extension à utiliser ou des 'flags' à modifier dans le
makefile pour la génération des fichier '.la'.
Si ce sont des modules chargés lors de l'exécution (pas au lancement mais au
besoin - comme des plugins), c'est un autre problème. Il faut déjà savoir par
quel mécanisme le programme veut se lier dynamiquement à ces modules (dlopen
par exemple) et comment il fait pour trouver ceux qui sont disponibles. Là, il
faudrait en savoir un peu plus pour répondre.
Pourquoi ne pas donner le nom de programme ? Il est peut-être déjà porté sur
MacOS X.
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Remove '.OOO' from e-mail address - Supprimez '.OOO' de l'adresse e-mail
À (at) Tue, 12 Aug 2003 12:59:35 +0200, ldame écrivait (wrote):
J'ai un problème avec un soft unix scientifique (basé sur IDL) et qui utilise pour certaines entrées/sorties des "Shared Objects", des .so qui n'existent pas dans OS X justement (bien expliqué dans les notes developer). J'ai le source en c de ce programme et gcc 3.1 (avec la bonne option qui va bien -no-cpp-precomp pour les compilations difficiles - j'ai donné avec MatLab 6.5 et les MEX files) et ma question est, une fois compilé, par quoi et comment remplace-t-on ces ".so" "Shared objects" ??? Une lib normale ".a" va-t-elle bien ou faut-il des "exoticités" type dylib, etc. (auxquelles je ne comprends rien...) ???
Cela dépend de la manière dont le programme utilise ces "Shared objects".
Si ce sont de simples bibliothèques dynamiques, c'est au moment de l'édition des liens (le 'link') que ça doit poser problème car il cherche des bibliothèques dont l'extensions est '.dylib' (pour "Dynamic Library"). Il faut donc modifier les makefile pour produire les bonnes extensions. Il se peut aussi que la fabrication de ces bibliothèques dynamiques soit piloté par 'libtool'. Dans ce cas, il y a peut-être pour chacune un fichier '.la' contenant le nom de l'extension à utiliser ou des 'flags' à modifier dans le makefile pour la génération des fichier '.la'.
Si ce sont des modules chargés lors de l'exécution (pas au lancement mais au besoin - comme des plugins), c'est un autre problème. Il faut déjà savoir par quel mécanisme le programme veut se lier dynamiquement à ces modules (dlopen par exemple) et comment il fait pour trouver ceux qui sont disponibles. Là, il faudrait en savoir un peu plus pour répondre.
Pourquoi ne pas donner le nom de programme ? Il est peut-être déjà porté sur MacOS X.
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Remove '.OOO' from e-mail address - Supprimez '.OOO' de l'adresse e-mail
ldame
À (at) Tue, 12 Aug 2003 12:59:35 +0200, ldame écrivait (wrote):
J'ai un problème avec un soft unix scientifique (basé sur IDL) et qui utilise pour certaines entrées/sorties des "Shared Objects", des .so qui n'existent pas dans OS X justement (bien expliqué dans les notes developer). J'ai le source en c de ce programme et gcc 3.1 (avec la bonne option qui va bien -no-cpp-precomp pour les compilations difficiles - j'ai donné avec MatLab 6.5 et les MEX files) et ma question est, une fois compilé, par quoi et comment remplace-t-on ces ".so" "Shared objects" ??? Une lib normale ".a" va-t-elle bien ou faut-il des "exoticités" type dylib, etc. (auxquelles je ne comprends rien...) ???
Cela dépend de la manière dont le programme utilise ces "Shared objects".
Si ce sont de simples bibliothèques dynamiques, c'est au moment de l'édition des liens (le 'link') que ça doit poser problème car il cherche des bibliothèques dont l'extensions est '.dylib' (pour "Dynamic Library"). Il faut donc modifier les makefile pour produire les bonnes extensions. Il se peut aussi que la fabrication de ces bibliothèques dynamiques soit piloté par 'libtool'. Dans ce cas, il y a peut-être pour chacune un fichier '.la' contenant le nom de l'extension à utiliser ou des 'flags' à modifier dans le makefile pour la génération des fichier '.la'.
Justement c'est ce que je ne comprends pas même en lisant le makefile (ce dernier envisage plusieurs type de machines - SunOS, IRIX, OSF 1, etc.). Il crée des ld_flags (pour SunOS par exemple). Je copie ci-après le début du makefile qui va avec le source pour ce qui concerne SunOS :
# Platform independant makefile for the IDL Call_External() examples. # SHELL=/bin/sh CFLAGS FFLAGS SHL_LIBS= trace_decode_idl.$(SHL_EXT)
# The following is the default entry point. This section will determine # what system we are on, set the correct flags and call this same makefile # again with the correct flags.
all : @echo "OS type detected: "`uname` @case `uname` in "SunOS") if [ -d /proc ]; then make libs "SHL_EXT=so" "CCÌ" "F77÷7" "C_LDÌ" "F_LD÷7" "CFLAGS=-K pic -DSPARC -G" "C_LD_FLAGS=-G -DSOLARIS" "FFLAGS=-pic -G" "FOBJS=ftn_only_sun.o ftn_strarr_sun.o" "F_LD_FLAGS=-G" "F_LD_POST= -lF77 -lm -lc"; else make libs "SHL_EXT=so" "CC¬c" "F77÷7" "C_LD=ld" "F_LD=ld" "CFLAGS=-pic -DSPARC -fsingle" "C_LD_FLAGS=-assert pure-text" "F_LD_FLAGS=-assert pure-text" "FFLAGS=-pic" "FOBJS=ftn_only_sun.o ftn_strarr_sun.o" "F_LD_POST= -L/usr/lang/SC3.0.1/lib -lF77 "; fi ;;
Si ce sont des modules chargés lors de l'exécution (pas au lancement mais au besoin - comme des plugins), c'est un autre problème. Il faut déjà savoir par quel mécanisme le programme veut se lier dynamiquement à ces modules (dlopen par exemple) et comment il fait pour trouver ceux qui sont disponibles. Là, il faudrait en savoir un peu plus pour répondre.
Je vais regarder le programme qui fait appel au .so pour voir comment il est appelé. Si tu veux le source du programme (trace_decode_idl.c) je peux te le faire parvenir par mail. Merci de aide (j'y vois déjà un peu plus clair... dans le brouillard quand-même !).
Pourquoi ne pas donner le nom de programme ? Il est peut-être déjà porté sur MacOS X.
Il s'agit d'un ensemble de programmes IDL, SolarSoft, créés par l'Equipe de Physique Solaire de Lookheed pour l'exploitation des missions spatiales solaires NASA/ESA (SXT/Yohkoh, SOHO, TRACE). Une installation existe pour beaucoup de systèmes d'exploitation mais pas OS X encore... Je souhaite l'utiliser sur Mac OS X plutôt que sur Sparc (pour changer) mais la décompression des images du satellite (trace_decode_idl.so) ne peut fonctionner vu la logique EFL du package...
À (at) Tue, 12 Aug 2003 12:59:35 +0200,
ldame <luc.dame@aerov.jussieu.fr> écrivait (wrote):
J'ai un problème avec un soft unix scientifique (basé sur IDL) et qui
utilise pour certaines entrées/sorties des "Shared Objects", des .so qui
n'existent pas dans OS X justement (bien expliqué dans les notes
developer). J'ai le source en c de ce programme et gcc 3.1 (avec la
bonne option qui va bien -no-cpp-precomp pour les compilations
difficiles - j'ai donné avec MatLab 6.5 et les MEX files) et ma question
est, une fois compilé, par quoi et comment remplace-t-on ces ".so"
"Shared objects" ??? Une lib normale ".a" va-t-elle bien ou faut-il des
"exoticités" type dylib, etc. (auxquelles je ne comprends rien...) ???
Cela dépend de la manière dont le programme utilise ces "Shared objects".
Si ce sont de simples bibliothèques dynamiques, c'est au moment de l'édition
des liens (le 'link') que ça doit poser problème car il cherche des
bibliothèques dont l'extensions est '.dylib' (pour "Dynamic Library"). Il faut
donc modifier les makefile pour produire les bonnes extensions. Il se peut
aussi que la fabrication de ces bibliothèques dynamiques soit piloté par
'libtool'. Dans ce cas, il y a peut-être pour chacune un fichier '.la'
contenant le nom de l'extension à utiliser ou des 'flags' à modifier dans le
makefile pour la génération des fichier '.la'.
Justement c'est ce que je ne comprends pas même en lisant le makefile
(ce dernier envisage plusieurs type de machines - SunOS, IRIX, OSF 1,
etc.). Il crée des ld_flags (pour SunOS par exemple). Je copie ci-après
le début du makefile qui va avec le source pour ce qui concerne SunOS :
# Platform independant makefile for the IDL Call_External() examples.
#
SHELL=/bin/sh
CFLAGS FFLAGS
SHL_LIBS= trace_decode_idl.$(SHL_EXT)
# The following is the default entry point. This section will determine
# what system we are on, set the correct flags and call this same makefile
# again with the correct flags.
all :
@echo "OS type detected: "`uname`
@case `uname` in
"SunOS") if [ -d /proc ]; then
make libs
"SHL_EXT=so"
"CCÌ"
"F77÷7"
"C_LDÌ"
"F_LD÷7"
"CFLAGS=-K pic -DSPARC -G"
"C_LD_FLAGS=-G -DSOLARIS"
"FFLAGS=-pic -G"
"FOBJS=ftn_only_sun.o ftn_strarr_sun.o"
"F_LD_FLAGS=-G"
"F_LD_POST= -lF77 -lm -lc";
else
make libs
"SHL_EXT=so"
"CC¬c"
"F77÷7"
"C_LD=ld"
"F_LD=ld"
"CFLAGS=-pic -DSPARC -fsingle"
"C_LD_FLAGS=-assert pure-text"
"F_LD_FLAGS=-assert pure-text"
"FFLAGS=-pic"
"FOBJS=ftn_only_sun.o ftn_strarr_sun.o"
"F_LD_POST= -L/usr/lang/SC3.0.1/lib -lF77 ";
fi
;;
Si ce sont des modules chargés lors de l'exécution (pas au lancement mais au
besoin - comme des plugins), c'est un autre problème. Il faut déjà savoir par
quel mécanisme le programme veut se lier dynamiquement à ces modules (dlopen
par exemple) et comment il fait pour trouver ceux qui sont disponibles. Là, il
faudrait en savoir un peu plus pour répondre.
Je vais regarder le programme qui fait appel au .so pour voir comment il
est appelé. Si tu veux le source du programme (trace_decode_idl.c) je
peux te le faire parvenir par mail. Merci de aide (j'y vois déjà un peu
plus clair... dans le brouillard quand-même !).
Pourquoi ne pas donner le nom de programme ? Il est peut-être déjà porté sur
MacOS X.
Il s'agit d'un ensemble de programmes IDL, SolarSoft, créés par l'Equipe
de Physique Solaire de Lookheed pour l'exploitation des missions
spatiales solaires NASA/ESA (SXT/Yohkoh, SOHO, TRACE). Une installation
existe pour beaucoup de systèmes d'exploitation mais pas OS X encore...
Je souhaite l'utiliser sur Mac OS X plutôt que sur Sparc (pour changer)
mais la décompression des images du satellite (trace_decode_idl.so) ne
peut fonctionner vu la logique EFL du package...
À (at) Tue, 12 Aug 2003 12:59:35 +0200, ldame écrivait (wrote):
J'ai un problème avec un soft unix scientifique (basé sur IDL) et qui utilise pour certaines entrées/sorties des "Shared Objects", des .so qui n'existent pas dans OS X justement (bien expliqué dans les notes developer). J'ai le source en c de ce programme et gcc 3.1 (avec la bonne option qui va bien -no-cpp-precomp pour les compilations difficiles - j'ai donné avec MatLab 6.5 et les MEX files) et ma question est, une fois compilé, par quoi et comment remplace-t-on ces ".so" "Shared objects" ??? Une lib normale ".a" va-t-elle bien ou faut-il des "exoticités" type dylib, etc. (auxquelles je ne comprends rien...) ???
Cela dépend de la manière dont le programme utilise ces "Shared objects".
Si ce sont de simples bibliothèques dynamiques, c'est au moment de l'édition des liens (le 'link') que ça doit poser problème car il cherche des bibliothèques dont l'extensions est '.dylib' (pour "Dynamic Library"). Il faut donc modifier les makefile pour produire les bonnes extensions. Il se peut aussi que la fabrication de ces bibliothèques dynamiques soit piloté par 'libtool'. Dans ce cas, il y a peut-être pour chacune un fichier '.la' contenant le nom de l'extension à utiliser ou des 'flags' à modifier dans le makefile pour la génération des fichier '.la'.
Justement c'est ce que je ne comprends pas même en lisant le makefile (ce dernier envisage plusieurs type de machines - SunOS, IRIX, OSF 1, etc.). Il crée des ld_flags (pour SunOS par exemple). Je copie ci-après le début du makefile qui va avec le source pour ce qui concerne SunOS :
# Platform independant makefile for the IDL Call_External() examples. # SHELL=/bin/sh CFLAGS FFLAGS SHL_LIBS= trace_decode_idl.$(SHL_EXT)
# The following is the default entry point. This section will determine # what system we are on, set the correct flags and call this same makefile # again with the correct flags.
all : @echo "OS type detected: "`uname` @case `uname` in "SunOS") if [ -d /proc ]; then make libs "SHL_EXT=so" "CCÌ" "F77÷7" "C_LDÌ" "F_LD÷7" "CFLAGS=-K pic -DSPARC -G" "C_LD_FLAGS=-G -DSOLARIS" "FFLAGS=-pic -G" "FOBJS=ftn_only_sun.o ftn_strarr_sun.o" "F_LD_FLAGS=-G" "F_LD_POST= -lF77 -lm -lc"; else make libs "SHL_EXT=so" "CC¬c" "F77÷7" "C_LD=ld" "F_LD=ld" "CFLAGS=-pic -DSPARC -fsingle" "C_LD_FLAGS=-assert pure-text" "F_LD_FLAGS=-assert pure-text" "FFLAGS=-pic" "FOBJS=ftn_only_sun.o ftn_strarr_sun.o" "F_LD_POST= -L/usr/lang/SC3.0.1/lib -lF77 "; fi ;;
Si ce sont des modules chargés lors de l'exécution (pas au lancement mais au besoin - comme des plugins), c'est un autre problème. Il faut déjà savoir par quel mécanisme le programme veut se lier dynamiquement à ces modules (dlopen par exemple) et comment il fait pour trouver ceux qui sont disponibles. Là, il faudrait en savoir un peu plus pour répondre.
Je vais regarder le programme qui fait appel au .so pour voir comment il est appelé. Si tu veux le source du programme (trace_decode_idl.c) je peux te le faire parvenir par mail. Merci de aide (j'y vois déjà un peu plus clair... dans le brouillard quand-même !).
Pourquoi ne pas donner le nom de programme ? Il est peut-être déjà porté sur MacOS X.
Il s'agit d'un ensemble de programmes IDL, SolarSoft, créés par l'Equipe de Physique Solaire de Lookheed pour l'exploitation des missions spatiales solaires NASA/ESA (SXT/Yohkoh, SOHO, TRACE). Une installation existe pour beaucoup de systèmes d'exploitation mais pas OS X encore... Je souhaite l'utiliser sur Mac OS X plutôt que sur Sparc (pour changer) mais la décompression des images du satellite (trace_decode_idl.so) ne peut fonctionner vu la logique EFL du package...
Paul GABORIT
À (at) Tue, 12 Aug 2003 22:00:48 +0200, ldame écrivait (wrote):
Justement c'est ce que je ne comprends pas même en lisant le makefile (ce dernier envisage plusieurs type de machines - SunOS, IRIX, OSF 1, etc.). Il crée des ld_flags (pour SunOS par exemple). Je copie ci-après le début du makefile qui va avec le source pour ce qui concerne SunOS : [...]
"SHL_EXT=so"
À mon avis, ce sont de simples bibliothèques dynamiques. Donc un premier réglage consiste en :
"SHL_EXT=dylib"
Vous avez déjà découvert le -no-ccp-precomp. Il y a d'autres 'flags' (de compilation ou à l'édition des liens) qui peuvent être utiles . Regardez les conseils pour le portage sur le site de 'Fink' ou sur ce celui des 'DarwinPorts' (ou le nouveau site commun sensé regrouper ce genre d'info).
Fink: <http://fink.sourceforge.net/> DarwinPorts: <http://www.opendarwin.org/projects/darwinports/> Site commun: <http://www.metapkg.org/>
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Remove '.OOO' from e-mail address - Supprimez '.OOO' de l'adresse e-mail
À (at) Tue, 12 Aug 2003 22:00:48 +0200,
ldame <luc.dame@aerov.jussieu.fr> écrivait (wrote):
Justement c'est ce que je ne comprends pas même en lisant le makefile
(ce dernier envisage plusieurs type de machines - SunOS, IRIX, OSF 1,
etc.). Il crée des ld_flags (pour SunOS par exemple). Je copie ci-après
le début du makefile qui va avec le source pour ce qui concerne SunOS :
[...]
"SHL_EXT=so"
À mon avis, ce sont de simples bibliothèques dynamiques. Donc un premier
réglage consiste en :
"SHL_EXT=dylib"
Vous avez déjà découvert le -no-ccp-precomp. Il y a d'autres 'flags' (de
compilation ou à l'édition des liens) qui peuvent être utiles . Regardez les
conseils pour le portage sur le site de 'Fink' ou sur ce celui des
'DarwinPorts' (ou le nouveau site commun sensé regrouper ce genre d'info).
Fink: <http://fink.sourceforge.net/>
DarwinPorts: <http://www.opendarwin.org/projects/darwinports/>
Site commun: <http://www.metapkg.org/>
--
Paul Gaborit - <http://www.enstimac.fr/~gaborit/>
Remove '.OOO' from e-mail address - Supprimez '.OOO' de l'adresse e-mail
À (at) Tue, 12 Aug 2003 22:00:48 +0200, ldame écrivait (wrote):
Justement c'est ce que je ne comprends pas même en lisant le makefile (ce dernier envisage plusieurs type de machines - SunOS, IRIX, OSF 1, etc.). Il crée des ld_flags (pour SunOS par exemple). Je copie ci-après le début du makefile qui va avec le source pour ce qui concerne SunOS : [...]
"SHL_EXT=so"
À mon avis, ce sont de simples bibliothèques dynamiques. Donc un premier réglage consiste en :
"SHL_EXT=dylib"
Vous avez déjà découvert le -no-ccp-precomp. Il y a d'autres 'flags' (de compilation ou à l'édition des liens) qui peuvent être utiles . Regardez les conseils pour le portage sur le site de 'Fink' ou sur ce celui des 'DarwinPorts' (ou le nouveau site commun sensé regrouper ce genre d'info).
Fink: <http://fink.sourceforge.net/> DarwinPorts: <http://www.opendarwin.org/projects/darwinports/> Site commun: <http://www.metapkg.org/>
-- Paul Gaborit - <http://www.enstimac.fr/~gaborit/> Remove '.OOO' from e-mail address - Supprimez '.OOO' de l'adresse e-mail
