Re: [SEToolkit-developer] Library problem when compiling with Studio 11 on Solaris 10
Brought to you by:
dmichelsen
|
From: Alex K. <ale...@gm...> - 2007-08-21 10:35:02
|
On 05/04/07, Dagobert Michelsen <da...@ba...> wrote: > Hi, > > when I compile the SE with the latest autoconf on Solaris 10 with SS > 11 everything works fine on > Solaris 10, 9 and 8. However, on Solaris 7 I get linker errors to libc: > > bopack7# cd /opt/RICHPse/libexec > bopack7# ./se.sparc > ld.so.1: ./se.sparc: fatal: libc.so.1: version `SUNW_1.19' not found > (required by file ./se.sparc) > zsh: killed ./se.sparc > bopack7# ldd se.sparc > libm.so.1 => /usr/lib/libm.so.1 > libkvm.so.1 => /usr/lib/libkvm.so.1 > libkstat.so.1 => /usr/lib/libkstat.so.1 > libdl.so.1 => /usr/lib/libdl.so.1 > libgen.so.1 => /usr/lib/libgen.so.1 > libsocket.so.1 => /usr/lib/libsocket.so.1 > libnsl.so.1 => /usr/lib/libnsl.so.1 > libc.so.1 => /usr/lib/libc.so.1 > libc.so.1 (SUNW_1.19) => (version not found) > libelf.so.1 => /usr/lib/libelf.so.1 > libmp.so.2 => /usr/lib/libmp.so.2 > /usr/platform/SUNW,Ultra-5_10/lib/libc_psr.so.1 > bopack7# pvs se.sparc > libm.so.1 (SUNW_1.1); > libkvm.so.1 (SUNW_1.1); > libkstat.so.1 (SUNW_0.7); > libdl.so.1 (SISCD_2.3); > libgen.so.1 (SUNW_1.1); > libc.so.1 (SUNW_1.19, SUNWprivate_1.1); > bopack7# pvs /usr/lib/libc.so.1 > libdl.so.1 (SUNW_0.7, SUNWprivate_1.1, SISCD_2.3); > libc.so.1; > SUNW_1.18.1; > SUNW_1.18; > SUNW_1.17; > SUNW_1.16; > SUNW_1.15; > SUNW_1.14; > SUNW_1.13; > SUNW_1.12; > SUNW_1.11; > SUNW_1.10; > SUNW_1.9; > SUNW_1.8; > SUNW_1.7; > SUNW_1.6; > SUNW_1.5; > SUNW_1.4; > SUNW_1.3; > SUNW_1.2; > SUNW_1.1; > SUNW_0.9; > SUNW_0.8; > SUNW_0.7; > SISCD_2.3; > SYSVABI_1.3; > SUNWprivate_1.2; > SUNWprivate_1.1; > bopack7# more /etc/release > Solaris 7 11/99 s998s_u4SunServer_10 SPARC > Copyright 1999 Sun Microsystems, Inc. All Rights Reserved. > Assembled 15 October 1999 > > Solaris 10 has newer versions included, so I assume that SS 11 always > binds to libc SUNW_1.19 > Is there a way to circumvent this or must we go back to build > individual versions of se for > different operating systems like it was in 3.3 or so? > It's the only way to do it right, given the way its structured at the moment. We could abstract out those pieces which are OS dependent (and compile these on the relevant platform) then compile what's left on the earliest platform we care about and then dynamically bind all the pieces together at run time. But that seems more effort than it's worth. -- Alex Kiernan |