From owner-freebsd-ports Sun Mar 19 22:03:17 1995 Return-Path: ports-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id WAA03298 for ports-outgoing; Sun, 19 Mar 1995 22:03:17 -0800 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id WAA03283; Sun, 19 Mar 1995 22:03:09 -0800 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id XAA06094; Sun, 19 Mar 1995 23:07:06 -0700 Date: Sun, 19 Mar 1995 23:07:06 -0700 Message-Id: <199503200607.XAA06094@trout.sri.MT.net> To: Paul Traina Cc: nate@sneezy.sri.com (Nate Williams), Steven Wallace , CVS-commiters@freefall.cdrom.com, freebsd-ports@FreeBSD.org Subject: Re: cvs commit: src/gnu/usr.bin/ld shlib.c In-Reply-To: <199503200548.VAA02959@precipice.Shockwave.COM> References: <199503200546.WAA06018@trout.sri.MT.net> <199503200548.VAA02959@precipice.Shockwave.COM> Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: ports-owner@FreeBSD.org Precedence: bulk Paul Traina writes: > 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}. Hmm, that's interesting. I've got a Sun box at work, and although I've got lots of libraries I *still* have to specifically add -L/usr/local/lib to them. > 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. Scuse me. We aren't using gcc as a supplemental compiler. It's the *only* compiler on the system and as such everything it uses is installed in /usr. This means it's includes files live in /usr/include, it's libraries live in /usr/lib, and all of it's binaries live in /usr/bin and /usr/libexec. They don't live in /usr/local, UNLESS you decide to install a different version of gcc than the system default version. If you want to install and use gcc1.4, it will install itself and look for it's binaries wherever you want it to. > 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). And those folks have to add a specific -L/usr/local/lib on their boxes for it to work. Either that, or they add it to /usr/local/lib/gcc_2_6.3/sparc-sunos4_1_3_U1/{bin|lib}, which is used because it's a non-standard part of the OS. > > 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. No I'm not. GCC is *NOT* an add-on part of the system. It doesn't have to avoid trying to mess with the standard compiler. That is the reason that gcc looks in /usr/local. As a matter of fact, if you install gcc in /usr/gnu it will only look there, and NOT look in /usr/local. It looks where it's installed, and in FreeBSD it's /usr And, I don't know why we are talking about GCC here. I modified the linker/loader to not look there. What compiler we are using is irrelevant to the issue. > > 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? Uhh, yeah. Everyone send me their root password and machine names so I can go fix the sources on your boxes. Really, that's all I am going to do, nothing more. :-) If the code relies on the linker looking in non-standard directories for it's libraries then it needs to be fixed. > You're fixing something that's not broken. Adding those libraries to the search path is a FreeBSD-specific addition that was made to bootstrap some things early on. However, these changes shouldn't have continued on in the system. The search path is now set to what most system linker/loaders do. (Some of them add all of their other libraries, but since we don't have separated out libraries trees for sys5 libraries and BSD libraries it's a non-issue for us) Nate