| 1 |
Quoth He: |
| 2 |
> I went with uClibc |
| 3 |
> because it appeared to support more of the applications that I needed to |
| 4 |
> use. |
| 5 |
|
| 6 |
I agree - the advantage to uClibc is that its developers took a great deal |
| 7 |
of trouble to maintain as much interface compatibility with glibc - a |
| 8 |
great advantage for porting code (quite often, code will recompile with no |
| 9 |
changes). |
| 10 |
|
| 11 |
Other libraries that sacrifice compatibility for (usually) space are |
| 12 |
useful for special purposes - for example, if you are only going to be |
| 13 |
using a small subset of the C libraries for a particular project. |
| 14 |
|
| 15 |
My sense is that we are going with a general-purpose embedded development |
| 16 |
environment, and thus cannot predict what library features will be needed, |
| 17 |
thus I think that uClibc would be the best way to go - at least for the |
| 18 |
outset. This is not saying that we shouldn't explore optionally making |
| 19 |
other libraries available, but its probably best to not stir up to much |
| 20 |
complexity before we even have a working preliminary build. |
| 21 |
|
| 22 |
|
| 23 |
-- |
| 24 |
---------------------------------- |
| 25 |
aja@×××××××××××××.com |
| 26 |
www.clanarmstrong.com |
| 27 |
|
| 28 |
qui tacet consentire videtur |
| 29 |
|
| 30 |
|
| 31 |
|
| 32 |
-- |
| 33 |
gentoo-embedded@g.o mailing list |
Archives