Re: [dev] How about sta.li ? - libc tangent

On Sun, Aug 1, 2010 at 8:00 PM, Anselm R Garbe <garbeam_AT_gmail.com> wrote:
> On 1 August 2010 12:35, Ethan Grammatikidis <eekee57_AT_fastmail.fm> wrote:
>> On 1 Aug 2010, at 8:43, pancake wrote:
>>
>>> I want to say that in latest glibc (see archlinux) many 9base programs
>>> cant be executed because of being static.
>>
>> I sent the other mail off & then I thought, are you talking about finding a
>> sane libc for any linux, not just sta.li? I've been thinking about it
>> lately, needing to avoid glibc, OS X's libc, and gcc for various reasons
>> including the dynamic linking issue. There are C compilers with the Go
>> distribution which will produce Linux and OS X executables, but no libc, and
>> that started me thinking, specifically with the goal of getting a statically
>> linked p9p on one machine and a completely glibc-free p9p/9base and inferno
>> on another.
>>
>> Perhaps it's a mad thought, but what about building a p9p-alike on top of a
>> modified, ported Plan 9 libc? I expect most of the system calls would pose
>> no more trouble than in p9p. It's work to be done over again, borrowing
>> methods from p9p, but some parts will actually be easier. For example, the
>> Linux kernel's clone system call is far closer to plan 9's fork() than posix
>> threads clone() interface is.
>
> I think one decision in p9p was to provide something considerable
> portable, not just Linux-tight. This decision wasn't bad at all and
> allows to run it on Darwin, many BSDs and some other Unices.

The Go runtime, which produces statically linked binaries which do not
use the system's libc, shows that one can build something that can be
ported to other systems while completely bypassing the system's libc.

uriel

> Anyways I see the point in migrating to a more suitable libc base.
> bionic seems nice and shouldn't be too limited, but it won't be as
> portable as uclibc for instance, which is still my favorite and fairly
> feature complete for what exists.
>
> Cheers,
> Anselm
>
>
Received on Mon Aug 02 2010 - 16:50:29 CEST