Re: [dev] sta.li progress

Hi Wolf,

On 9 October 2010 23:00, Wolf Tivy <wtivy1_AT_my.bcit.ca> wrote:
> 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.

unfortunately all sta.li efforts are stalled for quite some time now.
This is mainly related to my relocation to Munich, changing to a new
job and more or less lack of time during the past months. This doesn't
mean that sta.li is dead, I plan to carry on with it in the near
future.

> 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.

The current stage is to re-use arch's bootstrapping in a static way
for the base system, and to add 9base userland optionally on top of
it.

> 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.

That goes further than what I have in mind. There are no plans to
re-use ABS at this point, but rather creating a mk-based ports
collection.

> 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?

We will need uclibc at the least, bionic or dietlibc can be used for
certain tools that don't require a fully fledged libc, but we can't
work around the fact that we will need uclibc.

> 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.

It is just that. Working around stupid autohell scripts. But it's not
for the base system itself.

> 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?

It should be straightforward to use bionic for static linking. Bare in
mind that bionic has several limitations though.

> tl;dr: What is on the critical path of sta.li that isn't being done, and
> how can I help?

Help in the following areas is very welcome:

1. Demonstrate the ldwrapper idea for building webkit

2. Demonstrate stand-alone static binaries that have been linked
against bionic/x86.

3. Develop a mk based ports tree (that contains all optional non-base packages)

I would prefer to focus on the archlinux bits to bootstrap the core
system in a static way.

Cheers,
Anselm
Received on Mon Oct 11 2010 - 10:19:11 CEST