[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: 1.7.0-beta1 up for testing / signing

From: Peter Samuelson <peter_at_p12n.org>
Date: Fri, 15 Jul 2011 10:36:54 -0500

> 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

This is an archived mail posted to the Subversion Dev mailing list.