[Ecls-list] observations

[Paul Bowyer]

On 12/20/2011 03:40 PM, Matthew Mondor wrote:
> 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...
Thank you for sharing, Mathew.

I'll do some experimentation with it all as soon as I get a little help 
from Jaunjo with a compilation problem reported in another message.

Paul