History

This task came from discussions Here. I was nervous about just deleting all the code for that task so decided to create this, mark the other for maybe future deletion, and see how things go. --Paddy3118 23:44, 14 March 2011 (UTC)

Tcl problem

Oh no, after all the confusion of Scripted main the Tcl example shows a design pattern that is central to the method, but doesn't follow the task description in a way that I had thought a secondary feature of the task - the two separate files. I won't make any changes just yet, (maybe the Tcl author would like to comment)? But I am aware that although I like what this sets out to do, the explanation might need further clarification. --Paddy3118 06:13, 16 March 2011 (UTC)

I must've been distracted when I wrote it. Corrected. –Donal Fellows 11:28, 16 March 2011 (UTC)
Thanks Donal. --Paddy3118 12:34, 16 March 2011 (UTC)

executable Shared Objects?

Is there a way to build Shared Objects to make them valid executables? --Oenone 08:41, 19 April 2011 (UTC)

Presumably you mean Shared Objects and not Shared Objects? --Rdm 12:19, 19 April 2011 (UTC)
I know it's doable in the former case on Windows. I don't know enough about ELF to know if it's doable there. --Michael Mol 12:24, 19 April 2011 (UTC)

Yes, I was talking about ELF Shared Objects. I don't know any way to make it both, a shared object and an executable. So for Unix the task is not solvable. --Oenone 12:35, 19 April 2011 (UTC)

ELF != Unix -- you just need a different file format (and, thus, a different "interpreter"). But the problem with elf is e_type where 2 is "executable file" and 3 is "shared object" http://linux.die.net/man/5/elf --Rdm 13:07, 19 April 2011 (UTC)
There are other problems with ELF shared objects. With systems like OpenBSD, an executable needs some special code to initialize certain variables (like environ and __progname), to call main() and to call exit() with the return value from main. A shared object misses this special code, so you cannot start a shared object as an executable. --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? --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 environ might not be necessary) --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.) --Rdm 19:03, 19 April 2011 (UTC)

So, most compiled languages will have to be omitted, since most operating systems don't provide anything to make this possible. Using GCC you could produce relocatable object code, which can be converted into an executable or a library, but this was excluded in the task description. --Oenone 11:51, 10 May 2011 (UTC)

Return to "Executable library" page.