[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