I've updated the "polyc" script so that as well as accepting an ML source file to compile and link it can also be used to link object files created with PolyML.export.
Switching to static linking by default in SVN has turned up a few problems. In particular it seems that it's important to include the libraries required by libpolyml. The problem is that this can depend on how it was built. In particular, the configure script will use GMP if it is present but falls back to the internal arbitrary precision package if it is not. That has the effect that if GMP was detected during the build process then the linking line must include -lgmp. However, if GMP is not present then including -lgmp will result in an error message. This makes it rather difficult to write a general purpose linking script. The linking line found at http://www.polyml.org/FAQ.html#standalone has gone through several versions and still has to be tweaked. It should now just require polyc -o hello hello.o
Although "polyc" is a shell script it is produced during the build process and includes the appropriate options for linking depending on what the configure script found. The name "polyc" was meant to be analogous to "cc" or "gcc". I don't know whether it might be better to use the name "poly" for both the "batch" and interactive versions depending on the options. Any ideas?
David
On Thu, 1 Aug 2013, David Matthews wrote:
Switching to static linking by default in SVN has turned up a few problems. In particular it seems that it's important to include the libraries required by libpolyml. The problem is that this can depend on how it was built. In particular, the configure script will use GMP if it is present but falls back to the internal arbitrary precision package if it is not. That has the effect that if GMP was detected during the build process then the linking line must include -lgmp. However, if GMP is not present then including -lgmp will result in an error message.
I usually try to compile with gmp, but there are some snags. What I usually do is to compile on one machine with libgmp, then copy the required libgmp.so files to the polyml target directory, and run on another machine with LD_LIBRARY_PATH changed to that. This works most of the time.
Is there a way to assimilate libgmp.so into the compiled poly executable in the plain-old static manner? If yes, it might solve the problem described above.
One might be more brutal in making a completely static link, with the C/C++ libraries included, but I was educated in never doing that. (The transition from SunOS 4.x to SunOS 5.x/Solaris was critically depending on the operating system being able to provide fresh shared libraries for old executables.)
Makarius
On 01/08/2013 19:40, Makarius wrote:
Is there a way to assimilate libgmp.so into the compiled poly executable in the plain-old static manner? If yes, it might solve the problem described above.
One might be more brutal in making a completely static link, with the C/C++ libraries included, but I was educated in never doing that. (The transition from SunOS 4.x to SunOS 5.x/Solaris was critically depending on the operating system being able to provide fresh shared libraries for old executables.)
I found the following http://stackoverflow.com/questions/4156055/gcc-static-linking-only-some-libr... when this came up on the list before.
Linking with an explicit path to the static library for GMP rather than using -lgmp seems to work. i.e. on Debian 32-bit gcc -o hello hello.o -L/home/david/mypolyml -lpolymain -lpolyml /usr/lib/i386-linux-gnu/libgmp.a -lpthread -lrt -lm -ldl -lstdc++ -lgcc_s -lgcc
This produces a binary that works on a machine that does not have the GMP libraries.
David
-
David.Matthews＠prolingua.co.uk -
makarius＠sketis.net