[Philip Martin]
> The perl bindings are really confusing. Start from scratch:
>
> configure
> make
> make swig-pl
> make check-swig-pl # PASS
> make clean-swig-pl
> make swig-pl
> make check-swig-pl # FAIL
>
> It was that FAIL after the rebuild that was confusing me. I get the
> same thing in 1.6 so this is not a regression.
>
> So r1037358 is not a problem, it's simply that when I reverted it I also
> manually removed enough of the perl build that my environment got back
> to the state in which the tests would PASS the first time.
Good to hear! I was very very puzzled at what r1037358 had done wrong,
there - I felt some responsibility since it was my patch.
Don't know what to make of 'clean-swig-pl' breaking things. I might
try to reproduce that some time and see if I can figure it out.
> >> $ objdump -x /usr/local/lib/perl/5.10.1/auto/SVN/_Repos/_Repos.so | grep RPATH
> > I think that's been the case for a long time. I actually have a
> > patch in the Debian build specifically to work around this, dating
> > from ages and ages ago.
>
> Should we put this patch into Subversion?
My patch is pretty crude, to Makefile.in:
$(SWIG_PL_DIR)/native/Makefile: $(SWIG_PL_DIR)/native/Makefile.PL
- cd $(SWIG_PL_DIR)/native; $(PERL) Makefile.PL
+ cd $(SWIG_PL_DIR)/native; \
+ $(PERL) Makefile.PL INSTALLDIRS=vendor; \
+ sed -i -e '/^LD_RUN_PATH/s/^/#/' Makefile Makefile.[a-z]*
Basically it comments out the LD_RUN_PATH = ... line from the family of
Makefiles. (Adding 'INSTALLDIRS=vendor' is also needed here, but is
not part of the RPATH fix.) One would think a cleaner solution could
be found, working _with_ ExtUtils::MakeMaker instead of against it.
Besides being crude, it uses sed -i, which works on my platform but is
not portable. (Portable is to redirect sed to a temp file and then
rename it to the original, which here would involve a shell loop.)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on 2011-07-15 16:52:02 CEST