Date: Sun, 19 Mar 1995 21:48:08 -0800 From: Paul Traina <pst@shockwave.com> To: nate@sneezy.sri.com (Nate Williams) Cc: Steven Wallace <swallace@newport.ece.uci.edu>, CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c Message-ID: <199503200548.VAA02959@precipice.Shockwave.COM> In-Reply-To: Your message of "Sun, 19 Mar 1995 22:46:32 MST." <199503200546.WAA06018@trout.sri.MT.net>
next in thread | previous in thread | raw e-mail | index | archive | help
From: nate@sneezy.sri.com (Nate Williams)
Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c
> 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?
I would disagree with you. Every real -development- machine that I have ever
seen has a working /usr/local{/lib}.
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.
Excuse me, but /usr/local/lib is a GCC standard. This change breaks the
way gcc users expect things to operate. You are thinking like the person
who owns the OS, as opposed to thinking of your customers. Lots of folks
like to override system libraries that they use for development by putting
code in /usr/local/lib (e.g. a working libresolv.a on a sun).
> 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.
Again, it's a gcc standard behavior that you are breaking just for FreeBSD.
> 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.
And what about the code that hasn't been submitted for ports? Are you going
to login to everyone's FreeBSD machine and fix their makefiles for them?
You're fixing something that's not broken.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503200548.VAA02959>