On Tue, 2003-10-21 at 20:37, Ruben Safir Secretary NYLXS wrote: > > > > If you don't know whether, or where, it's installed, and you don't know how > > to find out, you shouldn't be messing with source installs. You're likely to > > break things. > > > > That's one opinion, but not a good one. There is a huge difference between building an app from source using available system libraries and building a system library. The dependency chains alone dictate that you *must* know what you're doing before you do it. > > Why not show him how to find them? I'm afraid that having a configure script search all over hell for a library (which may or may be the right library) leads exactly to the situation that we all would like to avoid where we have complete DLL hell with the same .dll (but different compiles, glitches, etc) existing in several places. This would be analogous to the DLL hell that currently exists on windows. Also just because a DLL is on the system doesn't mean the linker is going to look at it. How do you propose to solve the problems that will erupt when user's can figure out why the linker isn't seeing their special dll in nonstandard location X. Just because the configure script and the compiler find it doesn't mean the linker will (or should). Furthermore, at the very least you should never look for shared libraries that are outside the scope of the linker's search path. To do so would be disasterous, resulting in further error messages and end user confusion. -- Michael Torrie <torriem@xxxxxxxxxxxx> _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
