[Ecls-list] observations

Paul Bowyer pbowyer at olynet.com
Tue Dec 20 19:46:16 UTC 2011

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.

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?



More information about the ecl-devel mailing list