[uClibc] cc and libc linkage

[Bennett Todd]

2004-02-12T09:28:22 Anders Eriksson:
> The compiler needs to know how to generate code to call in and
> out to/from a library. [...] The compiler doesn't need to know
> anything specific about the libs to do that, does it?

Sure it does.

	#include <stdio.h>
	int main(int argc, char **argv) {
	    (void) fprintf(stdout, "Hello, world\n");
	    return 0;
	}

To generate that call to fprintf, the compiler needs to know where
this particular libc implementation keeps stdout, a FILE *.
Different libcs can and do have different answers to that question;
the libc implementation communicates these details to the compiler
through the contents of stdio.h (and/or other headers which stdio.h
includes, recursively).

"cc" has to know where to find the stdio.h that goes with the
library you're using. The default answer to this is /usr/include, it
can be overridden as is done by dietlibc's "diet" wrapper/driver.

> The opaque objects are passed as pointers to more or less fancy
> structs and arrays, right? If so, the compiler wouldn't need to know
> the details of those objects (the caller and callee would have to
> agree of course). Or does the compiler need to be FILE aware for some
> reason?

The compiler could be allowed to be blind to the internals of a
struct FILE, and things could still work. Traditionally this isn't
done. But a libc is still obliged to publish other info back to the
compiler via header files --- BUFSIZ, any number of flag #defines,
etc.

> The pre-created FILE * handles are a bit trickier though. Can they
> be regarded as a set of global objects which could have resulted
> from a init_libc() call right at the top of main()?

They could be so regarded, but it turns out that's not the standard
interface contract between a libc and the compiler. Instead, a
matched set of header files publishes this info.

> Given the mout of trouble people have gone through to get other
> libc's to play nicely with gcc I feel there must be more to it
> than that...

There are two issues that I know of that can come up when doing an
alternative libc, that can effect how it interacts with gcc.

(1) gcc needs to be told to use this library's header files and
    libraries for building programs. It knows how to do this for a
    system's native library; it can be told how for non-native
    add-on libraries.

(2) If you wish to use a library as the primary, native library for
    a distro, then in addition you'll be wanting to make sure that
    library delivers a sufficiently complete implementation of
    "libc" to satisfy all the needs of gcc itself. Happily, uClibc
    is there.

> I know of the path circus. But tweaking the paths to include files
> (which really are parameters for the preprocessor, not the compiler)
> could be done on the command line, right?

Yup. That's how dietlibc does it.

> Why is patching the gcc source needed if that is all it takes?

Beats me, I didn't have to patch gcc for that; the only patch I had
to apply for my uClibc-based distro is

<URL:http://www.uclibc.org/cgi-bin/cvsweb/*checkout*/buildroot/sources/gcc-810-libstd++-locale.patch>

which has nothing (that I can see) to do with such paths; instead,
it's hammering on gcc's head where it's getting perhaps
inappropriately intimate with the internals of glibc's locale
support. Incestuous, even.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.busybox.net/pipermail/uclibc/attachments/20040212/17fdf60d/attachment-0002.pgp