On 2005-08-30 11:43, Jonathon McKitrick <jcm@FreeBSD-uk.eu.org> wrote:
>On Tue, Aug 30, 2005 at 01:37:02PM +0300, Giorgos Keramidas wrote:
>>On 2005-08-30 04:29, Jonathon McKitrick <jcm@FreeBSD-uk.eu.org> wrote:
>>> I'm doing some experimentation with assembly code based on the int80h.org
>>> tutorials. But since I am going to use malloc and some other functions,
>>> I need to make my code link with libc rather than stand totally on its own.
>>> ld -s -o foo foo.o -lc
>>> leaves 'environ' and '__progname' undefined. What is the correct way to link
>>> standalone asm code with needed libraries?
>> That depends on what the ``standalone'' code contains. If your foo.o
>> object file defines a 'main' function, then you can just use cc(1):
> This is the method I've been using until now. And maybe it's the best one. I
> was just wondering, though, if I want to write an app that is linked to libc,
> but doesn't have 'main', and has '_start' instead, and where I want to use ld
> directly rather than indirectly through cc to link.
That's up to you, really.
Linking to the libc library has both good and bad points.
- You don't need to reinvent the wheel as far as program startup,
cleanup and other useful bits are concerned.
- Since the C library has setup up things for you, you can call all
the known functions that libc or other libraries that use the same
calling conventions support (i.e. any library available on your
- The extra bloat of the C startup/cleanup code.
- When you call into C functions you should follow the C calling
conventions, otherwise the called library functions may break in
I'm sure others can think of more points in support or linking to libc
and against linking to it :-)