pgndev <pgnet....@gmail.com> writes:
> IIUC, -R is a linker option, not a compiler option. LDFLAGS is supposed
> to contain linker flags.
Ugh, I thought that worked. I must be thinking of Solaris. I've always
used LD_RUN_PATH on both Solaris and Linux since I discovered it many
years ago, so I stopped using -R and apparently never tested it on Linux.
I went and looked at the bug report that you pointed to, and I see that it
was a bug in gold. I'm kind of amazed that it's not been fixed yet, but I
guess there's a good reason why Debian still considers gold too
experimental to use and is still using the bfd linker.
Unfortunately, the flags to tell gcc to use the bfd linker are going to
run afoul of the same problem: Automake passes LDFLAGS to the compiler in
link mode, but your Perl is invoking ld directly without using a compiler
driver.
(I now understand why that ssl.m4 bug was affecting you. It wasn't a lack
of transitive library dependencies -- you're on Linux, so that part works
fine. It's that libcrypt couldn't find libssl without an rpath set in the
resulting binary. Which I should have picked up on since you'd said that
it worked if you specified the rpath flags when invoking configure.)
Basically, I think I see how to fix all of the problems that you're having
by using an --enable-rpath option and adding the rpath flags, at least for
Linux, *except* how to get the Perl module to build properly, because I
don't know how to pass the right flags along to the Perl module to set
rpath. It's going to be either -Wl,-rpath or -rpath depending on how Perl
is configured, and I don't see any good way of knowing which. For
example, on my (Debian) system:
windlord:~> perl -MConfig -e 'print $Config{"ld"}, "\n"'
cc
so it will invoke the linker via the compiler, and -rpath will result in
errors (but -Wl,-rpath will work).
I suppose I could do something really ugly and check $Config{'ld'} and see
if it "looks like" a compiler or "looks like" a linker, but ick.
This would work better if the Perl module were completely standalone and
didn't rely on the portability layer in the main package, so that you
could just build it independently. I was meaning to do that but hadn't
gotten to it yet.
--
Russ Allbery <ea...@windlord.stanford.edu>
Technical Lead, ITS Infrastructure Delivery Group, Stanford University
