Date: Sun, 19 Mar 1995 22:46:32 -0700 From: nate@sneezy.sri.com (Nate Williams) To: Steven Wallace <swallace@newport.ece.uci.edu> Cc: Paul Traina <pst@shockwave.com>, CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c Message-ID: <199503200546.WAA06018@trout.sri.MT.net> In-Reply-To: <9503200523.AA07989@newport.ece.uci.edu> References: <199503200136.SAA04263@trout.sri.MT.net> <9503200523.AA07989@newport.ece.uci.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
> Why were /usr/local/lib and /usr/X11/lib removed from the standard > search path? Tell me WHY a program should not rely on on a "non-standard" > path for brining in libraries. You say it is "non-standard", but > most BSD machines use /usr/local and /usr/X11R6. Wow now, that's a statement and a half. 'Most' BSD machine probably don't have any libraries in /usr/local/lib, and ALOT of machine don't have X installed on them. Why should we make it the linker search those paths by default instead of them being specified if they don't exist? Secondly, one of the more difficult things that happens is code becomes very FreeBSD-centric, since the writer will not go out of their way to do the right things for other OS's. Try and build most of the software written specificall for Linux and you'll know what I mean. It relies on non-standard behavior of Linux, and will only work on other OS's with heavy-duty Makefile and config file hacking. > What is the matter > with defining this as the default search path, and then if a user wants > to use /opt then they can change that if they want to? Because it's non-standard. > This means programs written for any previous FreeBSD version will not > be able to recompile without modification. They are broken then. I would rather not continue this non-standard behavior here and now, so it doesn't continue on. > Most of the ports will > now have to be updated to reflect this change. Are you willing to > make all the necessary fixes to make ports work with your change? Andreas is doing that now. > Come to think of it, this causes a big ports dillema because now a > port that relies on an installed library will have to assume it is > installed in a specific directory and use an explicit -L/?. Yep. This is the way it's supposed to be done. If we are relying on a different port, then we already know where that library is installed, correct? > Unfortunately, a user may have it installed in a different directory > which will make the port fail. This is avoided by having the standard > search path. If they've installed it somewhere other than the default, then they are facing the same problem now as they would have before. It all goes down to do we want to make people 'Do The Right Thing' and have them add those extra 15 chars to the Makefile so that the code is portable across many different OS's, or make it FreeBSD specific. Most of the programs that this affects are X binaries, and *most* X binaries are built with 'xmkmf' which adds the extra -L$(XROOT) call to the linker. This is how is supposed to be done so the program can compile on many platforms without regard to where the X11 software is installed. When FreeBSD runs on other platforms, the X11 software *may* not be installed in /usr/X11R6, so do we start kludging up the source tree with what is essentially a local configuration issue. Doing the right thing now will save us time in the long run. We know where our pre-built binaries are installed, so we know (as Andreas has already done) where the files are located if the user uses them. Note, the default search path for run-time linking is still correct. The shared libraries will be found where they are installed, so it's a non issue once the program is installed. Finally, for *most* folks they install the pre-built binaries. They couldn't care less *how* a binary was built, just as long as it works. Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503200546.WAA06018>