diff options
Diffstat (limited to 'mdk-stage1/dietlibc/FAQ')
| -rw-r--r-- | mdk-stage1/dietlibc/FAQ | 224 |
1 files changed, 224 insertions, 0 deletions
diff --git a/mdk-stage1/dietlibc/FAQ b/mdk-stage1/dietlibc/FAQ new file mode 100644 index 000000000..d6595dcc9 --- /dev/null +++ b/mdk-stage1/dietlibc/FAQ @@ -0,0 +1,224 @@ +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. |