Todd Vierling writes:
> On Thu, 22 Apr 1999, Joseph Sarkes wrote:
> 
> : > Also ... make sure you don't have a /usr/lib/libbfd.a or /usr/lib/libbfd.so
> : > (libbfd.so.MAJOR and libbfd.so.MINOR are fine).
> : 
> : That is exactly the place I found my problem. I made a 
> : ln -s /usr/lib/libbfd.so.3.0 /usr/lib/libbfd.so
> : and things started working again.
> 
> You need a /usr/lib/libbfd.so.3, but you need to *remove*
> /usr/lib/libbfd.so.  The bfd-based tools *need* to pull the bfd library out
> of the source tree, not /usr/lib, and the .so (without any numbers) makes it
> look in /usr/lib too, which is wrong.

that sounds like a reasonable idea of how it SHOULD work, but it wasn't
until i put IN the /usr/lib/libbfd.so that it found a useable version.
I think it was using the stuff in /usr/lib anyways and picking the .2 
version vice the .3 version just cause it came earlier. Without the
/usr/lib/libbfd.so symlink it never looked in /usr/obj/whatever first
(nor did it afterwards as it used the newly installed 5x over .3 file
due to the symlink) I'll try playing with it after my current build is
done, as I don't want to screw it up midstream.

Since i reinstalled the /usr/share/mk stuff, includes, libraries, etc.
over and over again, it seems to me there MAY be something broken
here, as I never did get the impression it was looking in the newly
built directory even, without the /usr/lib/libbfd.so symlink. I had
installed the library after rebuilding it a few times, same with 
make clean in the ld.new directory. Shouldn't the system allow the
existance of older shared libraries/earlier versions? And also, does
not the build preferentially use the /usr/src versions of libraries
by placing them earlier in the search path? I did see a -L entry for
the libbfd stuff and kept assuming it would look there first.

> 
> -- 
> -- Todd Vierling (Personal tv@pobox.com; Bus. todd_vierling@xn.xerox.com)
> 


-- 
Joseph Sarkes                   mailto:joe@mediaone.net