Talk:Executable library: Difference between revisions

(→‎executable Shared Objects?: e_type drives code interpretation?)
Line 18:
:::: I think I am missing something here. Why can't an elf shared object be made to contain this code? --[[User:Rdm|Rdm]] 18:18, 19 April 2011 (UTC)
::::: I don't know know much of anything about ELF, but you mentioned e_type...I'm guessing that's a header field which identifies the role of the binary? Perhaps there's no spec for how to execute that glue code if e_type isn't 2? (It's arguable that not all of that glue code is strictly necessary, though; the task is satisfiable without referencing environment varss, so <tt>environ</tt> might not be necessary) --[[User:Short Circuit|Michael Mol]] 18:49, 19 April 2011 (UTC)
:::::: Sure, ok... I suppose my point was that, if e_type had been defined as a bitfield instead of an enum, this kind of issue could have been solved already. Not that I can see a use for a core dump which is also a shared object and and also an executable... And I suppose ELF could be extended to support a "shared object that is also an executable", though I am not sure who could get away with defining such an extension. (On Linux it would be whoever owns /etc/ld-linux.so but for ELF as a whole it's probably some standards body that would take 10 years before they could get around to considering the issue.) --19:03, 19 April 2011 (UTC)
6,951

edits