In local.freebsd-current you write:
>> "Bruce A. Mah" wrote:
>> >
>> > If memory serves me right, Marcel Moolenaar wrote:
>> >
>> > > So, from a pure
>> > > ELF layout point of view, both shared objects and executables are the
>> > > same. But a shared library is not guaranteed to be executable. Allowing
>> > > shared objects to be executed is in violation with the specs:
>> >
>> > This may be a really stupid question, but what on Earth do they gain by
>> > allowing the execution of shared object files?
>>
>> 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.
>If so that would be a simple addition to the linux-lib port.
Personally, I wouldn't mind being able to run "ldd" on native shared
libraries as well (that is how it works on solaris). I can never remember
the right flags to "objdump" to get the dependency information...
I don't know quite how it works, but from ldd(1) on solaris 7:
FILES
/usr/lib/lddstub
Fake executable loaded to check the dependencies
of shared objects.
$.02,
/Mikko
--
Mikko Työläjä[EMAIL PROTECTED]
RSA Security
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
