From: Nelson H. F. B. <be...@ma...> - 2006-10-19 14:06:46
|
In working around build problems for clisp-2.41, I built two binary distribution archives, one from a successful build on GNU/Linux on IA-32 for installation on local AMD64 and IA-64 systems where I still have build failures, and another for a remote user who did not have a C compiler on Sun Solaris 10 SPARC that could successfully build clisp-2.41 (I did my build with gcc-3.3.3). After doing the build with the default prefix=/usr/local setting, to make the binary tree, I tried $ make prefix=/tmp/clisp install That produced an installation tree that I could bundle up starting in /tmp/clisp, but it would not run in any file tree with a different prefix. I then did $ cd /tmp/clisp $ find . ! -type d | sort > ~/foo.cfiles $ cd /usr/local $ tar cf ~/clisp-2.41-solaris-10-sparc-binary-dist.tar.gz `cat ~/foo.cfiles` to create a distribution relative to the standard /usr/local that would run elsewhere, although I later found that I needed to include lib/libreadline.so.5 as well. It would be nice if clisp could work out its own installed file locations by computing paths relative to the pathname of the clisp binary, rather than having them hard-coded in the executable: $ strings -a /usr/local/bin/clisp | grep /usr/local %MAGIC%LISPLIBDIR=/usr/local/lib/clisp %MAGIC%LOCALEDIR=/usr/local/share/locale /usr/local/bin/clisp Developers on Apple Mac OS X do this for most applications, so their distributions can be unbundled anywhere in the filesystem, and used from there. The commercial Maple, Mathematica, and Matlab systems all do this as well. All use wrapper shell scripts that are configured at installation time to record absolute pathnames. Similarly, in the annual TeXLive distributions that some dedicated people in the TeX User Group have been producing for the last decade, all binaries are statically linked, and use relative paths to find files, so that they can be run directly off the distribution CDs and DVDs, or copied onto a user's filesystem in any convenient location, and they do not rely on availability of particular shared libraries on end-user systems. I myself have written packages that have hard-wired paths compiled into them, but elimination of that infelicity is on my TO-DO list for each of them. ------------------------------------------------------------------------------- - Nelson H. F. Beebe Tel: +1 801 581 5254 - - University of Utah FAX: +1 801 581 4148 - - Department of Mathematics, 110 LCB Internet e-mail: be...@ma... - - 155 S 1400 E RM 233 be...@ac... be...@co... - - Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ - ------------------------------------------------------------------------------- |
From: Sam S. <sd...@gn...> - 2006-10-19 15:26:48
|
Nelson H. F. Beebe wrote: > In working around build problems for clisp-2.41, I built two binary > distribution archives, one from a successful build on GNU/Linux on > IA-32 for installation on local AMD64 and IA-64 systems where I still > have build failures, and another for a remote user who did not have a > C compiler on Sun Solaris 10 SPARC that could successfully build > clisp-2.41 (I did my build with gcc-3.3.3). > > After doing the build with the default prefix=/usr/local setting, to > make the binary tree, I tried > > $ make prefix=/tmp/clisp install the standard way to share CLISP binary distributions, as explained in unix/INSTALL, is to do $ make distrib > That produced an installation tree that I could bundle up starting in > /tmp/clisp, but it would not run in any file tree with a different > prefix. of course. this is because "make install" records lisplibdir in the clisp executable. > It would be nice if clisp could work out its own installed file > locations by computing paths relative to the pathname of the clisp > binary, rather than having them hard-coded in the executable: clisp already does it if you use "make distrib", search for ENABLE_RELOCATABLE. Sam. |