On 16 May 2010 02:09, Ersin Akinci <ersin.aki...@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
