in reply to Building Perl in a Non-standard environment

Try perl -V:.*prefix.* -V:perlpath and see what you get back. If those values aren't correct, it means your Config.pm is messed up, and if you installed perl properly, that shouldn't be the case. ExtUtils::MakeMaker relies, like perl does, on Config.pm containing the correct information.


MJD says you can't just make shit up and expect the computer to know what you mean, retardo!
I run a Win32 PPM repository for perl 5.6x+5.8x. I take requests.
** The Third rule of perl club is a statement of fact: pod is sexy.

Replies are listed 'Best First'.
Re: Re: Building Perl in a Non-standard environment
by comand (Acolyte) on Mar 20, 2003 at 02:50 UTC

    True story - unfortunately, I need a way of overriding where Config.pm (and the perl binary itself) think they are located. The only solution I could find to this was to just install perl into my VOB path, then adding -Dotherlibdirs to point to the perl5/lib and perl5/lib/site_perl directories in /usr/local. Downside is that the @INC path contains directories that will never exist on a target system, but that's minor for me...

    Of course I would prefer a cleaner alternative, and investigated stream editing the perl binary itself to remove a prefix string from all portions of the PERLLIB encoded in there. I can do this by hand, but it involves either space padding the beginning or end of the path elements with the same number of spaces as prefix characters removed. This has some strange consequences when modules attempt to use the @INC path, however. The most hardcore of efforts would involve updating the ELF header to account for the missing characters, but let's just say I'm not that motivated :).

    Rgds,
    C.