1 |
The discussion over glibc vs. uClibc is very important because every |
2 |
system really has to be built, tested, and debugged with a specific C |
3 |
library in mind. Fundimental functions like malloc() are sometimes |
4 |
exhibit slightly different behavior. |
5 |
|
6 |
Many applications and services will not compile against uClibc becuase |
7 |
simply does not provide many of the functions that glibc does.(1) The |
8 |
reason for this is because uClibc focuses on C89, C99, and SUSv3 (Single |
9 |
UNIX Specification 3) compatibility, but not full compatibility with |
10 |
glibc.(2) The selection of Diet libc is even more troublesome because it |
11 |
is targets the development of binaries that are statically linked.(3) |
12 |
|
13 |
I would argue that building a hardened platform requres the |
14 |
standardization of basic programming libraries. Otherwise our motto will |
15 |
be "it should work with whatever library you choose". Embedded sytems |
16 |
such as routers fit into the mission critical category. On the other |
17 |
hand, if someone's PDA freezes up once every 6 months nobody's going to |
18 |
care. |
19 |
|
20 |
References: |
21 |
(1) www.kernel.org/pub/linux/libs/uclibc/Glibc_vs_uClibc_Differences.txt |
22 |
(2) Building Embedded Linux Systems (O'Reilly), p.134 |
23 |
(3) Building Embedded Linux Systems (O'Reilly), p.139 |
24 |
|
25 |
Eric Radman |
26 |
|
27 |
On Fri, 2003-11-07 at 02:45, Seemant Kulleen wrote: |
28 |
> Well, look, we've had glibc (not sure if uclibc and dietlibc do yet), |
29 |
> PROVIDE a virtual/glibc (though, to be completely correct, it should |
30 |
> just be virtual/libc, but let's leave that aside). So this argument is |
31 |
> just an argument. The point of a virtual is that the user has the |
32 |
> ultimate choice to decide who satisfies the virtual. Why don't we just |
33 |
> leave it at that and move on |
34 |
|
35 |
|
36 |
-- |
37 |
gentoo-embedded@g.o mailing list |