C. Bergstr?m wrote:
>
> 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 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
Can you explain what you're trying to achieve with that?
LD_PRELOAD is something that is implemented by ld.so.1, so
ld.so.1 is already in memory and running at the point when
your LD_PRELOAD is being seen and acted upon.I'm not sure what
happens at that point, but I don't think it would be anything good.
If you're trying to substitute a different ld.so.1, then you
can run your example this way:
./ld.so.1 /usr/bin/amd64/ld --help
Or you can elfedit your binary to point at a different interpreter.
Or even better since you're using a zone, here's how I use zones to
do linker testing:
http://blogs.sun.com/ali/entry/testing_critical_system_components_without
- Ali
