From: Braden M. <br...@en...> - 2003-10-20 20:15:56
|
On Mon, 2003-10-20 at 10:58, Richard Rauch wrote: > On Mon, Oct 20, 2003 at 09:54:03AM -0400, Braden McDaniel wrote: > > On Mon, 2003-10-20 at 07:12, Richard Rauch wrote: > > > On Sun, Oct 19, 2003 at 05:01:46PM -0400, Braden McDaniel wrote: > > > Bulding against -lglut... Oh, well, that's broke. > > > > It's not broken at all. Set -L appropriately for whichever library you > > want, and you're good to go. > > You already have set -L to the /usr/pkg/lib (or wherever your package system > drops libraries) for other things, though. So there is no point in repeating > this option. You aren't accomplishing anything. Yes, you are. You can use -L repeatedly; its effect is cumulative and the order is significant. > Besides which, you can't put both GLUT and freeglut in /usr/pkg/lib/libglut.so. > That simply doesn't work. It would work if you had /usr/pkg/lib/libglut.so > and /usr/pkg/lib/libfreeglut.so, though. That would be simple and direct. Which is why you put them under different prefixes, as I've already described. configure readily supports this (--prefix). > > > How is the .so (.dll) supposed to know which header file you included? > > > > > > Hint: It doesn't. > > > > So what? > > So when someone installs a binary package built against freeglut and it > picks up GLUT at runtime, there's NO way to do anything but fail. Miserably. It'll work just fine if you set LD_LIBRARY_PATH appropriately. [snip] > > > I'd just make freeglut a self-contained library, and let the user decide > > > about "plain glut": Old GLUT, freeglut, or don't bother with "glut" at all > > > and just have "freeglut". > > > > > > > > > But, what you propose would be superior to the current state, so I'd > > > consider it better than what we have. > > > > Why do you think it would be superior? (The overhead of another shared > > library should not be idly dismissed. So I think there'd need to be a > > clear advantage.) > > It would be superior because it would work. It works as it is now. > > > > Kilgard's glut typically lives under the same prefix as GL and GLU, I > > > > don't think there's any reason freeglut must be installed in the same > > > > place. For instance, a user could easily put freeglut under > > > > /opt/freeglut. > > > > > > You mean just different directories? > > > > > > This is not a portable consideration. > > > > Why not? > > Because there is only one /usr/pkg/lib dir, and that's where GLUT already > lives, so freeglut can't be installed. There's nothing magical about /usr/pkg/lib. You can install stuff *anywhere* (that you have write permission, of course). > This may not be a problem on your Red Hat box where they install GLUT in > /lib or whereever. But when you consider portability, you can't assume > that there's an empty spot for "libglut" after GLUT has been installed. There's absolutely nothing nonportable about installing software to an arbitrary prefix. > > > GLUT isn't a core library on many systems. It's an add-on package. > > > > > > And certainly freeglut is going to be an add-on package into the forseeable > > > future. > > > > > > So they will both go into the package system's "lib" directory. > > > > Why? Plenty of stuff that comes with the OS distribution does not. > > Mozilla, for example. Kerberos, for another example (on Red Hat, at > > least; I think Debian is different). > > You have Mozilla in a base OS distribution? It's been part of a number of Linux distributions for some years now. > > > When you consider portability (a claimed aim for freeglut), this simply > > > isn't an option. > > > > Sure it is. > > No. Portability forces you to consider other systems besides your pet. It > has to work not just for you, but for me, for John, etc. You can't make > a decision that only makes sense in your own back yard. You have yet to demonstrate a valid case where portability is compromised. [snip] > > > No, if the programmer really wants old GLUT, then they find *glut*. If they > > > want freeglut, they find *freeglut*. > > > > No, no, no. It must be the user's choice. > > That's ridiculous. If a program is using freeglut extensions, they cannot > possibly use GLUT for it. Which they'll find out if they try to do so; all remains right with the universe. > > > This is not (let me emphasize this: NOT) about creating aliases for freeglut. > > > It is about *distinguishing* two incompatible libraries. > > > > > > It would be foolish to conflate the two, since *glut* doesn't have freeglut > > > extensions, and *freeglut* is still a ways from being GLUT-compatible. (And > > > may never fully bridge that gap.) > > > > Not an issue. If a user tries to build an app that needs freeglut > > extensions against Kilgard's glut, it will fail. > > Not if they have a binary package (which GNU/LINUX users seem to love > so dearly, and which even some NetBSD users use). A binary package should set LD_LIBRARY_PATH appropriately, per the requirements of whatever it was built against. > > > The programmer should just say what they want. I think that you are making > > > a problem out of thin air, here. No one in their right mind should generally > > > say "either GLUT or freeglut, whichever." > > > > Of course they should. > > Only for their own system. Package configuration is a system-specific thing. Binary packages work on systems with near-identical package configurations. > It's foolish otherwise because freeglut is not > GLUT compatible, nor vice versa. They are close, on the subset of features > that GLUT provides, but even there they are far enough apart that it is silly > to want this. I think *you're* being foolish. So there. > > > > want glut and freeglut to coexist on a system should install them to > > > > different prefixes, and build configuration will Just Work provided the > > > > > > THAT is annoying. Automated installs of freeglut/glut can't tell which to do, > > > and there's only one "package" directory to install to. > > > > Not so. See pkg-config. > > Never heard of it, but it seems to have been installed at some point > by my package system. I do not have any ".pc" files, so apparently they > come with packages rather than being held in package systems. How would you > write a .pc file to solve this problem without knowing the target host? Yes, packages install the .pc metadata files. Typically they are generated when a package is configured. > Even if it would work, it seems like you're pulling out heavy artillery > for what can be solved far more simply by simply NOT colliding in the > namespace. Ultimately you can't avoid namespace collisions--creating them is what freeglut is all about. (If not at the header/lib name level, then at the level of exported symbols. IOW, having an app that depends on *both* glut and freeglut is a recipe for disaster, regardless of what the headers and libraries are called.) > How about MS-WINDOWS users? Don't installed DLLs all go into something > like :\WINDOWS\LIBS or some such? They can go anywhere. "System" DLLs typically go in "C:\WINDOWS\System32"; though it's common for apps to put DLLs they need in their directory under "C:\Program Files". As it stands, neither glut nor freeglut is a system fixture on Windows; so each of them can reside anywhere. -- Braden McDaniel e-mail: <br...@en...> <http://endoframe.com> Jabber: <br...@ja...> |