Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3.03-alpha: ocamlrun ne trouve pas libX11.so.6.0 #2992

Closed
vicuna opened this issue Oct 13, 2001 · 4 comments
Closed

3.03-alpha: ocamlrun ne trouve pas libX11.so.6.0 #2992

vicuna opened this issue Oct 13, 2001 · 4 comments
Labels

Comments

@vicuna
Copy link

vicuna commented Oct 13, 2001

Original bug ID: 577
Reporter: administrator
Status: closed
Resolution: fixed
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)

Bug description

Salut,

je n'arrive pas à compiler la version alpha.
Voici le résumé produit par configure:

** Configuration summary **

Directories where Objective Caml will be installed:
binaries.................. /usr/local/bin
standard library.......... /usr/local/lib/ocaml
manual pages.............. /usr/local/man/man1 (with extension .1)
Configuration for the bytecode compiler:
C compiler used........... gcc
options for compiling..... -fno-defer-pop -Wall -Wno-unused
options for linking....... -lnsl -lsocket -lm -ldl -lcurses
shared libraries are supported
options for compiling..... -fPIC -fno-defer-pop -Wall -Wno-unused
command for building...... gcc -shared -o .so
Configuration for the native-code compiler:
hardware architecture..... sparc
OS variant................ solaris
C compiler used........... gcc
options for compiling..... -Wall -Wno-unused
options for linking....... -lnsl -lsocket -lm
assembler ................ $(AS)
preprocessed assembler ... gcc -c -DSYS_$(SYSTEM)
profiling with gprof ..... not supported
Source-level replay debugger: supported
Configuration for the external libraries:
libraries supported ...... unix str num dynlink bigarray threads graph dbm labltk
The "num" library:
target architecture ...... supersparc-solaris
The "graph" library:
options for compiling .... -I/usr/X11R6/include
options for linking ...... -L/usr/X11R6/lib -lX11
The "labltk" library:
use tcl/tk version ....... 8.3
options for compiling ....
options for linking ...... -ltk8.3 -ltcl8.3 -ldl

En particulier, c'est dans /usr/X11R6/lib que se trouve libX11.so.6.0.

"make world" échoue sur:

../../../boot/ocamlrun ../../../ocamlc -I ../../../stdlib -linkall -o
labltktop -I ../support
-I ../../../toplevel toplevellib.cma labltk.cma
-I ../../unix unix.cma
-I ../../str str.cma
if true; then echo -dllpath /usr/local/lib/ocaml/labltk; fi
topmain.cmo
Error on dynamically loaded library: ld.so.1: ../../../boot/ocamlrun:
fatal: libX11.so.6.0: open failed: No such file or directory
make[2]: *** [labltktop] Error 2
make[2]: Leaving directory
/users/formel8/frisch/ocaml-3.03-alpha/otherlibs/labltk/lib' make[1]: *** [all] Error 2 make[1]: Leaving directory /users/formel8/frisch/ocaml-3.03-alpha/otherlibs/labltk'
make: *** [otherlibraries] Error 2

En trussant ce dernier ocamlrun, on a:

mmap(0xFEFA0000, 1240, PROT_READ|PROT_WRITE|PROT_EXEC,
MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1, 0) = 0xFEFA0000
munmap(0xFEF86000, 57344) = 0
close(4) = 0
open("/usr/local/lib/libX11.so.6.0", O_RDONLY) Err#2 ENOENT
open("/usr/lib/libX11.so.6.0", O_RDONLY) Err#2 ENOENT
munmap(0xFF202000, 8760) = 0
munmap(0xFF1F0000, 14631) = 0
munmap(0xFF0C4000, 64592) = 0
munmap(0xFF000000, 742653) = 0
munmap(0xFEF94000, 50392) = 0
munmap(0xFEF00000, 546786) = 0
munmap(0xFF290000, 8192) = 0
getcontext(0xFFBEF008)
setcontext(0xFFBEF008)
write(3, " # ! / u s r / l o c a l".., 26) = 26
close(3) = 0
unlink("labltktop") = 0

Il ne regarde pas là où il faut pour libX11.so.6.0 (alors que
configure a trouvé le bon chemin).

Avec un LD_LIBRARY_PATH=/usr/X11R6/lib, ça marche.

Bon, je ne connais pas grand chose au link dynamique sur Solaris (et
encore moins au nouveau mécanisme d'ocamlrun) mais il semblerait qu'un
-R adéquat lors de la compilation d'ocamlrun pourrait faire l'affaire.

Désolé pour ce bug report approximatif (si vous avez besoin d'autres
infos sur la config utilisée, n'hésitez-pas à demander) ...

Alain

@vicuna
Copy link
Author

vicuna commented Oct 14, 2001

Comment author: administrator

From: frisch@clipper.ens.fr

je n'arrive pas à compiler la version alpha.

Il ne regarde pas là où il faut pour libX11.so.6.0 (alors que
configure a trouvé le bon chemin).

Avec un LD_LIBRARY_PATH=/usr/X11R6/lib, ça marche.

Bon, je ne connais pas grand chose au link dynamique sur Solaris (et
encore moins au nouveau mécanisme d'ocamlrun) mais il semblerait qu'un
-R adéquat lors de la compilation d'ocamlrun pourrait faire l'affaire.

Ok, c'est plus un oubli dans le FAQ qu'un veritable bug: linker un
executable en mode non-custom est, du point de vue des DLL, equivalent
a l'executer (il verifie qu'il peut tout charger). Donc il faut logiquement soit regler LD_LIBRARY_PATH, soit ajouter un -R/usr/X11R6/lib a X11_LINK (dans config/Makefile). Je ne vois pas ce
qu'il ferait dans ocamlrun, qui lui-meme ne depend pas de X11.
Cependant, je ne sais pas si c'est une bonne idee de le faire par
defaut, parce que de nombreux systemes regardent de toutes facons dans
/usr/X11R6/lib sans options supplementaires (ceci dit, ca ne coute pas
grand chose).

Ah, les joies des DLL.

Jacques

@vicuna
Copy link
Author

vicuna commented Oct 17, 2001

Comment author: administrator

Ok, c'est plus un oubli dans le FAQ qu'un veritable bug: linker un
executable en mode non-custom est, du point de vue des DLL, equivalent
a l'executer (il verifie qu'il peut tout charger). Donc il faut logiquement soit regler LD_LIBRARY_PATH, soit ajouter un -R/usr/X11R6/lib a X11_LINK (dans config/Makefile).

En toute logique, il faudrait mettre le -R. Ou encore: dans
ocamlmklib, si on donne une option -L/chemin/absolu, ajouter
automatiquement le -R/chemin/absolu correspondant. J'ai beau
chercher, je ne vois pas de cas où on ne voudrait pas ce
comportement...

Ah, les joies des DLL.

Comme tu dis :-)

  • Xavier

@vicuna
Copy link
Author

vicuna commented Oct 18, 2001

Comment author: administrator

On Sun, 14 Oct 2001, Jacques Garrigue wrote:

Ok, c'est plus un oubli dans le FAQ qu'un veritable bug: linker un
executable en mode non-custom est, du point de vue des DLL, equivalent
a l'executer (il verifie qu'il peut tout charger). Donc il faut logiquement soit regler LD_LIBRARY_PATH, soit ajouter un -R/usr/X11R6/lib a X11_LINK (dans config/Makefile). Je ne vois pas ce
qu'il ferait dans ocamlrun, qui lui-meme ne depend pas de X11.

Ah oui, c'est clair. Par contre, configure, qui détecte bien
/usr/X11R6/lib ne pourrait-il pas lui-même ajouter
ce qu'il faut à config/Makefile ?

Cependant, je ne sais pas si c'est une bonne idee de le faire par
defaut, parce que de nombreux systemes regardent de toutes facons dans
/usr/X11R6/lib sans options supplementaires (ceci dit, ca ne coute pas
grand chose).

Justement, configure peut essayer sans, et le mettre si ça ne marche pas,
non ?

Ah, les joies des DLL.

On souffre un peu, mais ça vaut le coup ! ( le
déchargement dynamique des modules Caml, ce serait bien aussi )

Alain

@vicuna
Copy link
Author

vicuna commented Oct 30, 2001

Comment author: administrator

Should be fixed with new -L/-rpath coupling in ocamlmklib. XL, 2001-10-30.

@vicuna vicuna closed this as completed Oct 30, 2001
@vicuna vicuna added the bug label Mar 19, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant