Re: [dev] stali and static surf binary

On 16 May 2010 02:09, Ersin Akinci <ersin.akinci_AT_gmail.com> wrote:
> You're correct, my intentions are quite different and have nothing at all to
> do with performance concerns.  I'm trying to manifest a certain aesthetic
> vision: I like the act of downloading static binaries and deleting them
> without worrying about dependencies, complicated directory structures, etc.
> stali's web page also implies that the goal isn't just completely focused on
> performance, especially when you read the proposed directory structure
> (i.e., "/proc: linux stuff").
>
> Heh, yeah dillo would work, but really dillo isn't a solution.  It's
> admirable for what it is, but I need a full-featured, statically linked
> browser.  I figured that if anyone would know how to do that it would be the
> stali dev(s).  No idea if it's being actively maintained or not.

I'll share the state I've got soon. In my impression the real pain is
GNU autoconf and libtool that never really work to produce static libs
instead of shared libs + shared stubs. Hence my approach is ignoring
all existing build systems and writing mkfile's from scratch based on
example runs of the configure toolchain (like in WebKit I run the
normal process to get DerivedSources first) and then running mk on all
source files I determined which results in a static libWebKit.a that
contains everything. If also all dependencies have been build
similarly you will get quite far, though you will also need dlopen
support unfortunately in case of WebKit; at least for plugins, but of
course you can link that in from a static eglibc and hope it will be
supported in a similar fashion. The absolute hardcore solution would
be hacking dlopen to be a dummy and link all plugins into libWebKit.a
that you are going to use (then you need some binary magic though in
renaming NP entrypoints for each plugin and dealing with those in
dlsym).

Cheers,
Anselm
Received on Mon May 17 2010 - 07:55:11 UTC