David,
On 2 Aug 2013, at 18:39, David Matthews <David.Matthews at prolingua.co.uk> wrote:
On 02/08/2013 16:47, Rob Arthan wrote:
I tried building ProofPower with it on a VirtualBox guest running Kubuntu 12.10.. The build runs the following command just after a run of poly that created pp-ml.o using PolyML.export.
LD_RUN_PATH=/opt/PolyML/latest/lib c++ -o slrp-ml pp-ml.o -L/opt/PolyML/latest/lib -lpolymain -lpolyml
LD_LIBRARY_PATH has been set in the shell script that calls this to /opt/PolyML/latest/lib
I get numerous undefined reference errors: /opt/PolyML/latest/lib/libpolyml.a(processes.o): In function `Processes::Init()': processes.cpp:(.text+0x166): undefined reference to `pthread_key_create ... /opt/PolyML/latest/lib/libpolyml.a(foreign.o): In function `load_sym(TaskData*, SaveVecEntry*)': foreign.cpp:(.text+0x27f9): undefined reference to `dlsym' ... /opt/PolyML/latest/lib/libpolyml.a(locking.o): In function `PLock::Trylock()': locking.cpp:(.text+0x257): undefined reference to `sem_init' ... collect2: error: ld returned 1 exit status
This seems to be a consequence of changing the default in configure to --disable-shared. It seems to require all the libraries (pthread, etc) at link time. It should be possible to get the old behaviour by building with --enable-shared. However, a better solution would be to change the linking line to use "polyc". e.g. /opt/PolyML/latest/bin/polyc -o slrp-ml pp-ml.o You then won't need any LD_RUN_PATH or LD_LIBRARY_PATH when you run slrp-ml because libpolyml will have been statically bound.
/bin/sh on ubuntu-flavoured Linux is dash, which is very pernickety about POSIX compliance. polyc needs a couple of changes to work with it (see attached diffs file).
However, I don't think polyc as it stands is going to work for me because it expects the poly binaries and libraries to be installed in /usr/local. Pro tem, I have just added -lpthread etc. (copied from the polyc source) into my make files. This seems to be backwards compatible.
You could enhance polyc to work out the installation directory using dirname $0 (which will give you BINDIR and then LIBDIR is `dirname $BINDIR`/lib). However, this approach can be fooled by symbolic links. I do something like this that is fairly foolproof in the scripts that run ProofPower, but I use a C program of my own to resolve symbolic links. You can probably do just as well using readlink and some string manipulation in the shell (or you would be very welcome to use my program for resolving symbolic links). Unfortunately, I don't have any time to look further into this just now.
Regards,
Rob.