[Ecls-list] observations

[Matthew Mondor]

On Tue, 20 Dec 2011 11:46:16 -0800
Paul Bowyer <pbowyer at olynet.com> wrote:

> On 12/18/2011 08:08 PM, Matthew Mondor wrote:
> > On Sun, 18 Dec 2011 17:22:34 -0800
> > Paul Bowyer<pbowyer at olynet.com>  wrote:
> >
> >> Hello again Juanjo:
> >>
> >> Now that I have both 32-bit and 64-bit PCLinuxOS systems with ECL
> >> installed on them I tried running a executable created on the 32-bit
> >> system on the 64-bit system and discovered that libecl.so.11.1.1, which
> >> the executable is linked against, is different on the two systems.
> >>
> >> I was thinking that 32-bit executables would run on a 64-bit system, but
> >> not the other way around. Can I expect that to be true if I ship
> >> libecl.so.11.1.1 created on a 32-bit system to 64-bit systems?
> >>
> >> What is the best practice to keep from overwriting an existing 64-bit
> >> version of libecl.so.11.1.1?
> >>
> >> Maybe I'm asking a silly question...
> > A different configure --prefix, along with --enable-rpath should help
> > such that every executable loads its proper library, i.e. there then
> > can be multiple versions/builds of ECL, i.e. stored
> > as /usr/local/ecl-<suffix>/*
> >
> > If your use your system's libgmp, libgc and libdffi, this could still
> > be problematic, but ECL also supports building its own statically, i.e.
> > using --enable-boehm=included --with-gmp=included --with-dffi=included,
> > so every build can use its own ABI-compatible version.
> Mathew:
> 
> I didn't include you email address because they are continually returned 
> to me.
> 
> How much of ecl in /usr/local/lib is required to make executables run on 
> another machine? Do I just copy libecl.so.11.1.1, or is 
> /usr/local/lib/ecl-11.1.1 and its contents also required? Is it 
> necessary to provide the links to libecl.so.11.1.1 also?

I would personally transfer the whole /usr/local/<ecl-edition>
directory, (so including its bin, lib, etc. directories).  Also, since
the rpath tells ecl where to find its libecl, the location to place the
distribution on other systems should ideally be the same.  Because of
rpath, there is no need to use special library symlinks other than
those already created by the original install procedure.

RPATH is a means for ELF objects to embed a list of dynamic dependency
search paths.  The --enable-rpath configure directive should enable it,
and objects will then be linked with the necessary flags to set them
(i.e. -Wl,-R/usr/local/ecl-11.1.11-64bit/lib
-L/usr/local/ecl-11.1.11-64bit/lib).  When dlopen/dlfcn will be used to
load the dynamic libraries, that path will be used.  The  objdump -p
<object>  command should help to view the RPATHs of an ELF object.

It might be necessary to adjust PATH and/or make a symbolic link to the
ecl executable though, i.e. in the case
above: /usr/local/ecl-11.1.11-64bit/bin/ecl

Note that although the previous message showed how to embed libffi,
libgmp and libgc statically into ECL, the remaining libraries are by
default dynamically linked, which means that other system library
dependencies are still used (i.e. libc, libpthread, librt)...  If you
transfer your ECL distributions to those systems you should ensure that
they too have compatible library versions in this case.

It might be possible to do a fully static ECL build, although I
personally have no experience with it.  It then theoretically would
only have dependency on the kernel version.  Juan may confirm if this
is possible.  I expect that some of its own modules would however still
be dynamically loaded from its modules directory
(i.e. /usr/local/ecl-11.1.11-64bit/ecl-11.1.1 in the above case).

Of course the above exemples used /usr/local/<ecl-build>, but it well
could be a more OS-friendly path if you were building packages for your
OS, which might be to consider if you expect eventual deployment on
multiple systems...
-- 
Matt