Marc van Kempen wrote:
> > The only gain I see, if you can call it a gain, is that you can get
> > non-trivial information out of a shared object from within scripts, but
> > I don't know if this has been the reason. If you don't allow execution
> > of shared objects, you have to use dlopen(3) and call some functions or
> > query some variables.
> Would it be possible to write a small wrapper to load the shared library
> and execute some entryfunction to get it started? I suppose that's what
> the elf-loader under linux does.
You mean something like MS Windows rundll? Yes, that should work in
general. But may not in all cases. If the dynamic linker (ld-linux.so.2)
checks the executable name to see if it has been started by the OS to
perform dynamic linking for the binary or to see if it's executed itself
for the dependency information (ie by ldd), then this may not work (I
have to check if this is the case, but I don't think it's out of the
> If so that would be a simple addition to the linux-lib port.
For trivial cases, the simplest solution would be to just remove
/compat/linux/usr/bin/ldd and have our native ldd do the work. If
something depends on the switches, this won't work.
I haven't come up with a solution I like. I also haven't paid much
attention to it, because it doesn't seem a major problem. Suggestions
are always welcome, of course. As a work-around, I can have
linux_devtools remove ldd(1) so that it at least works for the trivial
cases. I don't know why I haven't done this already :-)
mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
tel: (408) 447-4222
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message