diet libc FAQ.


Q: How do I compile this?  I don't see a configure?
A: Just type make.


Q: How do I install it?  make install?
A: Yep.  It will then install itself to /opt/diet, with the wrapper in
   /opt/diet/bin/diet.  Or you don't install it at all.
   The diet libc comes with a wrapper called "diet", which can be found
   in bin-$(ARCH)/diet, i.e.  bin-i386/diet for most of us.  Copy this
   wrapper somewhere in your path (for example ~/bin) and then just
   compile stuff by prepending diet to the command line, e.g. "diet gcc
   -pipe -g -o t t.c".


Q: How do I compile programs using autoconf with the diet libc?
A: Set CC in the environment properly.  For Bourne Shells:

     $ CC="diet gcc -nostdinc" ./configure --disable-nls

   That should be enough, but you might also want to set
   --disable-shared and --enable-static for packages using libtool.


Q: My program complains about missing asm/* or linux/* header files!
A: It is quite linux specific.  You can try omitting the -nostdinc, but
   except for some cases conflicts are likely.  You should not be using
   the kernel headers in your software.


Q: Do you have cross compiling support?
A: Yes.  Just type something like "make ARCH=arm CROSS=arm-linux- all".
   For arm, alpha, mips, ppc, sparc and i386, shortcuts exist.  You can
   also use "make arm", for example.  You still use the same "diet"
   program as for normal compilation, but you can then say

     $ diet sparc-linux-gcc -pipe -g -o t t.c

   Programs using autoconf can be configured like this:

     $ CC="diet sparc-linux-gcc" ./configure --disable-nls


Q: There are a few warnings about possibly uninitialized variables when
   compiling the diet libc.  Can't you remove them?
A: This type of warning can only be removed by a) compiling without
   warnings or b) initializing the variables in question.  In all cases,
   the variables won't actually be used uninitialized, but adding an
   explicit initializer will add a few bytes of code.  As you know, the
   goal of the diet libc is to not waste a single byte of code, so we
   don't add initializers ;-)


Q: When linking binaries, I get warnings about stdio and printf all the
   time.  What gives?
A: Since the diet libc was written to make writing small programs
   possible, it also tries to assist in the process of seeing causes of
   bloat.  Premier causes for bloat are stdio and the printf family of
   functions.  The diet libc will also warn you if you still use
   assert() (which is normally not enabled in production code) or if you
   use functions that use static buffers (like gethostbyname and
   friends).


Q: My program stopped parsing command line arguments properly!  Now what?
A: The getopt in the diet libc adheres to the Single Unix Specification.
   In particular, it initialized optind to 1 (not 0) and breaks if
   someone sets optint to 0 (as some misguided legacy programs to).
   Also, it does not reorder arguments, i.e. something like "rm -f foo -v"
   will not see -v as option but rather as non-option argument.  If you
   need GNU getopt behaviour, please use GNU getopt instead of the diet
   libc code.


Q: I get linker errors about missing __ctype_b!
A: This happens when you link in code that was compiled with the glibc
   headers.  The most common culprit is a library like -lncurses,
   -lcrypto or -lresolv.  All external libraries you use have to be
   compiled with the diet libc headers (CC="diet gcc"), and there is no
   libresolv with the diet libc, it's in the main libc!


Q: My program links, but when I run it, I get no output at all and it
   appears to terminate immediately.
A: This normally happens if you link in glibc.  The major reason for
   this was that shared libraries were linked in.  diet sets -static
   since version 0.13, so if it still happens to you, you need to strace
   and debug your software.


Q: Why aren't you compatible to glibc?  I thought the interface was a
   standard?
A: Yes, the interface is, but a lot of details are missing.  For
   example, the diet libc uses a different "struct stat" layout than
   glibc.  We use the one from the kernel, glibc uses an own one and
   links in translation code.  This is part of the reason why glibc is
   so big and ugly.  If we support all of this, we end up as bloated as
   glibc.


Q: Where is the test suite?
A: The humble beginnings are in the "test" directory, but it can't be
   run automatically yet.


Q: GPL sucks!  Now I can't compile my BSD programs with the diet libc!
A: Wrong.  You can compile them, and you can use them.  You just can't
   redistribute the binaries.  If you are a distribution vendor and want
   to use the diet libc to make BSD licensed binaries for the install
   or rescue floppy which you sell commercially, please talk to me.


Q: Where are the shared libaries?  make install didn't install them!
A: You have to explicitly build them with "make dyn".  Since they are
   experimental and only supported on a small subset of the platforms,
   that is not default.  Also, I recommend you only use shared libraries
   if you really know what you are doing.  For example, you can't just
   use your system shared libraries, because they have a dependency on
   glibc in them, so the program will crash.  And you have to explicitly
   compile the code with -fPIC or -fpic.  You can then use them by
   substituting "diet-dyn" for "diet" on the command line.


Q: My target platform does not have a MMU.  Should I be using uClibc?
A: I am not aware of any issues with MMU-less systems.  You should be
   able to use the diet libc just fine.  Having a MMU or not is mostly
   an issue for the kernel, not libc.


Q: How do I make myself a cross compiler?
A: untar binutils and gcc (I used version 2.11.2 and 3.0.4 respectively)
   Then use the --target=arm-linux (or whatever platform you want)
   configure options.  For gcc, add --enable-languages=c (otherwise gcc
   will try to make C++, Objective C and Java, too, and those
   compilations will fail because they require installed libc headers
   which you don't have yet).  I recommend using --enable-static
   --disable-shared, too, because otherwise the binutils shared
   libraries will overwrite each other if you install more than one
   cross binutils for different targets.
   binutils$ ./configure --enable-static --disable-shared --prefix=/opt/cross --target=arm-linux
   gcc$ ./configure --enable-static --disable-shared --prefix=/opt/cross --target=arm-linux --enable-languages=c
   For some platforms, gcc compilation will fail while trying to compile
   some part of libgcc.a because it depends on some libc header file.
   This is a gcc bug and you should complain using gccbug, because you
   can't cross-compile libc unless you successfully installed the cross
   compiler.


Q: Where are the xdr_* symbols?
Q: Where are the RPC symbols?
Q: util-linux says that rpcgen output does not work?!
A: Add -lrpc.  The code is from Sun and frankly it is so ugly and so
   rarely used that I don't want to include it in libc.


Q: I am missing some BSD/GNU extension!
A: I started adding a few of them to libcompat.  You have to link it in
   manually, though, as using them is bad for portability and I want
   people to make a conscious effort to write non-portable applications
   by not including them in the libc itself.


Q: I'm just starting with the diet libc.  Should I use the tarball or
   the CVS version?
A: Always use the CVS version.  We generally don't add unstable test
   stuff on the CVS tree, and our APIs are stable (they are
   standardized, remember?).  In fact, we don't add much stuff at all.
   Most changes are bug fixes and optimizations, and in general you'll
   want those.


Q: Does the diet libc support profiling (with gprof)?
A: There is experimental support for profiling, but so far it only works
   on x86.  To use it, do "make profiling" before make install.  Then,
   diet will link in the support code if it finds a -pg on the gcc
   command line.


Q: I get compiler errors in a line with caddr_t, u_long, n_short or
   nlong or similar.
A: Add -D_BSD_SOURCE to the compiler command line.  The diet libc tries
   to encourage portable and standards compliant programming, so it
   hides these legacy BSD types from the standard name space.  The
   reason is that the Single Unix Specification contains a specification
   of the socket API but does not mention those types.


Q: I get compiler errors in a line with u_int8_t or similar.
A: Add -D_GNU_SOURCE to the compiler command line.  See previous
   question.  This is a very questionable GNU extension.  The C Standard
   defines uint8_t, uint16_t and uint32_t.  Use those instead.


Q: Can I compile or use the diet libc with a compiler that is not gcc?
A: Compile: no.  Use: yes.


Q: Can you please port the diet libc to FreeBSD/Solaris/Windows?
A: No.


Q: Why do you support non-embedded platforms like IA64 and x86_64?
A: The diet libc is also useful for servers because it can improve
   performance by an order of magnitude for certain programming models.
   Please see http://www.fefe.de/fnord/ (in particular .../fnord/SPEED)
   for an example and/or read http://www.fefe.de/talk.pdf for some
   benchmarks.


Q: I just compiled hello world and the binary is larger than with glibc!
A: You forgot to add the dynamic glibc to your size comparison.  Please
   use -static when linking with glibc to see the difference.


Q: Should I compile my kernel with the diet libc?
A: The kernel is not linked against any libc.  In fact, the libc is the
   user space interface to the kernel.  So unless you are talking about
   "user mode linux" (which is a special version of the kernel that
   happens to be a user space program) you cannot link the kernel
   against the diet libc.  Linking user space Linux with the diet libc
   should be possible in theory but I don't think anyone has actually
   tried it.