Also, from the Sun documentation: Linking The linker remains a 32-bit application, but this should be transparent to most users, since it is normally invoked indirectly by the compiler driver, for example, cc(1). If the linker is presented with a collection of ELF32 object files as input, it creates an ELF32 output file; similarly, if it is presented with a collection of ELF64 object files as input, it creates an ELF64 output file. Attempts to mix ELF32 and ELF64 input files are rejected by the linker.
LD_LIBRARY_PATH The two separate dynamic linker programs for 32-bit applications and for 64-bit applications are: /usr/lib/ld.so.1 and /usr/lib/sparcv9/ ld.so.1. At runtime, both dynamic linkers search the same list of colon- separated directories specified by the LD_LIBRARY_PATH environment variable. ****However, the 32-bit dynamic linker binds only to 32-bit libraries, while the 64-bit dynamic linker binds only to 64-bit libraries. So directories containing both 32-bit and 64-bit libraries can be specified via LD_LIBRARY_PATH, if needed.**** The 64-bit dynamic linker's search path can be completely overridden using the LD_LIBRARY_PATH_64 environment variable. On Jan 29, 11:39 pm, Bill Hart <[email protected]> wrote: > By the way, Solaris also has LD_LIBRARY_PATH_32. You can put 32 bit > libraries in that and leave the generic LD_LIBRARY_PATH for libtool to > play with. But you should put $LD_LIBRARY_PATH in $LD_LIBRARY_PATH_64 > and probably in $LD_LIBRARY_PATH_32 as well, otherwise it won't work. > > Bill. > > On Jan 29, 11:28 pm, Bill Hart <[email protected]> wrote: > > > > > It does work if you also add $LD_LIBRARY_PATH to LD_LIBRARY_PATH_64. I > > have tested this, i.e. MPIR now builds and all tests now pass on t2, > > so at least there is no problem for Sage. > > > We do not use the latest libtool. I tried upgrading it once before, > > and not only could I not understand the documentation, but in the end, > > I completely, abjectly failed. When I first started working on MPIR I > > spent almost 3 months full time working on the build system of MPIR. > > > Bill. > > > On Jan 29, 3:37 pm, "Dr. David Kirkby" <[email protected]> > > wrote: > > > > Bill Hart wrote: > > > > Ah, got it. LD_LIBRARY_PATH_64 needs to also contain > > > > /home/wbhart/mpir-1.3.0/.libs. Basically if LD_LIBRARY_PATH_64 is not > > > > specified at all, i.e. left blank, the linker uses whatever is in > > > > LD_LIBRARY_PATH. Otherwise it uses LD_LIBRARY_PATH_64 exclusively, > > > > which means that *all* 64 bit library paths must be in > > > > LD_LIBRARY_PATH_64. > > > > > So, in order to make MPIR work on t2, we'd need LD_LIBRARY_PATH_64 to > > > > be set globally for users *and* we'd need libtool to recognise that it > > > > needs to set LD_LIBRARY_PATH_64. > > > > > Unfortunately libtool doesn't do this automatically. So this is seems > > > > to be a bug in the version of libtool we use. Another solution is to > > > > set LD_LIBRARY_PATH_64 to include $LD_LIBRARY_PATH. This actually > > > > works because the substitution is done live by the shell. In other > > > > words, if LD_LIBRARY_PATH_64 is set to > > > > /usr/local/gcc-4.4.1-sun-linker/lib/sparcv9:$LD_LIBRARY_PATH for all > > > > users of t2 globally, I believe MPIR will work just fine on that > > > > machine. > > > > > Bill. > > > > I do not believe it is correct to add the sparcv9 directory to > > > LD_LIBRARY_PATH, > > > though I accept it might solve the issue. If anything, that would be > > > added to > > > LD_LIBRARY_PATH_64, but that is not working here. > > > > I would speak to the libtool developers - I know Ralf is very helpful, > > > and has > > > an account on 't2'. Perhaps he can solve this. > > > > Are you using the latest libtool ? If not, an upgrade might work. > > > > Dave -- To post to this group, send an email to [email protected] To unsubscribe from this group, send an email to [email protected] For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
