>> Anything you execute from the command line must have
>> a main(). Your attempt to run without a main() will
>> rightfully fail because the system does not have an
>> address for main() and it will segfault attempting to
>> use some garbage address. OTOH, no shared object should
>> have a main as this would conflict with anything that
>> tried to do a runtime load.
>> If you want to execute foo from a shared object, simply
>> build a program that links to libfoo.so.
> And yet, it is possible to execute /lib/libc.so.6 on Linux.
Yes. It uses the -e linker option to set the entry point.
Quote:> I looked at the symbol table of this shared object and found no
> trace of main.
Executables are usually set up in such a way that the startup code
executes first. The startup code then invokes the runtime linker
(/lib/ld-linux.so.2 on GNU/Linux systems) to load shared libraries,
resolves symbols, and finally calls "main". But there is no require-
ment to link to startup code which does exactly this -- in fact, the
GNU C Library has some code which instead just prints a copyright
notice and then terminates. Of course, it doesn't have to care about
loading the C library to do the printing, because it *is* the C
Quote:> When reading the ld manpage, the -e option is said to specify the
> symbol for beginning execution of the program. In the original
> example, if foo is the entry point, shouldn't it be executed
> regardless of the fact it's a shared object?
It is. The problem is that it cannot call the "write" or "_exit"
functions without first loading the C library and locating the
implementations of these functions.