> Well, I should better say:
> In general, pic-code is faster for shared libraries, because
> the dynamic linker doesn't need to resolve all the relocations
> every time the program is run, and the library code can be shared
> between several processes, which saves memory (and is the purpose of
> shared libraries). So, why not simply link against the static library?
1) Because then you have to relink every time you rebuild mesa.
2) Because there are a whole bunch of demos - I challenge you to link them all
static - you'll either get bored waiting, or run out of disk space.
3) Because you can't link proprietry code static.
4) Because the existing system lets you do it.
This isn't an autoconf restriction - the g200 group build a non-PIC version of
their stuff via. autoconf.
> > It is possible to build a non-pic .so which is much more convient than
> > linking to a static library --
>
> That's not portable (trust me, I'm libtool maintainer).
> Why is linking against a static library less convenient?
Well if there are systems which can't do it, don't offer the option on those
systems. We shouldn't punish those that can for the sake of the others.
More to the point - people (like me) will do it anyway. If your autoconf scripts
don't handle it, they won't use your scripts.
> > you can't say './linuxquake3 +set r_glDriver libGL.a', for instance.
>
> Josh didn't say that he wants to use it as a loadable driver.
Well, I'm saying it.
Keith
_______________________________________________
Mesa-dev maillist - [EMAIL PROTECTED]
http://lists.mesa3d.org/mailman/listinfo/mesa-dev
