Date: Sun, 19 Mar 1995 23:07:06 -0700 From: nate@sneezy.sri.com (Nate Williams) To: Paul Traina <pst@shockwave.com> Cc: nate@sneezy.sri.com (Nate Williams), 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: <199503200607.XAA06094@trout.sri.MT.net> In-Reply-To: <199503200548.VAA02959@precipice.Shockwave.COM> References: <199503200546.WAA06018@trout.sri.MT.net> <199503200548.VAA02959@precipice.Shockwave.COM>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199503200607.XAA06094>