Bug #71747 for ExtUtils-MakeMaker: EU:MM_Unix and userelocatableinc

Mon Oct 17 15:04:50 2011 BRICKER [...] cpan.org - Ticket created

CC:	William.Ricker [...] fmr.com
Subject:	EU:MM_Unix and userelocatableinc

I am attempting to build Perl 5.14.2 with userelocatableinc . Trying to build more modules in a temporary DESTDIR fails. Warning: PERL_LIB (../lib/5.14.2) seems not to be a perl library directory (strict.pm not found) at /export/home/a273121/test/perl5/elsewhere/perl/lib/5.14.2/ExtUtils/MM_Unix.pm line 1735. and then tells me Perl arch aix-64int doesn't match Config arch aix-64int (so it's loaded Config ok) but makefile created can't find file or target ../lib/5.14.2/aix-64int/Config.pm I am using userelocatableinc since local IT filesystem convention does not permit applications team supported code in nonvarying FS name like /opt as is norm elsewere. My intent is to use -Dusesitecustomize 's special pl file in final location to patch paths but am using classical ENV After make install DESTDIR=$HOME/test/perl5 for building additional modules (list a bit long to build with perl) I expect setting PATH & PERLLIB at shell export env to give me a temporarily working perl for running cpanp to build DBI, Ack, etc before bundling for distribution. MM_Unix diagnostics and path analysis defeat cpan shell, cpanp shell, and manual wget/tar/perl Makefile.PL . Attached find output from Makefile.PL (in HTTP-Tiny Dist) with Perl -V also attached. Similar results occur with CPAN shell invoked from Perl build-extras and cpan or cpanp shell from shell. Maybe I just need better docs on how to *use* a perl built -Duserelocatableinc -- i will try sitecustomize.pl -- but not being able to use build-extra-modules -Duserelocatableinc with Perl is an issue somewhere. I'm only rating this Normal as it's only critical to the few of us trying -Duserelocatableinc (for which I was one of the original requestors back in 5.8.8 timeframe, for this very use-case). The cc: email is $DayJob where this build lives. Thanks Bill Ricker aka N1VUX aka William.Ricker@fmr.com

Subject:

ExUtilFAIL.txt

cd HTTP-Tiny-0.013 PERL514 $ perl Makefile.PL Checking if your kit is complete... Looks good Warning: PERL_LIB (../lib/5.14.2) seems not to be a perl library directory (strict.pm not found) at /export/home/a273121/test/perl5/elsewhere/perl/lib/5.14.2/ExtUtils/MM_Unix.pm line 1735. Have /export/home/a273121/test/perl5/elsewhere/perl/lib/5.14.2/aix-64int Want ../lib/5.14.2/aix-64int Your perl and your Config.pm seem to have different ideas about the architecture they are running on. Perl thinks: [aix-64int] Config says: [aix-64int] This may or may not cause problems. Please check your installation of perl if you have problems building this extension. Writing Makefile for HTTP::Tiny Writing MYMETA.yml PERL514 $ PERL514 $ make make: Cannot find a rule to create target ../lib/5.14.2/aix-64int/Config.pm from dependencies. Stop.

Subject:

perl.cfg

Download perl.cfg
application/octet-stream 2.2k

Message body not shown because it is not plain text.

Mon Oct 17 18:20:57 2011 BRICKER [...] cpan.org - Correspondence added

RT-Send-CC:

William.Ricker [...] fmr.com

Ignore first perl.cfg uploaded, that was from wrong path and sees vendor 5.8.8 :-( (For some reason Reply to Requestors is the Update type; this is actually a requestor update to report)

Subject:

perl.cfg

Download perl.cfg
application/octet-stream 3.2k

Message body not shown because it is not plain text.

Mon Oct 17 18:21:07 2011 BRICKER [...] cpan.org - Status changed from 'new' to 'open'

Wed Oct 19 17:56:37 2011 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #71747] EU:MM_Unix and userelocatableinc
Date:	Wed, 19 Oct 2011 14:56:26 -0700
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

On 2011.10.17 12:04 PM, William D (Bill) Ricker via RT wrote: Show quoted text

> I am attempting to build Perl 5.14.2 with userelocatableinc . > Trying to build more modules in a temporary DESTDIR fails. > > Warning: PERL_LIB (../lib/5.14.2) seems not to be a perl library directory > (strict.pm not found) at > /export/home/a273121/test/perl5/elsewhere/perl/lib/5.14.2/ExtUtils/MM_Unix.pm > line 1735. > and then tells me Perl arch aix-64int doesn't match Config arch > aix-64int (so it's loaded Config ok) but makefile created can't find > file or target ../lib/5.14.2/aix-64int/Config.pm

Short version: Unset PERLLIB. (And don't download CPAN modules into your perl directory.) You should not need PERLLIB set to point at the Perl library paths. It's redundant, perl should take care of that for you. That's the point of userelocatbleinc. This one took some puzzling, I don't run userelocatableinc and had to try it out for myself. If I'm correct you have PERLLIB set to replicate the location of Perl libraries? And you unpacked HTTP-Tiny into /export/home/a273121/test/perl5/elsewhere/perl/HTTP-Tiny? Those two things will confuse MakeMaker as to which Config.pm perl has loaded. We had issues with the architecture check in the past. The purpose is both to check that you've loaded the Config.pm for your perl binary and not some other... or to check that the loaded Config.pm matches the architecture of your perl binary. It's not entirely clear which is correct. It currently does the former and reports the latter. :-/ I believe it's getting confused because it doesn't realize that /export/home/a273121/test/perl5/elsewhere/perl/lib/5.14.2/aix-64int and ../lib/5.14.2/aix-64int are the same directory. That could be made smarter, but having a redundant PERLLIB will bang into something else down the line. Please let me know how it works out. -- 60. "The Giant Space Ants" are not at the top of my chain of command. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/

Wed Oct 19 17:59:24 2011 mschwern [...] cpan.org - Status changed from 'open' to 'stalled'

Wed Oct 19 23:03:10 2011 bill.n1vux [...] gmail.com - Correspondence added

CC:	BRICKER [...] cpan.org, William.Ricker [...] fmr.com
Subject:	Re: [rt.cpan.org #71747] EU:MM_Unix and userelocatableinc
Date:	Wed, 19 Oct 2011 23:02:42 -0400
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Bill Ricker <bill.n1vux [...] gmail.com>

Dear Schwern, I'm moderately sure I tried original userelocatableinc without PERLLIB and it wouldn't even find feature.pm to process -E 'say', let alone build modules. I did not download the cpan module to perl dir. HTTP-Tiny was un-tarred in $HOME. (Not via CPANP since 5.14.2 bundles cpanp that prefers Tiny but a Tiny that doesn't do http_proxy. My $DayJob firewall is finicky, robotic FTP usually won't go.) I had same or similar MM-Unix error message when Perl 5.14.2 Build had Configure specified to do extra modules . I get the feeling userelocatableinc isn't much used, not much discussion on-line. (If $DayJob's core IT let me package a divisional perl for deploy to /opt/$div/perl5$nn/ and include that in our deploy recipe, life would be so much easier. Coming with the cloud, but that won't help my AIX legacy platforms where DBI code lives.) I'll give it another try. Maybe the problem is deeper than MM-Unix. I agree, I don't expect to need PERLLIB with userelocatableinc. -- Bill Ricker BRICKER@cpan aka n1vux William.Ricker@fmr.com @n1vux bill.n1vux@gmail.com

Wed Oct 19 23:03:12 2011 The RT System itself - Status changed from 'stalled' to 'open'

Thu Oct 20 19:46:06 2011 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #71747] EU:MM_Unix and userelocatableinc
Date:	Thu, 20 Oct 2011 16:45:42 -0700
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

On 2011.10.19 8:03 PM, Bill Ricker via RT wrote: Show quoted text

> I'm moderately sure I tried original userelocatableinc without PERLLIB and > it wouldn't even find feature.pm to process -E 'say', let alone build > modules. > > I did not download the cpan module to perl dir. HTTP-Tiny was un-tarred in > $HOME. > (Not via CPANP since 5.14.2 bundles cpanp that prefers Tiny but a Tiny that > doesn't do http_proxy. My $DayJob firewall is finicky, robotic FTP usually > won't go.)

Hmmm. In that case it's truly odd that you had ../foo paths in @INC. What directory were you in when you ran perl -V to generate perl.cfg? I built my Perl 5.14.2 using the exact same configure arguments you reported, and building HTTP-Tiny from inside the perl install directory with PERLLIB set redundantly was the only way I could trigger the same problem. Maybe you can show me the complete chain of commands to reproduce the problem?

Mon Oct 24 18:09:31 2011 William.Ricker [...] fmr.com - Correspondence added

CC:	"BRICKER [...] cpan.org" <BRICKER [...] cpan.org>
Subject:	RE: [rt.cpan.org #71747] EU:MM_Unix and userelocatableinc
Date:	Mon, 24 Oct 2011 18:08:59 -0400
To:	"bug-ExtUtils-MakeMaker [...] rt.cpan.org" <bug-ExtUtils-MakeMaker [...] rt.cpan.org>
From:	"Ricker, William" <William.Ricker [...] FMR.COM>

Dear Schwern, I'm getting the feeling Userelocatableinc as implemented is useless or insecure, and thus no one uses it nor tests other parts of foodchain with it. (I wonder if it worked right in 5.10.0? I didn't try it then.) I built clean and still run into dead ends when CPANPLUSing modules using EU:MM. -Duserelocatableinc causes build to compile literal ../ into paths in 'perl' executable and stores them in Config.pm too. Supposedly this will get patched at runtime from path to the perl. The built perl can do perl -e 'print 1' perl -v But fails on perl -V perl -E 'say q(hellow world!)' which it can only do if one of -I $DESTDIR/bin $ENV{PERLLIB} cd $DESTDIR/bin is in effect at runtime, to enable it to open feature.pm or Config.pm . Thus the compiled-in @INC of ../lib:$etc are interpreted as relative to $PWD not relative to $DESTDIR/bin (as would be secure and sane). In Configure processing, it looks like it intends to save THREE dots to mean UP FROM PERL BIN not two, but two is what is found. And it isn't interpreted as from-perl. (Sadly sitecustomize.pl isn't usable either, unclear if that's related or not.) On to EU:MM ... Interestingly, the CPAN-shell invoked by -Dextras="JSON::XS" works during make of Perl. But after make install DISTDIR=$elsewhere , EU:MM get confused by compiled in compiled @INC having "../lib". Naturally, with the problem above, one needs one of three workarounds above to get CPAN or CPANPLUS to even run. CPANPLUS of course does a chdir at some point so starting it from $DESTDIR/bin is ineffective. [ERROR] Could not read /export/home/a273121/.cpanplus/5.14.2/build/Digest-SHA-5.62/META.yml: 'Can't locate CPAN/Meta/YAML.pm in @INC (@INC contains: ../lib/site_perl/5.14.2/aix-64int ../lib/site_perl/5.14.2 ../lib/5.14.2/aix-64int ../lib/5.14.2 .) at ../lib/5.14.2/Parse/CPAN/Meta.pm line 110. This affects EU:MM as, of the three workarounds, it's the one that might work for EU:MM's Strict.pm and Config.pm checks, but it can't even get called. (A manual build might work if I unzipped each CPAN tar in bin/.. but that's just unclean, or perhaps in a Build dir containing symbolic links Build/{bin,lib,man} -> $DESTDIR/{bin,lib,man} ?? ) With either the -I workaround (passed in PERL5OPT) or PERLLIB equivalent, EU::MM warns of mismatched Config thusly - Warning: PERL_LIB (../lib/5.14.2) seems not to be a perl library directory (strict.pm not found) at /export/home/a273121/test/perl5/elsewhere/perl/lib/5.14.2/ExtUtils/MM_Unix.pm line 1735. Checking if your kit is complete... Looks good Have /export/home/a273121/test/perl5/elsewhere/perl/lib/5.14.2/aix-64int Want ../lib/5.14.2/aix-64int Your perl and your Config.pm seem to have different ideas about the architecture they are running on. Perl thinks: [aix-64int] Config says: [aix-64int] This may or may not cause problems. Please check your installation of perl if you have problems building this extension. Writing Makefile for Storable and generates a Makefile that fails [ERROR] MAKE failed: No such file or directory make: Cannot find a rule to create target ../lib/5.14.2/aix-64int/Config.pm from dependencies. If the consensus is that userelocatableinc is useless, then there's nothing for EU:MM to fix, and I'll log bug on core's userelocatableinc, reopening my old 5.8 bug to which userelocatableinc was the 'fixed in the next release' answer. If userelocatableinc is considered useful, if one of my workarounds is valid, EU:MM needs to let folks compile modules after "make install DESTDIR=$wherever". (In theory I could list all CPAN I need on 'Configure -Dextras=' but that's monster long , and doesn't allow for updating later, which I want to be able to do.) Tangential : I ran into another issue I should report; it's on building perl on AIX. Is there an RT queue for README.AIX and sibling docs? Or do I just go to bleadperl RT or p5p ? =ignorable [ README.AIX says any IBM C compiler will work if patched (provided choice is compatible with threading desired). This was true for me through make tests. However building cpan modules with XS failed for IBM AIX 'cc'. ParseXS generates C99 syntax that is rejected by IBM 'cc' without specific permissive flags, and Configure did not give 'cc' the right flags to accept them. Adding Configure -Dcc=xlc works. Perl 5.14.2 sources, AIX6.1, IBM cc/xlc v11 patched. I do not know at what compiler version, Configure, or ParseXS version this changed.] =cut Way off topic: Somewhere I still have photos from the night brian d foy passed the shirt he'd bought off your back around the Boston.PM meeting. Next time you're passing near Boston, how about meeting up with Boston.PM for a talk or social ? cheers Bill BRICKER@CPAN n1vux Aka @$DayJob William Ricker Director, Architecture Fidelity Investments / FPCMS Systems, Arch & Data 617-563-0648 / 780-2223 William.Ricker@FMR.com http://www.linkedin.com/in/n1vux

Message body is not shown because sender requested not to inline it.

Mon Oct 24 21:05:31 2011 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #71747] EU:MM_Unix and userelocatableinc
Date:	Mon, 24 Oct 2011 18:05:14 -0700
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

On 2011.10.24 3:09 PM, William.Ricker@fmr.com via RT wrote: Show quoted text

> I'm getting the feeling Userelocatableinc as implemented is useless or insecure, > and thus no one uses it nor tests other parts of foodchain with it. (I wonder > if it worked right in 5.10.0? I didn't try it then.)

https://rt.perl.org/rt3//Public/Bug/Display.html?id=85432 Well look at that, I reported this years ago. :) It seems it works on Linux and BSD, but not OS X or AIX or Solaris if using it from $PATH. I was executing from a full path before, I see your bug now once I've set $PATH. While it's about OS X it could apply to AIX as well. Might want to report this to p5p to make sure they fix it for AIX. It looks like Nick fixed everything but. Try 5.15.4 and see if it's fixed. You could also try convincing p5p that this is important enough to put into 5.14.x. While that's going on, you could try patching 5.14 with his fixes. It looks like they start at 7969fa3ad87a5c1e868e959d5ff214a5a1b2fdab. https://github.com/mirrors/perl/commits/7969fa3ad87a5c1e868e959d5ff214a5a1b2fdab Show quoted text

> If the consensus is that userelocatableinc is useless, then there's nothing for > EU:MM to fix, and I'll log bug on core's userelocatableinc, reopening my old > 5.8 bug to which userelocatableinc was the 'fixed in the next release' answer.

I suspect $(PERLARCHLIB) and friends will be broken as well. Hmm. MakeMaker can certainly detect the problem and fix the broken %Config values. I'm not sure how much effort should be put into this given that Perl is broken in a number of ways on your platform with -Duserelocatableinc. I guess it could be made compatible with your PERL5LIB work around. I don't suppose Fidelity would be interested in sponsoring a fix? PS You could use the old, hacky way to relocate Perl. Essentially you give it a PREFIX of something long and easily identifiable like xxxxxxXXXXxxXXxxxTHISISTHEPREFIXxxxxxxxxXXXXXXXXxxxxxxxxx, install using DESTDIR and then run a s/// over the binaries (making sure to pad with null characters), Config.pm and Config_heavy.pl. ActivePerl used to do this. They have a program for it you can probably get out of older versions of the ActivePerl sources. PPS Another fix would be to write a wrapper which runs Perl with an absolute path and put that in your PATH as perl. Something as simple as: #!/bin/sh /path/to/your/perl "$@" You'd have to write this equivalent in C to make it work in #! Show quoted text

> Tangential : I ran into another issue I should report; it's on building perl on AIX. > Is there an RT queue for README.AIX and sibling docs? Or do I just go to bleadperl > RT or p5p?

I would report it via perlbug or Perl 5's RT. Show quoted text

> Way off topic: Somewhere I still have photos from the night brian d foy passed > the shirt he'd bought off your back around the Boston.PM meeting. Next time

you're Show quoted text

> passing near Boston, how about meeting up with Boston.PM for a talk or social ?

Cool, will do! -- I have a date with some giant cartoon robots and booze.

Mon Oct 24 22:12:48 2011 bill.n1vux [...] gmail.com - Correspondence added

CC:	BRICKER [...] cpan.org, William.Ricker [...] fmr.com
Subject:	Re: [rt.cpan.org #71747] EU:MM_Unix and userelocatableinc
Date:	Mon, 24 Oct 2011 22:12:18 -0400
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Bill Ricker <bill.n1vux [...] gmail.com>

Show quoted text

> https://rt.perl.org/rt3//Public/Bug/Display.html?id=85432 > Well look at that, I reported this years ago. :)

Hah, wonderful. You realize you've just rewarded me for reporting the wrong bug to the wrong team, right ? :-) Show quoted text

> It seems it works on Linux and BSD, but not OS X or AIX or Solaris if using it > from $PATH. I was executing from a full path before, I see your bug now once > I've set $PATH. While it's about OS X it could apply to AIX as well. Might > want to report this to p5p to make sure they fix it for AIX. It looks like > Nick fixed everything but. Try 5.15.4 and see if it's fixed.

Aha. Everyone forgets AIX. Days like this, I wish I could, but it's so very well behaved other times. And a workaround that might even work, call with fullpath. (which alas won't work with #! /usr/bin/env perl ) Show quoted text

> You could also try convincing p5p that this is important enough to put into > 5.14.x.

heh. maybe. Show quoted text

> While that's going on, you could try patching 5.14 with his fixes. > It looks like they start at 7969fa3ad87a5c1e868e959d5ff214a5a1b2fdab. > https://github.com/mirrors/perl/commits/7969fa3ad87a5c1e868e959d5ff214a5a1b2fdab

If I can make it work for AIX that would be amusing. I will have to look closely, I was wondering how this could work ! Show quoted text

> > If the consensus is that userelocatableinc is useless, then there's nothing for > > EU:MM to fix, and I'll log bug on core's userelocatableinc, reopening my old > > 5.8 bug to which userelocatableinc was the 'fixed in the next release' answer.

Show quoted text

> I suspect $(PERLARCHLIB) and friends will be broken as well. Hmm. MakeMaker > can certainly detect the problem and fix the broken %Config values. I'm not > sure how much effort should be put into this given that Perl is broken in a > number of ways on your platform with -Duserelocatableinc. I guess it could be > made compatible with your PERL5LIB work around.

Yeah, doesn't make a lot of sense to 'fix' it to work with borked perl if there's expectation we can make Perl right 'soon'. Show quoted text

> I don't suppose Fidelity > would be interested in sponsoring a fix?

Alas this is for a backwater backoffice, not a big profit center with big consulting budget. Not sure if I can swing a budget on this. But worth a thought, might be worth doing if I can't do it the right way. (Since the whole point of building a current Perl is to load DBI drivers, giving up on CPAN/CPANPLUS is not an option. But Crude hacks to make it relocatable are ok.) Show quoted text

> PS You could use the old, hacky way to relocate Perl. Essentially you give > it a PREFIX of something long and easily identifiable like > xxxxxxXXXXxxXXxxxTHISISTHEPREFIXxxxxxxxxXXXXXXXXxxxxxxxxx, install using > DESTDIR and then run a s/// over the binaries (making sure to pad with null > characters), Config.pm and Config_heavy.pl. ActivePerl used to do this. They > have a program for it you can probably get out of older versions of the > ActivePerl sources.

I made my own version of that years ago, that's how I'd solved the problem caused by filesystem naming convention headbutting Perl previously. I fixed #! 's and maybe a few other hidden spots as well. It blew up when I tried it with 5.12.3 and 5.14.1 when I tried. Not sure what changed, or why it failed. Maybe it was using \0 where not needed (-t $_), or maybe perl has some count/data strings inside now for thread-safety ? Do you anecdotally know if s/// has worked on recent perls? I may well try tweaking my fix-it script again to see if that technique is resurectable. Show quoted text

> PPS Another fix would be to write a wrapper which runs Perl with an absolute > path and put that in your PATH as perl. Something as simple as: > > #!/bin/sh > > /path/to/your/perl "$@" > > You'd have to write this equivalent in C to make it work in #!

hmm that's sneaky, would even work with #! /usr/bin/env perl ... , i like it could even be in same ./bin if my perl binary is renamed perl514 ... I suspect my rusty old-school C skills can handle enough exec\w? to handle a #! worthy wrapper. Could even read an ENV var like $PERLHOME to get the path. But since I do NOT want hard paths in #!, since every copy has different mountpoint according to an internal 'standard' over which I have no control, I can use #! /usr/bin/env perl ... => #! /bin/sh $PERLHOME/bin/perl514 "$*" #REWRITE with hard path or export the variable the #! is satisfied because env is binary . Good old double indirect. Show quoted text

> > Tangential : I ran into another issue I should report; it's on building perl on AIX. > > Is there an RT queue for README.AIX and sibling docs? Or do I just go to bleadperl > > RT or p5p?

> > I would report it via perlbug or Perl 5's RT.

roger wilco Show quoted text

> > Way off topic: Somewhere I still have photos from the night brian d foy passed > > the shirt he'd bought off your back around the Boston.PM meeting. Next time

> you're

> > passing near Boston, how about meeting up with Boston.PM for a talk or social ?

Show quoted text

> Cool, will do!

great Show quoted text

> I have a date with some giant cartoon robots and booze.

I have a date with some swank booze on Friday but no robots. Although there are a couple of robot labs around here ... a old friend said he was switching from doing rocket science (satellite instrument fab) to building his robot minions like a proper mad scientist, when he job hopped recently. :-) Thanks ! -- Bill @n1vux bill.n1vux@gmail.com aka william.ricker@fmr.com BRICKER@cpan

Mon Oct 24 23:45:58 2011 schwern [...] pobox.com - Correspondence added

Subject:	Re: [rt.cpan.org #71747] EU:MM_Unix and userelocatableinc
Date:	Mon, 24 Oct 2011 20:45:42 -0700
To:	bug-ExtUtils-MakeMaker [...] rt.cpan.org
From:	Michael G Schwern <schwern [...] pobox.com>

On 2011.10.24 7:12 PM, Bill Ricker via RT wrote: Show quoted text

>> While that's going on, you could try patching 5.14 with his fixes. >> It looks like they start at 7969fa3ad87a5c1e868e959d5ff214a5a1b2fdab. >> https://github.com/mirrors/perl/commits/7969fa3ad87a5c1e868e959d5ff214a5a1b2fdab

> > If I can make it work for AIX that would be amusing. > I will have to look closely, I was wondering how this could work !

There's some AIX folks on p5p. If you alert them to the problem they can probably work it out. They just need to know the thing to call to get the full path of a running executable. Show quoted text

>> I don't suppose Fidelity >> would be interested in sponsoring a fix?

> > Alas this is for a backwater backoffice, not a big profit center with > big consulting budget. Not sure if I can swing a budget on this. But > worth a thought, might be worth doing if I can't do it the right way.

As much as the money would be nice, it would probably be better giving the money to Nick Clark (or his TPF fund) to fix it properly and either put it into the next 5.14 or give you a 5.14 patch. Show quoted text

> Do you anecdotally know if s/// has worked on recent perls?

No idea. Show quoted text

> Thanks !

You're welcome. I'm going to close this up. Feel free to reopen if you want to go the MakeMaker work around route. Module::Build would probably need fixing, too. It just occurred to me, most of the problems would go away if you hacked Config.pm and Config_heavy.pl to make the relative paths absolute. -- 94. Crucifixes do not ward off officers, and I should not test that. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/

Mon Oct 24 23:46:27 2011 mschwern [...] cpan.org - Status changed from 'open' to 'rejected'