Phil Harman wrote:
> First of all, the cp(1) command is actually a 32-bit application ...
>
> # uname -a
> SunOS opensolaris 5.11 snv_101b i86pc i386 i86pc Solaris
> # which cp
> /usr/gnu/bin/cp
> # file /usr/gnu/bin/cp
> /usr/gnu/bin/cp: ELF 32-bit LSB executable 80386 Version 1
> [FPU], dynamically linked, stripped
> # ldd /usr/gnu/bin/cp
> libgen.so.1 => /lib/libgen.so.1
> libc.so.1 => /lib/libc.so.1
> libm.so.2 => /lib/libm.so.2
> #
> <big snip>
I wasn't kidding when I said everything was 64bit
file /usr/bin/cp
/usr/bin/cp: ELF 64-bit LSB executable, x86-64, version 1 (SYSV),
dynamically linked (uses shared libs), not stripped, uses FPU CMOV FXSR SSE
I'm also not using the gnu version..
Ok.. so mv should work.. thanks
I also found another work-around
cp libc.so.1 /lib/amd64/libc.so.1.new; cd /lib/amd64;ln -sf
libc.so.1.new libc.so; mv -f libc.so.1.new libc.so.1; ln -sf libc.so.1
libc.so
The above I think is using crle a hack to take advantage of the symlink
in /usr/lib/amd64 being correct while the one in /lib/am64 isn't..
(doesn't matter)
and if you're *really* curious.. here's why I'm replacing my system libc..
Running: dlmgmtd -d
(process id 7860)
stopped in priv_vlist at line 384 in file "privlib.c"
384 priv_set_t *pset = priv_allocset();
(dbx) dump
priv = 0x5c4 "<bad address 0x5c4>"
ap = 0xfffffd7fffdfe960
pset = 0x81c
(dbx) list +20
384 priv_set_t *pset = priv_allocset();
385 const char *priv;
386
387 if (pset == NULL)
388 return (NULL);
389
390 priv_emptyset(pset);
391
392 while ((priv = va_arg(ap, const char *)) != NULL) {
393 if (priv_addset(pset, priv) < 0) {
394 priv_freeset(pset);
395 return (NULL);
396 }
397 }
398 return (pset);
399 }
400
I'm hoping to fix this tonight..
Thanks
./C
_______________________________________________
opensolaris-discuss mailing list
[email protected]
