Re: Bug#534398: ITP: libposix -- unifed implementation of core functionality of all Unix systems
On Wed, Jun 24, 2009 at 6:24 PM, Guus Sliepen<guus@debian.org> wrote:
> On Wed, Jun 24, 2009 at 05:47:16PM -0400, Steve Langasek wrote:
>
>> > Once libposix reaches maturity, I will certainly consider linking
>> > applications I wrote myself against libposix. Applications linked against
>> > it will probably use less memory
>>
>> Why would they use less memory?
>
> Since they don't link against a large library. Granted, that is only a benefit
> if all running programs link against libposix instead of glibc.
What makes you think libposix will be smaller? It is currently very
incomplete; by the time it reaches a full implementation of POSIX, it
may well be the same size as libc.
>> > and will also make it easier to run things on embedded platforms.
>>
>> Why does this make anything easier? If you're rebuilding your whole system
>> against libposix, you're not doing that in the archive, so packaging
>> libposix seems largely irrelevant to this; if you aren't rebuilding your
>> whole system against libposix, you get two libcs, so that's hardly a win for
>> embedded systems.
>
> If I'm compiling I'd rather do it on a fast desktop with all my usual stuff
> installed than on an embedded system.
Again, this is what a cross-compile toolchain is for (mandatory if
your embedded platform is anything other than your desktop arch!). You
could adapt the crosstool buildscripts that uclibc uses, for example.
If you just use debian's normal GCC, you're going to have a hell of a
time convincing it to not use libc's include files/statically-linked
startup objects/dynamic linker.
Reply to: