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
compilation problems with snapshot #2958
Comments
Comment author: administrator From: markus@mail4.ai.univie.ac.at
Thank your for the information. The problem you describe on Solaris is particularly interesting, since I've commited a few changes that may solve your problems. At least Best regards, Jacques Garrigue |
Comment author: administrator On Sun, 09 Sep 2001, Jacques Garrigue wrote:
It is reasonable, of course, to first make things work on one (standard)
I don't use the Solaris machines often, but need them from time to time make[1]: Entering directory which is obviously a consequence of this (the lack of a shared ../../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 The machine seems to have a funny configuration indeed. I don't know in
When I "configure" OCaml to use the second installation of our machine, ../../../boot/ocamlrun ../../../ocamlc -I ../../../stdlib -linkall -o labltktop -I ../support Everything before this error seemed to work fine. "libtk8.1.so" can be
What concerns the Alpha, the build process completes without problems, 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 Best regards, -- |
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:
No problem, it's not critical for me. The previous release will do in the
Hm, difficult question. Usually, sysadmins put the default they prefer
Ah, ok, I had assumed implicitly that such paths are considered by With this flag and the ones for the right X-libraries the distribution
It rather seems that ocamlmktop messes up things: I get quite weird ocamlmktop -I $CONTRIB -I $LABLTK -dllpath $LABLTK labltk.cma pcre.cma When I run the resulting toplevel, I get the following error (on the mottl@miss:~$ ./a.out When I leave away "labltk.cma", the resulting toplevel works fine Best regards, -- |
Comment author: administrator Hi Markus, I'm sorry to be so slow answering.
This suggests that the order of checked directories in ./configure might
Is /usr/local/lib in your LD_LIBRARY_PATH? It is not a default on You can have more details on what went wrong by doing
The reason might be in the dependencies of liblabltk41.so. Hope it helps,
|
Comment author: administrator On Thu, 13 Sep 2001, Jacques Garrigue wrote:
I can well imagine that it must be extremely painful to solve these
Thanks a lot, this solves the problem!
Once I find a bit more time, I'll play around with shared object creation Regards, -- |
Comment author: administrator [Solaris]
The problem is that the flag depends on the flavour Unix you are using. [D/Unix]
You may try the latest version in CVS. I just made dllpaths work on Jacques Garrigue |
Original bug ID: 517
Reporter: administrator
Status: closed
Resolution: not a bug
Priority: normal
Severity: minor
Category: ~DO NOT USE (was: OCaml general)
Bug description
Hello,
the problems here are not critical to me so don't bother fixing them if
they are not high priority for you:
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.
The last lines of compilation read as follows on Solaris:
../../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
make[1]: *** [libgraphics.a] Error 1
make[1]: Leaving directory `/tmp/markus/ocaml/otherlibs/graph'
make: *** [otherlibraries] Error 2
markus@westbahn:/tmp/markus/ocaml$ uname -a
SunOS westbahn 5.6 Generic_105181-23 sun4u sparc SUNW,Ultra-2
Here is the problem on the Alpha:
gcc -O -mieee -fno-defer-pop -Wall -Wno-unused -D_REENTRANT -c unix.c -o unix.o
unix.c: In function
caml_dlopen': unix.c:158:
RTLD_GLOBAL' undeclared (first use in this function)unix.c:158: (Each undeclared identifier is reported only once
unix.c:158: for each function it appears in.)
make[1]: *** [unix.o] Error 1
make[1]: Leaving directory `/usr/loginsai/mottl/local/osf4.0e/src/cvs/ocaml/byterun'
make: *** [coldstart] Error 2
mottl@miss:~/local/src/cvs/ocaml$ uname -a
OSF1 miss.wu-wien.ac.at V4.0 1091 alpha alpha
The configuration command in both cases:
./configure -cc gcc -prefix $LOCAL_INST -with-pthread
Just tell me if you need more information on any of the errors.
Best regards,
Markus Mottl
--
Markus Mottl markus@oefai.at
Austrian Research Institute
for Artificial Intelligence http://www.oefai.at/~markus
The text was updated successfully, but these errors were encountered: