There's another way to look at things:
GGI is made to be able to dynamicly load the pieces it needs: memory
layouts, color depths, input devices, display targets, etc. Most
embeded applications know ahead of time what all of these are.
Why can't libggi be built staticly with exactly the driver it needs?
Why should an embeded system have all the code for parsing config files
and trying to decide if it needs to display to X or framebuffer?
If everything is known for the host system then all of the dynamic
configuration code (most being in libgg?) could be excluded. No files
in /etc/ggi should need parsing.
Now, tell me where I'm wrong.
PS. How was vacation, Andreas?
On 23 Aug 2001 23:11:04 +0200, Andreas Beck wrote:
> > > > Do you really mean Debian wants every single LibGGI target, renderer,
> > > > and extension lib all rolled into one .a?
>
> > My thought is that a static library would contain debugging information so
> > that could solve two problems at once. (Or am I wrong here?)
>
> Dynamic libs can also contain debug infos - no problem.
>
> The problem about having a static version of LibGGI is that it will still
> try to dynamically load the .so driver files which are dynamic libraries
> basically.
>
> The only way to really statically link a LibGGI program would be, if all the
> targets would be rolled into the executable and then accessed by a
> table-lookup-call or similar.
>
> LibGGI has been prepared to do this, but noone has yet written the code
> for making up such a table and using it.
>
> It's a lot of work probably for a very rare application.
>
> but if someone likes this challenge, go for it.
>
> CU, Andy
>
> --
> = Andreas Beck | Email : <[EMAIL PROTECTED]> =
--
Thayne Harbaugh
