[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: libraries, packaging and other stuff
Michael Nachbaur wrote:
> > Because I know Svgalib (and now I know enough X11 to be dangerous). And
> > since GGI isn't very popular yet, we would have to link it statically,
> > which isn't very different than what I programmed here (and would
> > probably induce the very same Svgalib linking problem that I am
> > experiencing).
> Well, that is just the very reason for using GGI. You are going through
> hoops to get X11 and svgalib to play nice with eachother. LibGGI is built
> to be crossplatform, including X11 and svgalib. I whipped up a dumb GGI
> program in 5 minutes, and on one compile worked in both X11 and svgalib.
I'm not going through a lot of hoops. It already works in both X11 and
Svgalib. The user who has a problem does not have the prototype version
I have, only the latest release that is a straight Svgalib app. Probable
that if I would have made Quadra a GGI app and compiled statically with
GGI, it wouldn work any better, because now it would be GGI spitting out
crap because it's not able to load Svgalib.
> If you're already statically linking two different libraries, what does it
> matter which one you use? At least you know GGI will work without any
> strange side-effects.
I'm not statically linking to libX11.so or libvga.so. It is particularly
evil to statically link libvga.so, as its the library that contains the
video drivers for Svgalib.
Dynamically linking to libX11.so or libvga.so is acceptable, because
those are well-known libraries that just about every distribution
includes, where dynamically linking to GGI would require us to package
GGI or tell users to get it and it's just making things difficult for
users ("oh, I don't have this libggi.so thingy. I'll just forget about
the thing" followed by "rm quadra.rpm").
Ludus Design, http://ludusdesign.com/
"First they ignore you. Then they laugh at you.
Then they fight you. Then you win." -- Gandhi