Yura Vishnevskiy wrote:
> debug: file=/usr/sfw/lib/gcc/i386-pc-solaris2.11/3.4.3/crtbegin.o [ ET_REL ]
> debug:
> debug:
> file=/export/home/yura/Projects/MYPROJ/dev/trunk/build/solaris-gcc-x86-i686/Debug/apr/lib/libapr-1.so
> [ ET_DYN ]
> debug:
> debug:
> file=/export/home/yura/Projects/MYPROJ/dev/trunk/build/solaris-gcc-x86-i686/Debug/apr-util/lib/libaprutil-1.so
> [ ET_DYN ]
> debug:
> debug:
> file=/export/home/yura/Projects/MYPROJ/dev/trunk/build/solaris-gcc-x86-i686/Debug/expat/lib/libexpat.so
> [ ET_DYN ]
> .....
> In my custom dirs apr/lib, aprutil/lib and expat/lib I have both shared and
> static libs and it seems that linker prefers shared libs.
Yes, you've picked up the shared objects ("ET_DYN").
Under the "-lx" option, ld(1) first searches for libx.so and if that can't be
found, searches for libx.a in the same directory.
Set LD_OPTIONS=-Dargs,files. The diagnostics will verify what arguments are
used, and will show where on the command-line ld(1) processes them. It's
another alternative to the truss experiment.
Andrew has figured it out though, -Bstatic isn't being passed to ld(1).
The question about --whole-archive use is valid too. The whole point of
archives is to selectively extract members, if you're going to extract them
all, why not build apr-1.o etc, and just link in the one object? But then,
why not use shared objects in the first place? :-)
--
Rod.
