On 10/01/2013 10:11:03 PM, Andrew Bradford wrote:
On 07/18/13 15:11, Andrew Bradford wrote:
> On Mon, Jul 15, 2013, at 08:15 AM, Andrew Bradford wrote:
>> I've not done any testing yet but I have a branch that uses EGLIBC
>> instead of uClibc for the embedded book. If anyone wants to give
it a
>> whirl and let me know what issues you find, that'd be awesome!
>>
>> I'll be doing some testing real soon now.
>>
>> https://github.com/bradfa/clfs-embedded/tree/eglibc-n-headers
That branch is a dead end but the concept is living on again for me!
> So I'm giving up on EGLIBC or glibc. They're both huge and that's
not
> really in line with the goals of the embedded book. For now uClibc
> makes the most sense but I'm not completely ruling out musl-libc
until I
> try it at least once.
glibc isn't as horrible as first thought, size wise. It's still not
as
small as uClibc can be or as musl is, but that's OK I think as the
overhead of configuring it is very low and binutils + gcc don't need
any
special patches to support it. Low overhead and straight forward
configuration win in my mind, still.
One of the things that attracts me to uClibc and musl is you don't need
perl as a build prerequisite for either. I pushed patches upstream to
linux to take out the perl build prerequisite that appeared in 2.6.25
(as of 3.10 or so it's gone away again), so if you're using a libc
other than glibc, perl can move from LFS to BLFS.
Also, size isn't my only criteria, I like the simplicity of musl. If
somebody wants to security audit their system, it's a lot easier to
read through the whole of musl than to read and understand all the
glibc code. (uClibc... less so than it used to be.)
Rob
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
