Subject: Re: amd and bfd problem? (linking libs)
To: Chuck McManis <firstname.lastname@example.org>
From: Matt Thomas <email@example.com>
Date: 04/27/2000 10:29:30
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?
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
Matt Thomas Internet: firstname.lastname@example.org
3am Software Foundry WWW URL: http://www.3am-software.com/bio/matt/
Cupertino, CA Disclaimer: I avow all knowledge of this message