Comment author: administrator

From: markus@mail4.ai.univie.ac.at

The most recent CVS-snapshot (2001-09-07) neither compiles on our Solaris
machines nor on our Alpha but without problems on the Intel-boxes.

Thank your for the information.
Such a situation is not surprising, since we are mainly testing on
Intel boxes, and I've been trying to make the dynamic loading work
more smoothly, particularly for add-on libraries.

The problem you describe on Solaris is particularly interesting, since
you seem to have only static libraries for X11. You may try setting
the path by hand with -x11lib, to get shared ones, but we must still
support the case with static libraries only, since it may happen with
other libraries.

I've commited a few changes that may solve your problems. At least
this is now working on D/UNIX 4.0A, Solaris 2.6 and IRIX 6.5.
Can you tell us how it is for you.

Best regards,

Jacques Garrigue

Comment author: administrator

On Sun, 09 Sep 2001, Jacques Garrigue wrote:

Such a situation is not surprising, since we are mainly testing on
Intel boxes, and I've been trying to make the dynamic loading work
more smoothly, particularly for add-on libraries.

It is reasonable, of course, to first make things work on one (standard)
architecture before considering others so I don't mind. I use Linux/Intel
boxes most of the time anyway.

The problem you describe on Solaris is particularly interesting, since
you seem to have only static libraries for X11. You may try setting
the path by hand with -x11lib, to get shared ones, but we must still
support the case with static libraries only, since it may happen with
other libraries.

I don't use the Solaris machines often, but need them from time to time
to compile OCaml-binaries when people need them. The newly updated
CVS-snapshot gets much farer than the previous one. It only fails in
the installation procedure with the following problem:

make[1]: Entering directory /tmp/markus/ocaml/otherlibs/graph' test -f libgraphics.so && cp libgraphics.so /raid/user/markus/local/solaris2.6/lib/ocaml/libgraphics.so make[1]: *** [install] Error 1 make[1]: Leaving directory /tmp/markus/ocaml/otherlibs/graph'
make: *** [install] Error 2

which is obviously a consequence of this (the lack of a shared
X11-library):

../../tools/ocamlmklib -o graphics open.o draw.o fill.o color.o text.o image.o make_img.o dump_img.o point_col.o sound.o events.o subwindow.o -L/usr/local/X11R5/lib -lX11
ld: fatal: file /usr/local/X11R5/lib/libX11.a: unknown type, unable to process using elf(3E) libraries
ld: fatal: file /usr/local/X11R5/lib/libX11.a: unknown type, unable to process using elf(3E) libraries
ld: fatal: File processing errors. No output written to libgraphics.so
collect2: ld returned 1 exit status

The machine seems to have a funny configuration indeed. I don't know in
how far this is anywhere near any standard so I'll leave it up to you to
decide how to handle this specific case. This is what the X-configuration
looks like:

• a dead-old X11-version under /usr/local/X11R5
• a somewhat more recent one under /usr/X (symlink to /usr/openwin)

When I "configure" OCaml to use the second installation of our machine,
the following problem happens:

../../../boot/ocamlrun ../../../ocamlc -I ../../../stdlib -linkall -o labltktop -I ../support
-I ../../../toplevel toplevellib.cma labltk.cma
-I ../../unix unix.cma
-I ../../str str.cma
-dllpath /raid/user/markus/local/solaris2.6/lib/ocaml/labltk
topmain.cmo
Error on dynamically loaded library: ld.so.1: ../../../boot/ocamlrun: fatal: libtk8.1.so: open failed: No such file or directory
make[2]: *** [labltktop] Error 2
make[2]: Leaving directory `/tmp/markus/ocaml/otherlibs/labltk/lib'

Everything before this error seemed to work fine. "libtk8.1.so" can be
found in /usr/local/lib.

I've commited a few changes that may solve your problems. At least
this is now working on D/UNIX 4.0A, Solaris 2.6 and IRIX 6.5.
Can you tell us how it is for you.

What concerns the Alpha, the build process completes without problems,
but for some reason the "-dllpath"-option seems to get ignored, e.g. a
toplevel buildt with this option cannot be run:

32514:/net/loginsai/mottl/local/osf4.0e/bin/mocaml: /sbin/loader: Fatal Error: cannot map liblabltk41.so

This works without problems on the Intel-box.

If you need more information to fix the problems, just tell me! - Thanks
for your help!

Best regards,
Markus Mottl

--
Markus Mottl markus@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus

Comment author: administrator

Shared lib support in a state of flux, being worked on. XL, 2001-09-10

Comment author: administrator

Hi Jacques,

On Thu, 13 Sep 2001, Jacques Garrigue wrote:

I'm sorry to be so slow answering.

No problem, it's not critical for me. The previous release will do in the
meanwhile. Commercial vendors would probably take an order of magnitude
longer to respond so I am rather thankful... ;)

This suggests that the order of checked directories in ./configure
might be improved, to get the best directory. What about putting
/usr/openwin at the head of the list.

Hm, difficult question. Usually, sysadmins put the default they prefer
into the "local"-directory so as not to overwrite the vendor supplied
distributions. For some strange reason the Solaris machine where I have
tried installation has its more recent version (with shared libraries)
in the /usr/openwin path. So I'd suggest we better leave the order of
checked directories as it is and require the user to supply configure
flags for such weird cases.

Is /usr/local/lib in your LD_LIBRARY_PATH? It is not a default on
Solaris, so you might also want to add -R/usr/local/lib in -tklibs.

Ah, ok, I had assumed implicitly that such paths are considered by
"configure". There is also no notice in the INSTALL-file that this flag
can be used in such cases (yet).

With this flag and the ones for the right X-libraries the distribution
now compiles fine on our Solaris machine, including shared libraries. I
have tested the system by letting it build a "fat" toplevel containing
all of the distributed and all of my libraries and using this toplevel
to play a round of tetris by running it as a script. Works fine :-)

32514:/net/loginsai/mottl/local/osf4.0e/bin/mocaml: /sbin/loader: Fatal Error: cannot map liblabltk41.so

The reason might be in the dependencies of liblabltk41.so.
You can get more details with
$ _RLD_ARGS=-v make

It rather seems that ocamlmktop messes up things: I get quite weird
behaviour depending on what I link into the toplevel, e.g. (variables
set to required paths):

ocamlmktop -I $CONTRIB -I $LABLTK -dllpath $LABLTK labltk.cma pcre.cma

When I run the resulting toplevel, I get the following error (on the
Alpha only):

mottl@miss:~$ ./a.out
12793:./a.out: /sbin/loader: Fatal Error: cannot map liblabltk41.so

When I leave away "labltk.cma", the resulting toplevel works fine
(including the Pcre-library) and also vice versa. It's only the
combination which somehow clashes. Maybe this has to do with implicitly
stored compilation flags in pcre.cma? Just tell me if you need more
information...

Best regards,
Markus

--
Markus Mottl markus@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus

Comment author: administrator

Hi Markus,

I'm sorry to be so slow answering.

The machine seems to have a funny configuration indeed. I don't know in
how far this is anywhere near any standard so I'll leave it up to you to
decide how to handle this specific case. This is what the X-configuration
looks like:

• a dead-old X11-version under /usr/local/X11R5
• a somewhat more recent one under /usr/X (symlink to /usr/openwin)

This suggests that the order of checked directories in ./configure might
be improved, to get the best directory. What about putting
/usr/openwin at the head of the list.

When I "configure" OCaml to use the second installation of our machine,
the following problem happens:

../../../boot/ocamlrun ../../../ocamlc -I ../../../stdlib -linkall -o labltktop -I ../support
-I ../../../toplevel toplevellib.cma labltk.cma
-I ../../unix unix.cma
-I ../../str str.cma
-dllpath /raid/user/markus/local/solaris2.6/lib/ocaml/labltk
topmain.cmo
Error on dynamically loaded library: ld.so.1: ../../../boot/ocamlrun: fatal: libtk8.1.so: open failed: No such file or directory
make[2]: *** [labltktop] Error 2
make[2]: Leaving directory `/tmp/markus/ocaml/otherlibs/labltk/lib'

Everything before this error seemed to work fine. "libtk8.1.so" can be
found in /usr/local/lib.

Is /usr/local/lib in your LD_LIBRARY_PATH? It is not a default on
Solaris, so you might also want to add -R/usr/local/lib in -tklibs.

You can have more details on what went wrong by doing
$ LD_DEBUG=libs make

What concerns the Alpha, the build process completes without problems,
but for some reason the "-dllpath"-option seems to get ignored, e.g. a
toplevel buildt with this option cannot be run:

32514:/net/loginsai/mottl/local/osf4.0e/bin/mocaml: /sbin/loader: Fatal Error: cannot map liblabltk41.so

The reason might be in the dependencies of liblabltk41.so.
You can get more details with
$ _RLD_ARGS=-v make

Hope it helps,

 Jacques Garrigue

Comment author: administrator

On Thu, 13 Sep 2001, Jacques Garrigue wrote:

The problem is that the flag depends on the flavour Unix you are using.
That's really the gory part of dynamic dependencies. Automatizing it
in configure may improve it a bit, but the simpler way might be for your
administrator to add /usr/local/lib in the default path of the system,
or for you to set LD_LIBRARY_PATH by hand.

I can well imagine that it must be extremely painful to solve these
platform-dependent stuff. What concerns me, I can live with the
requirement to correctly configure OCaml or having to set global
variables.

You may try the latest version in CVS. I just made dllpaths work on
D/Unix. Before that only the last path was considered, when the link
is in custom mode (caused by pcre).

Thanks a lot, this solves the problem!

You may also try to dynamize pcre, building a shared object and
removing the -custom flag. This way ocamlrun is doing the loading,
which is safer. And no need to build a specific toplevel, since you
can just do #load"pcre.cma".

Once I find a bit more time, I'll play around with shared object creation
and tell you if there is a problem. Dynamic loading surely makes byte
code interpretation even more interesting (more platform independent).

Regards,
Markus

--
Markus Mottl markus@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus

Comment author: administrator

[Solaris]

Is /usr/local/lib in your LD_LIBRARY_PATH? It is not a default on
Solaris, so you might also want to add -R/usr/local/lib in -tklibs.

Ah, ok, I had assumed implicitly that such paths are considered by
"configure". There is also no notice in the INSTALL-file that this flag
can be used in such cases (yet).

The problem is that the flag depends on the flavour Unix you are using.
That's really the gory part of dynamic dependencies. Automatizing it
in configure may improve it a bit, but the simpler way might be for your
administrator to add /usr/local/lib in the default path of the system,
or for you to set LD_LIBRARY_PATH by hand.

[D/Unix]

It rather seems that ocamlmktop messes up things: I get quite weird
behaviour depending on what I link into the toplevel, e.g. (variables
set to required paths):

ocamlmktop -I $CONTRIB -I $LABLTK -dllpath $LABLTK labltk.cma pcre.cma

When I run the resulting toplevel, I get the following error (on the
Alpha only):

mottl@miss:~$ ./a.out
12793:./a.out: /sbin/loader: Fatal Error: cannot map liblabltk41.so

You may try the latest version in CVS. I just made dllpaths work on
D/Unix. Before that only the last path was considered, when the link
is in custom mode (caused by pcre). You may also try to dynamize pcre,
building a shared object and removing the -custom flag. This way
ocamlrun is doing the loading, which is safer. And no need to build a
specific toplevel, since you can just do #load"pcre.cma".

Jacques Garrigue