[dev] sta.li progress

From: Wolf Tivy <wtivy1_AT_my.bcit.ca>
Date: Sat, 09 Oct 2010 14:00:55 -0700

I've been interested in sta.li for a while but luck has been against me.
surf leaks memory or something at maximum speed when I visit the
elevenislouder link on the sta.li website, and hg hangs trying to clone
hg.suckless.org/stali-toolchain. Furthermore, the hg repository hasn't
been touched in 7 months. sta.li is getting unfortunately vapourous.

My fantasy idea of sta.li is simplified archlinux with everything static,
9base>BSD>GNU and no /usr. I happen to like udev hotplugging and
such so I'm not so keen on getting rid of all that.

So moving towards that ideal, my first step would be some good
documentation or tools for gettign ABS to build static with bionic or
uClibc or whatever, and then a statically linked pacman repository.
But that's only for the hacked archlinux form of sta.li.

To do anything with sta.li, we need a static toolchain and good
documentation on using it in other systems. So, to my knowledge,
that involves a decent libc, and probably the ld wrapper from project
ideas. Anything else?

Is the ld wrapper as simple as it sounds? Is it just just sneaking
foo.a out the back door when asked to build foo.so and then sneaking
foo.a in the back door when asked to link with foo.so? This is only
needed with retarded build scripts that explicitly check for .so output
right? Someone more skilled than I (possibly me after reading some
docs) could write a script to do that pretty easily I think.

The libc seems to be mostly a legal and political issue. Aside from
that stuff, what is it that bionic (or whatever) does not do that it needs
to? Or is it just a matter of figuring out and documenting?

tl;dr: What is on the critical path of sta.li that isn't being done, and
how can I help?
Received on Sat Oct 09 2010 - 23:00:55 CEST

This archive was generated by hypermail 2.2.0 : Sat Oct 09 2010 - 23:12:03 CEST