On 12/20/2011 03:40 PM, Matthew Mondor wrote: > On Tue, 20 Dec 2011 11:46:16 -0800 > Paul Bowyer<pbow...@olynet.com> wrote: > >> On 12/18/2011 08:08 PM, Matthew Mondor wrote: >>> On Sun, 18 Dec 2011 17:22:34 -0800 >>> Paul Bowyer<pbow...@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... Thanks again for all of the help, Matthew (I spelled you name right this time). Transferring the complete /usr/local/ecl32 directory to the 64-bit version of PCLinuxOS worked fine after I manually created the symbolic links in the /usr/local/ecl32/lib directory. I wasn't clever enough to determine the correct incantation of cp to get the links to transfer also.
Also, the executable that I created on the 32-bit platform, ran without problems on the 64-bit platfom. Now if that will remain true for other 32/64-bit Linux platforms, I'll be a happy camper... I would still like to know how to compile ecl on the 64-bit platform so the created library will work with 32-bit created executables. I tried passing some arguments to configure in an effort to get gmp to compile, but I don't yet know the proper combination. I'll try some other things after the holidays. Have a great holiday season, Paul ------------------------------------------------------------------------------ Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev _______________________________________________ Ecls-list mailing list Ecls-list@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ecls-list
