On my solaris 2.6 box, I get
ssh moni
ld.so.1: ssh: fatal: libz.so: open failed: No such file or directory
Killed
while as root, I have no problem. Note that
echo $LD_LIBRARY_PATH
/space/local/lib:/usr/local/lib:/usr/openwin/lib:/usr/lib:/opt/x11r5/lib
ls -l /space/local/lib/libz.*
-rwxr-xr-x 1 wierdlm faculty 70488 Mar 10 17:26 /space/local/lib/libz.a
-rwxr-xr-x 1 bin bin 85600 Mar 10 17:26 /space/local/lib/libz.so
-rwxr-xr-x 1 bin bin 85600 Mar 10 17:26 /space/local/lib/libz.so.1
-rwxr-xr-x 1 bin bin 85600 Mar 10 17:26
/space/local/lib/libz.so.1.1.3
Also, when I run ssh as root as
truss -e -o truss.out ssh moni
I get
grep libz truss.out
open("/space/local/lib/libz.so", O_RDONLY) = 4
I do not know how to trace ssh when as nonroot though. I get
truss -e -o truss.out ssh moni
ld.so.1: ssh: fatal: libz.so: open failed: No such file or directory
truss: cannot trace set-id or unreadable object file: /space/local/bin/ssh
Any ideas?
Thx
Mate
On Mon, 13 Mar 2000, Mate Wierdl wrote:> On my solaris 2.6 box, I get > > ssh moni > ld.so.1: ssh: fatal: libz.so: open failed: No such file or directory > Killedwhat happens when you export your LD_LIBRARY_PATH? Is it the same as the one below?> while as root, I have no problem. Note that > > echo $LD_LIBRARY_PATH > /space/local/lib:/usr/local/lib:/usr/openwin/lib:/usr/lib:/opt/x11r5/libTo avoid LD_LIBRARY_PATH on Solaris, I always build my executables with LD_RUN_PATH=<dirlist> and -R<sparce/local/lib> (in your case). If for whatever reason you end up putting libraries elsewhere, then you can use LD_LIBRARY_PATH to maek the binary work.> ls -l /space/local/lib/libz.* > -rwxr-xr-x 1 wierdlm faculty 70488 Mar 10 17:26 /space/local/lib/libz.a > -rwxr-xr-x 1 bin bin 85600 Mar 10 17:26 /space/local/lib/libz.so > -rwxr-xr-x 1 bin bin 85600 Mar 10 17:26 /space/local/lib/libz.so.1 > -rwxr-xr-x 1 bin bin 85600 Mar 10 17:26 /space/local/lib/libz.so.1.1.3 > > Also, when I run ssh as root as > > truss -e -o truss.out ssh moni > > I get > > grep libz truss.out > open("/space/local/lib/libz.so", O_RDONLY) = 4 > > I do not know how to trace ssh when as nonroot though. I get > > truss -e -o truss.out ssh moni > ld.so.1: ssh: fatal: libz.so: open failed: No such file or directory > truss: cannot trace set-id or unreadable object file: /space/local/bin/ssh> Any ideas?Add "env LDFLAGS='-R/space/local/lib'" to your configure line. I just built openssl-0.9.5 and openssh-1.2.2 and everything worked. (Solaris 7, x86, gcc-2.95.2) Ben
On Wed, Mar 15, 2000 at 07:13:33PM +1100, Damien Miller wrote:> On Tue, 14 Mar 2000, Mate Wierdl wrote: > > > This must be the problem: while I specify > > [snip] > > > This is on Solaris 2.6 > > Caould you try the 1.2.3pre3 snapshot? it should set most of the > -R flags automatically. > > > One more remark: configure does not seem to understand the LD > > variable (to specify the ld program to use). Since apparently the > > most recent GNU ld does not work well on Solaris (it is on the egcs > > webpage), perhaps it may be worth making configure LD aware. > > Refresh my memory - why do you need to use a different ld?I am not sure I understand the question. On our system, the sysadm installed gcc so that it uses the gnu linker. But one can read at http://gcc.gnu.org/install/specific.html#sparc-sun-solaris* that ===============================sparc-sun-solaris* binutils 2.9.1 has known bugs on this platform. We recommend to use the vendor tools (Sun as, Sun ld) until these have been fixed. Unfortunately, C++ shared libraries, including libstdc++, won't work properly if assembled with Sun as: the linker will complain about relocations in read-only sections, in the definition of virtual tables. Some possible work-arounds: use some development release of binutils, wait for the next stable binutils release or refrain from creating C++ shared libraries. ============================== For example, the program RPM's configure exits with an error if it finds that the gnu linker is used. Mate
On Wed, 15 Mar 2000, Mate Wierdl wrote:> > Refresh my memory - why do you need to use a different ld? > > I am not sure I understand the question. On our system, the sysadm > installed gcc so that it uses the gnu linker. But one can read atOK - configure now honours a LD enviornment variable: LD=/some/other/ld ./configure It defaults to $CC -d -- | "Bombay is 250ms from New York in the new world order" - Alan Cox | Damien Miller - http://www.mindrot.org/ | Email: djm at mindrot.org (home) -or- djm at ibs.com.au (work)
Mate Wierdl <mw at wierdlmpc.msci.memphis.edu> writes:> ssh moni > ld.so.1: ssh: fatal: libz.so: open failed: No such file or directory > KilledIs libz.so in the default library search path? ssh is typically a setuid binary, and LD_LIBRARY_PATH is ignored for setuid binaries (for obivious security reasons).