stupid_idiot

Group: Members
Posts: 344
Joined: Oct. 2006 |
 |
Posted: July 16 2007,16:20 |
 |
Quote (curaga @ July 16 2007,17:34) | But you didn't say anything about the question of a static uclibc build environment for extensions needing a lot of libs not in core DSL, how about it? |
I would opt for a shared uClibc extension. The size of this extension would (in compressed form) be at most in the ~500K region. This is better than tacking the static uClibc onto every extension, which would swell every extension by a few hundred KB. The only objection I could have would be aesthetic. I mean, two(..?!) parallel libc libraries? The aggravation that people experience at this inelegant solution had better be outweighed by size reductions - which might not be as dramatic as imagined. Conversely, if this works out, it again begs the question - If uClibc is so great, why not use it in core DSL as well? Identity crisis, confusion, etc.
But above all, thank you very much for discussing these things.
UPDATE: Geez, I look at what I posted this morning, and I don't even know what I'm talking about anymore. I was contradicting myself all over the place. It's more interesting to hear what you want to do, instead. Would like to help out in little ways if possible.
|