pkgsrc-Bugs archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/47187 (net/p5-Net-LibIDN fails to build)
The following reply was made to PR pkg/47187; it has been noted by GNATS.
From: David Holland <dholland-pbugs%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc:
Subject: Re: pkg/47187 (net/p5-Net-LibIDN fails to build)
Date: Sun, 30 Dec 2012 19:19:42 +0000
On Mon, Dec 24, 2012 at 04:25:02AM +0000, David Holland wrote:
> > Perl package contains
> >
> > ldflags='-Wl,-rpath,/usr/pkg/lib -fstack-protector -L/usr/pkg/lib'
> >
> > which is wrong since the build environment is not in and not supposed
> > to be using /usr/pkg. This makes its way to p5-Net-LibIDN, which tries
> > to use it to link test programs, where it's intercepted by the
> > wrappers and removed, so the test programs' rpath ends up not being
> > set at all so they won't run.
> >
> > How it gets this way I dunno.
> >
> > Is this (or something like it) also the problem on dfly?
>
> After discussing this with wiz we concluded that the package should
> not depend on Perl and libidn being installed in the same prefix, so
> the fact that Perl is providing the wrong library path shouldn't be
> allowed to break it.
ok, I figured out what was causing Perl to provide /usr/pkg instead of
$PREFIX, and it's netbsd-specific. Therefore, it can't be the same as
the original problem.
(1) Are you using a non-default $PREFIX?
(2) Does the patch I posted work around your build problem?
(3) Does your Perl package also have wrong stuff in its config? Check
$PREFIX/lib/perl5/5.16.0/<ostype>/Config_heavy.pl, in particular the
value of "ldflags". If so, we need to figure out why.
If the ldflags value is not wrong, does it contain your $PREFIX? If
so, we need to figure out why this info isn't making it to
p5-Net-LibIDN. If not, the Perl folks need to decide if it should or
not and how to get it there.
--
David A. Holland
dholland%netbsd.org@localhost
Home |
Main Index |
Thread Index |
Old Index