nick at ccl4
May 8, 2012, 2:11 AM
Post #3 of 4
On Tue, May 08, 2012 at 10:02:55AM +1000, Tony Cook wrote:
Re: [perl #5844] [5.7.0] PERL5OPT messes with build
[In reply to]
> On Sat, May 05, 2012 at 04:03:17AM -0700, Brian Fraser via RT wrote:
> > On Sun Feb 18 01:05:26 2001, Peter [at] PSDT wrote:
> > >
> > How?
> Anything that loads a non in-lib core module?
> # just an example, Imager isn't suitable for PERL5OPT -M
> $ ./Configure -des -Dusedevel && PERL5OPT=-MImager make -j3
> cc -fstack-protector -L/usr/local/lib -o miniperl \
> perlmini.o opmini.o miniperlmain.o gv.o toke.o perly.o pad.o regcomp.o dump.o util.o mg.o reentr.o mro.o keywords.o hv.o av.o run.o pp_hot.o sv.o pp.o scope.o pp_ctl.o pp_sys.o doop.o doio.o regexec.o utf8.o taint.o deb.o universal.o globals.o perlio.o perlapi.o numeric.o mathoms.o locale.o pp_pack.o pp_sort.o -lnsl -ldl -lm -lcrypt -lutil -lc
> ./miniperl -w -Ilib -MExporter -e '<?>' || make minitest
> Can't locate Imager.pm in @INC (@INC contains: lib .).
> BEGIN failed--compilation aborted.
> Perhaps there's a less ridiculous option that causes a build failure.
Likely. But your example suggests to me that *mini*perl should ignore all of
these, as they aren't* used by the build process, and that the invocations for
./perl should explicitly clear them all.
(Which isn't too hard actually, as ./perl is, or should be, invoked
consistently throughout the Makefile with a macro that sets up
If this idea seems sane, an no-one else beats me to it, I'll try to do it in
the next couple of months.
* I should check this :-)