> Peter Samuelson <pe...@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/
