Talk:Executable library: Difference between revisions

→‎executable Shared Objects?: e_type drives code interpretation?
(→‎executable Shared Objects?: e_type drives code interpretation?)
Line 17:
::: There are other problems with ELF shared objects. With systems like [[OpenBSD]], an executable needs some [http://www.openbsd.org/cgi-bin/cvsweb/src/lib/csu/amd64/crt0.c?rev=1.3 special code] to initialize certain variables (like <tt>environ</tt> and <tt>__progname</tt>), to call <tt>main()</tt> and to call <tt>exit()</tt> with the return value from main. A shared object misses this special code, so you cannot start a shared object as an executable. --[[User:Kernigh|Kernigh]] 17:11, 19 April 2011 (UTC)
:::: 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)