2009/5/19 "C. Bergstr?m" <codestr0m at osunix.org>: > > I'm having a small issue with ld.so.1 in onnv_115. onnv_107 works/worked > fine.. > > From usr/src/cmd/sgs/rtld/amd64/ > > This works.. > > LD_PRELOAD=./ld.so.1 /usr/bin/amd64/ld --help > usage: ld [-6:abc:d:e:f:h:il:mo:p:rstu:z:B:CD:F:GI:L:M:N:P:Q:R:S:VW:Y:?] > file(s) >
As Ali Bahrami indicated, you are attempting to use ld.so.1 in a way that makes no sense, including no sense under the use you intend. While ld.so.1 is not an actual executable, you can call it like one, rather than dlopen() it like a normal shared lib: $ file /lib/ld.so.1 /lib/ld.so.1: ELF 32-bit LSB dynamic lib 80386 Version 1, dynamically linked, not stripped, no debugging information available bash-3.2$ file /lib/ld.so.1 bash-3.2$ /lib/ld.so.1 usage: ld.so.1 [-e option,...] dynamic-object [object args,...] Killed bash-3.2$ file /lib/amd64/ld.so.1 /lib/amd64/ld.so.1: ELF 64-bit LSB dynamic lib AMD64 Version 1 [SSE CMOV], dynamically linked, not stripped, no debugging information available bash-3.2$ /lib/amd64/ld.so.1 usage: ld.so.1 [-e option,...] dynamic-object [object args,...] Killed bash-3.2$ LD_PRELOAD_32=/lib/ld.so.1 /bin/ls Desktop Documents Downloads Public Screenshots bash-3.2$ uname -a SunOS AMILO-Pa3515 5.11 snv_114 i86pc i386 i86pc bash-3.2$ isainfo -k amd64 bash-3.2$ I would suggest you carefully re-read ld.so.1(1) and maybe additionally crle(1). I also played with mixing different userland <--> kernel versions since 2006. I even do it in the global zone from time to time. For example sometimes I needed another version of /lib and /usr/lib. Then I would do # mount -F lofs -O 192.168.155.12:/usr /usr # mount -F lofs -O 192.168.155.12:/lib /lib Sometimes I then ran into misc. incompatibilities and simply setting LD_LIBRARY_PATH_32 to something would not make a broken binary <--vs--> shared lib combination to work as expected. THEN I would depend on using ld.so.1, but not in the way you tried to use it with LD_PRELOAD (redundant, makes no sense), but instead with LD_LIBRARY_PATH_32=/path/to/OriginalMatchingLibs /lib/ld.so.1 /usr/X11/bin/i386/Xorg and so on. Here is one of the public references where I mentioned this: http://mail.opensolaris.org/pipermail/xwin-discuss/2009-May/003413.html Much fun hating Sun. I - on the other hand - RESPECT those brilliant minds. > As soon as I mv ld.so.1 to /lib/amd64 things hang.. (Before I was getting a > "Bad system call (core dumped)") With the stack not looking very interesting > (I didn't compile have debugging on, but still..) ?It's inside a zone so I > can easily revert things if needed.. Is the best way to debug this really > dbx or maybe there's something simple I'm missing. > > Thanks > > ./Christopher > _______________________________________________ > on-discuss mailing list > on-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/on-discuss >
