dietlibc/FAQ - annotate

Return to FAQ CVS log

Up to [DVB] / dietlibc

Annotation of dietlibc/FAQ, revision 1.35

1.1 fefe 1: diet libc FAQ.
2:
3:
1.18 fefe 4: Q: How do I compile this? I don't see a configure?
1.1 fefe 5: A: Just type make.
6:
7:
1.2 fefe 8: Q: How do I install it? make install?
1.7 fefe 9: A: Yep. It will then install itself to /opt/diet, with the wrapper in
10: /opt/diet/bin/diet. Or you don't install it at all.
11: The diet libc comes with a wrapper called "diet", which can be found
1.16 fefe 12: in bin-$(ARCH)/diet, i.e. bin-i386/diet for most of us. Copy this
1.7 fefe 13: wrapper somewhere in your path (for example ~/bin) and then just
14: compile stuff by prepending diet to the command line, e.g. "diet gcc
15: -pipe -g -o t t.c".
1.2 fefe 16:
17:
18: Q: How do I compile programs using autoconf with the diet libc?
19: A: Set CC in the environment properly. For Bourne Shells:
20:
1.7 fefe 21: $ CC="diet gcc -nostdinc" ./configure --disable-nls
1.2 fefe 22:
23: That should be enough, but you might also want to set
24: --disable-shared and --enable-static for packages using libtool.
25:
26:
1.7 fefe 27: Q: My program complains about missing asm/* or linux/* header files!
28: A: It is quite linux specific. You can try omitting the -nostdinc, but
29: except for some cases conflicts are likely. You should not be using
30: the kernel headers in your software.
31:
32:
1.1 fefe 33: Q: Do you have cross compiling support?
34: A: Yes. Just type something like "make ARCH=arm CROSS=arm-linux- all".
35: For arm, alpha, mips, ppc, sparc and i386, shortcuts exist. You can
1.2 fefe 36: also use "make arm", for example. You still use the same "diet"
37: program as for normal compilation, but you can then say
38:
39: $ diet sparc-linux-gcc -pipe -g -o t t.c
40:
41: Programs using autoconf can be configured like this:
42:
1.18 fefe 43: $ CC="diet sparc-linux-gcc" ./configure --disable-nls
1.2 fefe 44:
1.1 fefe 45:
46: Q: There are a few warnings about possibly uninitialized variables when
47: compiling the diet libc. Can't you remove them?
48: A: This type of warning can only be removed by a) compiling without
49: warnings or b) initializing the variables in question. In all cases,
50: the variables won't actually be used uninitialized, but adding an
51: explicit initializer will add a few bytes of code. As you know, the
52: goal of the diet libc is to not waste a single byte of code, so we
53: don't add initializers ;-)
1.2 fefe 54:
1.1 fefe 55:
1.4 fefe 56: Q: When linking binaries, I get warnings about stdio and printf all the
57: time. What gives?
58: A: Since the diet libc was written to make writing small programs
59: possible, it also tries to assist in the process of seeing causes of
60: bloat. Premier causes for bloat are stdio and the printf family of
61: functions. The diet libc will also warn you if you still use
62: assert() (which is normally not enabled in production code) or if you
63: use functions that use static buffers (like gethostbyname and
64: friends).
1.5 fefe 65:
66:
67: Q: My program stopped parsing command line arguments properly! Now what?
68: A: The getopt in the diet libc adheres to the Single Unix Specification.
69: In particular, it initialized optind to 1 (not 0) and breaks if
70: someone sets optint to 0 (as some misguided legacy programs to).
71: Also, it does not reorder arguments, i.e. something like "rm -f foo -v"
72: will not see -v as option but rather as non-option argument. If you
73: need GNU getopt behaviour, please use GNU getopt instead of the diet
74: libc code.
1.6 fefe 75:
76:
77: Q: I get linker errors about missing __ctype_b!
78: A: This happens when you link in code that was compiled with the glibc
1.7 fefe 79: headers. The most common culprit is a library like -lncurses,
80: -lcrypto or -lresolv. All external libraries you use have to be
81: compiled with the diet libc headers (CC="diet gcc"), and there is no
82: libresolv with the diet libc, it's in the main libc!
1.6 fefe 83:
84:
85: Q: My program links, but when I run it, I get no output at all and it
86: appears to terminate immediately.
1.7 fefe 87: A: This normally happens if you link in glibc. The major reason for
88: this was that shared libraries were linked in. diet sets -static
89: since version 0.13, so if it still happens to you, you need to strace
90: and debug your software.
1.6 fefe 91:
92:
93: Q: Why aren't you compatible to glibc? I thought the interface was a
94: standard?
95: A: Yes, the interface is, but a lot of details are missing. For
96: example, the diet libc uses a different "struct stat" layout than
97: glibc. We use the one from the kernel, glibc uses an own one and
98: links in translation code. This is part of the reason why glibc is
99: so big and ugly. If we support all of this, we end up as bloated as
100: glibc.
1.7 fefe 101:
102:
103: Q: Where is the test suite?
104: A: The humble beginnings are in the "test" directory, but it can't be
105: run automatically yet.
1.8 fefe 106:
107:
108: Q: GPL sucks! Now I can't compile my BSD programs with the diet libc!
109: A: Wrong. You can compile them, and you can use them. You just can't
1.32 leitner 110: redistribute the binaries. That said: I will not be sueing anybody
111: for distributing binaries of BSD programs linked against dietlibc, as
112: long as the source code is available somewhere publicly.
1.9 fefe 113:
114:
115: Q: Where are the shared libaries? make install didn't install them!
116: A: You have to explicitly build them with "make dyn". Since they are
117: experimental and only supported on a small subset of the platforms,
118: that is not default. Also, I recommend you only use shared libraries
119: if you really know what you are doing. For example, you can't just
120: use your system shared libraries, because they have a dependency on
121: glibc in them, so the program will crash. And you have to explicitly
122: compile the code with -fPIC or -fpic. You can then use them by
123: substituting "diet-dyn" for "diet" on the command line.
1.10 fefe 124:
125:
126: Q: My target platform does not have a MMU. Should I be using uClibc?
127: A: I am not aware of any issues with MMU-less systems. You should be
128: able to use the diet libc just fine. Having a MMU or not is mostly
129: an issue for the kernel, not libc.
1.11 fefe 130:
131:
132: Q: How do I make myself a cross compiler?
133: A: untar binutils and gcc (I used version 2.11.2 and 3.0.4 respectively)
134: Then use the --target=arm-linux (or whatever platform you want)
135: configure options. For gcc, add --enable-languages=c (otherwise gcc
136: will try to make C++, Objective C and Java, too, and those
137: compilations will fail because they require installed libc headers
138: which you don't have yet). I recommend using --enable-static
139: --disable-shared, too, because otherwise the binutils shared
140: libraries will overwrite each other if you install more than one
141: cross binutils for different targets.
142: binutils$ ./configure --enable-static --disable-shared --prefix=/opt/cross --target=arm-linux
143: gcc$ ./configure --enable-static --disable-shared --prefix=/opt/cross --target=arm-linux --enable-languages=c
144: For some platforms, gcc compilation will fail while trying to compile
145: some part of libgcc.a because it depends on some libc header file.
146: This is a gcc bug and you should complain using gccbug, because you
147: can't cross-compile libc unless you successfully installed the cross
148: compiler.
1.12 fefe 149:
150:
151: Q: Where are the xdr_* symbols?
152: Q: Where are the RPC symbols?
153: Q: util-linux says that rpcgen output does not work?!
154: A: Add -lrpc. The code is from Sun and frankly it is so ugly and so
155: rarely used that I don't want to include it in libc.
156:
157:
1.14 fefe 158: Q: I am missing some BSD/GNU extension!
1.12 fefe 159: A: I started adding a few of them to libcompat. You have to link it in
160: manually, though, as using them is bad for portability and I want
161: people to make a conscious effort to write non-portable applications
162: by not including them in the libc itself.
1.13 fefe 163:
164:
165: Q: I'm just starting with the diet libc. Should I use the tarball or
166: the CVS version?
167: A: Always use the CVS version. We generally don't add unstable test
168: stuff on the CVS tree, and our APIs are stable (they are
169: standardized, remember?). In fact, we don't add much stuff at all.
170: Most changes are bug fixes and optimizations, and in general you'll
171: want those.
1.15 fefe 172:
173:
174: Q: Does the diet libc support profiling (with gprof)?
175: A: There is experimental support for profiling, but so far it only works
176: on x86. To use it, do "make profiling" before make install. Then,
177: diet will link in the support code if it finds a -pg on the gcc
178: command line.
1.17 fefe 179:
180:
181: Q: I get compiler errors in a line with caddr_t, u_long, n_short or
182: nlong or similar.
183: A: Add -D_BSD_SOURCE to the compiler command line. The diet libc tries
184: to encourage portable and standards compliant programming, so it
185: hides these legacy BSD types from the standard name space. The
186: reason is that the Single Unix Specification contains a specification
187: of the socket API but does not mention those types.
188:
189:
190: Q: I get compiler errors in a line with u_int8_t or similar.
191: A: Add -D_GNU_SOURCE to the compiler command line. See previous
192: question. This is a very questionable GNU extension. The C Standard
193: defines uint8_t, uint16_t and uint32_t. Use those instead.
194:
195:
196: Q: Can I compile or use the diet libc with a compiler that is not gcc?
197: A: Compile: no. Use: yes.
198:
199:
200: Q: Can you please port the diet libc to FreeBSD/Solaris/Windows?
201: A: No.
1.18 fefe 202:
203:
204: Q: Why do you support non-embedded platforms like IA64 and x86_64?
205: A: The diet libc is also useful for servers because it can improve
206: performance by an order of magnitude for certain programming models.
207: Please see http://www.fefe.de/fnord/ (in particular .../fnord/SPEED)
208: for an example and/or read http://www.fefe.de/talk.pdf for some
209: benchmarks.
1.19 fefe 210:
1.20 fefe 211:
1.19 fefe 212: Q: I just compiled hello world and the binary is larger than with glibc!
213: A: You forgot to add the dynamic glibc to your size comparison. Please
214: use -static when linking with glibc to see the difference.
1.20 fefe 215:
216:
217: Q: Should I compile my kernel with the diet libc?
218: A: The kernel is not linked against any libc. In fact, the libc is the
219: user space interface to the kernel. So unless you are talking about
220: "user mode linux" (which is a special version of the kernel that
221: happens to be a user space program) you cannot link the kernel
222: against the diet libc. Linking user space Linux with the diet libc
223: should be possible in theory but I don't think anyone has actually
224: tried it.
1.21 leitner 225:
226:
227: Q: I get errors when cross compiling the diet libc with the Hard Hat
228: compiler chain.
229: A: Their compiler and/or binutils is broken. Compile your own. At the
230: time of this writing, I am successfully using gcc 3.1.1 and binutils
231: 2.12.1 to compile the diet libc 0.22.
232:
233:
234: Q: I can't link this software; it uses functions like ftok and cuserid.
235: A: Some obsolete and/or questionable functions have been put into
236: libcompat.a to quarantine them away. If your software uses these
237: functions, it is broken. Please go through the code and replace
238: these functions with their POSIX counterparts or get rid of it
239: altogether.
1.22 leitner 240:
241:
242: Q: Compiling software with "diet -Os gcc..." gives error messages about
243: -malign-loops, -malign-jumps and -malign-functions being obsolete.
1.27 leitner 244: A: UPDATE: the defaults have been changed as of 2005-04-23.
245: diet -Os uses some platform dependant gcc options to create tighter
1.22 leitner 246: code. Unfortunately, these options have been renamed on gcc 3. You
247: can fix this by creating a file ~/.diet/gcc containing this line:
248:
1.33 leitner 249: -Os -fomit-frame-pointer -falign-jumps=1 -falign-loops=1 -mpreferred-stack-boundary=4
1.22 leitner 250:
251: If you get this options not for diet -Os gcc but for diet -Os
252: i386-linux-gcc, put this in ~/.diet/i386-linux-gcc instead.
1.23 leitner 253:
254:
1.27 leitner 255: Q: Compiling software with "diet -Os gcc..." gives error messages about
256: -falign-loops, -falign-jumps and -falign-functions.
257: A: See previous entry for an explanation. You are using gcc 2; please
258: upgrade to gcc 3 or 4. As a workaround, put
259:
260: -Os -fomit-frame-pointer -malign-jumps=1 -malign-loops=1 -mpreferred-stack-boundary=2
261:
262: into ~/.diet/gcc.
263:
264:
1.23 leitner 265: Q: I see lots of uninitialized variables, like "static int foo;". What gives?
266: A: "static" global variables are initialized to 0. ANSI C guarantees that.
267: Technically speaking, static variables go into the .bss ELF segment,
268: while "static int foo=0" goes into .data. Because .bss is zero
269: filled by the OS, it does not need to be in the actual binary. So it
270: is in fact better to not initialize static variables if the desired
271: initialization value is 0 anyway. The same is true for pointers, by
272: the way. On all platforms supported by the diet libc, numeric zero
273: is also the pointer value for NULL. So not initializing a static
274: pointer yields NULL.
1.24 leitner 275:
276:
277: Q: My diet libc programs all segfault in User Mode Linux 2.6!
278: A: This is a shortcoming of User Mode Linux.
279: Edit dietfeatures.h, remove the WANT_SYSENTER #define, and then
280: recompile the diet libc and your program. Oh, and bug the user mode
281: linux people about this, it's their fault! ;)
1.26 leitner 282:
283:
284: Q: dietlibc.a does not look so small to me! It's almost 600k!
285: A: Use size(1) to find the real size, like this:
286:
287: $ ls -l bin-i386/dietlibc.a
288: -rw-r--r-- 1 leitner users 597204 Nov 30 16:36 bin-i386/dietlibc.a
289: $ size --totals bin-i386/dietlibc.a
290: text data bss dec hex filename
291: 62 4 0 66 42 unified.o (ex bin-i386/dietlibc.a)
292: [...]
293: 100 0 0 100 64 stackgap.o (ex bin-i386/dietlibc.a)
294: 73908 1163 9298 84369 14991 (TOTALS)
295:
296: "text" is the code in the library, "data" is the variables, "bss" are
297: the constants (string constants, mostly). So there are really only
298: 70k code in the whole library, and you will probably only use a small
299: part of it in your code.
300:
301:
302: Q: I get an error message at link time, that "main" can not be found.
1.30 leitner 303: A: Disable WANT_STACKGAP in dietfeatures.h or try upgrading your binutils.
1.26 leitner 304:
305:
306: Q: I want to have a gcc that uses the diet libc by default.
307: A: You will have to edit the "specs" file from gcc then. John K. Hohm
308: sent these lines to use gcc with the dynamic diet libc (make dyn and
1.35 ! leitner 309: make sure you have WANT_CTOR in dietfeatures.h):
1.26 leitner 310:
311: *endfile:
312: %{shared:dyn_dstop.o%s}%{!shared:%{static:dyn_stop.o%s}%{!static:dyn_dstop.o%s}}
313:
314: *startfile:
315: %{shared:dyn_so_start.o%s}%{!shared:%{static:start.o%s dyn_start.o%s}%{!static:dstart.o%s dyn_dstart.o%s}}
316:
317:
1.29 leitner 318: Q: Dynamically linked binaries don't work on Fedora 6!
319: A: Fedora 6 ships with binutils that can create non-standard ELF
320: binaries, and they hacked their gcc to generate them by default. You
321: can see whether your gcc also does this with
322:
323: gcc -dumpspecs|grep "hash-style=gnu"
324:
325: and you can see if a shared library was build with this flag with
326:
327: readelf -S libname.so|grep GNU_HASH
328:
329: You can override this behavior like this:
330:
331: diet-dyn gcc -Wl,--hash-style=sysv -shared -o libx.so x.c
332: ^^^^^^^^^^^^^^^^^^^^^
333:
1.31 leitner 334:
335: Q: How do I compile OpenSSL with dietlibc?
336: A: Here's how I do it:
337:
338: ./config --prefix=/opt/diet no-dso
339: make libssl.pc openssl.pc
340: for i in libssl.pc openssl.pc Makefile; do (echo ",s/ *-ldl//g"; echo w) | ed $i; done
341: make CC="diet -Os gcc -pipe -nostdinc"
342:
343: Then the libraries go to /opt/diet/lib, so you still need a symlink to
344: lib-i386 or whatever your architecture is.
1.34 leitner 345:
346:
347:
348:
349: Q: My binary segfaults immediately, before reaching main!
350: A: This can be caused by a bug in binutils 2.31.1,
351: if you have thread local storage enabled your dietlibc configuration
352: (that is the default setting). Workaround: Upgrade to more recent
353: version/snapshot of binutils. dietlibc cannot work around this,
354: unfortunately.
355:
356:
357:
358:
359: Q: A binary that used to be 8k is not 17k since I upgraded my binutils!
360: A: To combat side channel attacks such as Spectre,
361: binutils recently (2.31?) introduced a change that would separate rodata
362: and code. rodata used to be mapped as part of the code segment
363: (read-only and executable). Now binutils puts .text on a different page
364: and has a different ELF section. The result is a lot of additional
365: padding bytes that can cause small dietlibc binaries to double or even
366: triple in size.
367:
368: The idea appears to be to prevent Spectre gadgets to be accidentally
369: exposed through the rodata segment. You can turn this behavior off by
370: passing -Wl,-z,noseparate-code to gcc (or -z noseparate-code to ld).
371: Since I'm not sure for how long this option has been there, I'm not
372: passing it in diet as to not break builds on older binutils versions.

LinuxTV legacy CVS <linuxtv.org/cvs>