> Peter Samuelson <peter_at_p12n.org> writes:
> > 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.
[Philip Martin]
> So that removes RPATH from the shared objects in the build dir as
> well as the install dir? Do the tests still work?
Yes and yes, I think. The tests still work because the generated
Makefile sets LD_LIBRARY_PATH to that same long string.
> > 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.)
>
> Since we must have perl
> $(PERL) -pi -e 's/..../'
> should be portable.
Heh, true enough. Anyway, editing a generated Makefile after the fact
seems pretty crude compared to just figuring out why ExtUtil::MakeMaker
puts that line in in the first place, and getting it to not do that.
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Received on 2011-07-15 17:37:38 CEST