[Ecls-list] observations

Matthew Mondor mm_lists at pulsar-zone.net
Mon Dec 19 04:24:42 UTC 2011


On Sun, 18 Dec 2011 23:08:59 -0500
Matthew Mondor <mm_lists at pulsar-zone.net> 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.

Oh, I forgot to mention about setting CC and CFLAGS/LDFLAGS to the
wanted values prior to running the configure script, such that you
build ECL with the wanted compiler and ABI-specific flags...

Hopefully this helps a bit,
-- 
Matt




More information about the ecl-devel mailing list