Hi Rob,
23/04/14 17:13, Rob Arthan wrote:
The query relates to the fact that polyc doesn?t do anything with LD_RUN_PATH (or DYLD_LIBRARY_PATH on Mac OS). Am I right in thinking that libpolyml will now always be statically linked so that you no longer to need to tell the dynamic linker where to find it? (For Poly/ML versions 5.5 and earlier the ProofPower makefiles that I am updating used to create an executable that linked libpolyml dynamically.)
I believe that, by default, Gcc default would not link libpolyml statically if a shared version of the library exists. Whether the shared version exists depends on the particular Poly/ML installation. Supplying the argument --enable-shared to 'configure' when building creates the SO file.
If Poly/ML is built with a shared library and is not installed to a system location (so the libpolyml SO file is not automatically found), then executables from polyc require LD_LIBRARY_PATH to be set. Setting the linker path in polyc came up in discussion before, in a thread starting here: http://lists.inf.ed.ac.uk/pipermail/polyml/2013-April/001216.html (due to the comment in item 3) The current position seems to be that anyone installing (a shared version) to a non-system location needs to set LD_LIBRARY_PATH, just as they will need to set PATH.
I believe that LD_RUN_PATH can be specified in the environment for polyc to achieve the required effect. However, its value would have to be determined, which is unfortunate given that polyc has this information internally (libdir). The PC file for use with pkg-config is an alternative that is useful for Makefiles, e.g.
POLYMLLIB := `pkg-config polyml --variable=libdir`
$(NAME)-polyml : $(NAME)-polyml.o @LD_RUN_PATH=$(POLYMLLIB):$(LD_RUN_PATH) $(CC) -ggdb -o $@ `pkg-config --libs polyml` $<
but you may not want a dependency on that utility.
Regards, Phil
P.S. I think there have been a few updates/fixes to polyc since the 5.5.1 release.