At 09:40 AM 4/27/00, Chuck McManis wrote:
>At 07:38 AM 4/27/00 -0700, Matt Thomas wrote:
>>At 11:24 PM 4/26/00, Chuck McManis wrote:
>> >Building -current on the VAX has run into a couple of problem in both EGCS and amd. In both cases there is a library (libbfd in the egcs case and libamu in the amd case) that isn't quite built.
>>
>>I did a complete build a week ago with no errors.
>
>Ok, the only thing that seems to have changed in the last week was 'ld' with the -rpath fix.
>
>> >In both of these cases the Makefile in the library subdirectory has has "MKLINKLIB=no",
>>It there because only the shared version of the library is being made.  Unless you have
>>NOPIC= in your mk.conf, this should not be a problem.
>
>Did you build with objdirs? Can you go back to the obj tree and verify that only libamu_pic and libamu.so, libbfd_pic and libbfd.so exist?

Of course.

matt@fireball> ls obj.vax    
config_local.h  misc_rpc.so     mtabutil.so     umount_fs.so    xdr_func.so
hasmntopt.o     mount_fs.o      nfs_prot_xdr.o  util.o          xutil.o
hasmntopt.so    mount_fs.so     nfs_prot_xdr.so util.so         xutil.so
libamu.so.1.1   mtab.o          tranputil.o     wire.o
libamu_pic.a    mtab.so         tranputil.so    wire.so
misc_rpc.o      mtabutil.o      umount_fs.o     xdr_func.o

libbfd looks the same.
[why is it making .o's?  there's no need to do that.]

>Clearly making _pic the load target is stupid since that leaves the executables as object files rather than programs. I'm guessing egcs is involved again somehow. Sigh.

The problem is that your -L is not picking up the shared shared libraries as it 
should.
-- 
Matt Thomas               Internet:   matt@3am-software.com
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message