Text 1973, 135 rader
Skriven 2011-11-29 19:50:33 av Ben Morrow
Ärende: Re: Problem configuring OS/2 for installing CPAN packages
=================================================================
sv3-kNjiwCJ6tiMor2Nkfzae2TstW2UdhT6El9s8hkdiRQ5BNsvJuiTAycb+eZ3Uk3Uzt7aJWeuE+XnJlCO!gd2SUIN4Hfs3b9e5qtSU95CePx+qfy1NjjubEHHqbAlb58bUKdJwmhnUEmINOIIc6AQjjCi9ulNE!SQ==

properly
comp.os.os2.ecomstation:1129 comp.os.os2.misc:3733
From: Ben Morrow <ben@morrow.me.uk>


Quoth Shmuel (Seymour J.) Metz <spamtrap@library.lspace.org.invalid>:
> In <QIadnRHMSrAkpUnTnZ2dnUVZ8sydnZ2d@bt.com>, on 11/28/2011
>    at 07:43 PM, Ben Morrow <ben@morrow.me.uk> said:
> 
> >Is this a standard OS/2 build of perl from the perl source,
> 
> It's a 5.10.0 build from
> <http://download.smedley.info/perl-5.10.0-os2-20071227.zip>.

OK. That site doesn't seem to say anything about patches applied to
perl, but it does seem to build everything against a libc with some sort
of Cygwin-like Unix emulation layer. Since the perl libraries are
expecting OS/2 to use OS/2 paths (starting with a drive letter) I'm not
sure that is the most helpful thing to do.

> >README.os2 doesn't mention anything about any path remapping.
> 
> I believe that 5.8.0 was the last official OS/2 build. I don't know
> whether the path remapping is something that Paul Smedley or whether
> it was in the source.

When you say 'official' do you mean the builds Ilya used to do? There
are no official binary builds of perl (for any platform): the only
release supported by p5p is the source release. If you were on a Unix
system I would at this point be suggesting you install a proper dev
environment and build perl yourself from the source tarball. I don't
know whether that's something you would be able to do, but IME getting
MakeMaker and the CPAN shell to work with pre-packaged binary builds is
a nightmare. There are just too many details of the build environment to
get wrong.

If you do try to build from source, I don't know if the gcc packages
from Paul Smedley are suitable. I understand building perl on OS/2
requires something called 'EMX', which I presume you have, but those gcc
builds seem to be using an additional emulation layer on top of that.
(In Win32 terms, it seems to me Paul is providing the equivalent of
Cygwin when the equivalent of MinGW would probably be better.)

The rest of this is about trying to fix the installation you've got,
assuming you can't build one that works better.

> >is there some way you can invoke it as /perl5/bin/perl (or whatever
> >the proper path is) instead of Q:\PROGRAMS\PERL\BIN\PERL?
> 
> Q:\PROGRAMS\PERL\BIN\perl.exe is the actual location[1].

I wasn't clear. I realise that the binary is actually in
q:\programs\perl\bin, however there appear to be some parts of the
system that want to call that directory /perl5/bin. Presumably if you
were to type '/perl5/bin/perl' into cmd.exe it would either complain
about a non-existent binary or about the wrong sort of slashes. Do you
have some other shell, built against kLibc, which *will* let you invoke
perl by that path?

(I've no idea if this will make a difference. I am simply mystified as
to where perl got the path Q:\PROGRAMS\PERL\LIB from, and can only
assume it is starting with the path to the invoked binary and working
back from there.)

For reference, what does 'perl -V' give you? Does the @INC list at the
end have paths under q:\programs\perl or under /perl5?

> >Is this the make used to build that copy of perl?
> 
> Probably not. I've got one in U:\extras\bin that may be the one used
> for the build; I'll try it and see what happens.

OK. If your perl is going to write Makefiles with Unix-mapped paths, you
will need a make that understands them. If the Config-editing below
works, you may be able to get perl to write Makefiles with native OS/2
paths, at which point you need to go back to the first make again.

> >....on the other hand, you could try simply editing that copy of
> >Config.pm and globally replacing /perl and /perl5 with
> >Q:/PROGRAMS/PERL.
> 
> I've got files by that name in
<snip>
> Is q:\PROGRAMS\PERL\lib\5.10.0\CPAN\Config.pm the right one?

No. That file is for the module CPAN::Config, which is for CPAN
configuration; what we are talking about here is the module Config,
which is a record of the build-time core perl configuration.

> It
> doesn't contain the string /perl, although these do:
> 
>   q:\Perl\lib\5.8.0\os2\Config.pm

This is left over from a previous installation of perl?

>   q:\PROGRAMS\PERL\lib\5.10.0\CPANPLUS\Config.pm

This, similarly, is the module CPANPLUS::Config, for configuring
CPANPLUS. You almost certainly don't care about it.

>   q:\PROGRAMS\PERL\lib\5.10.0\os2\Config.pm

This is the file you need to edit; and I've just remembered that Config
uses a delay-loading hack, so you also need to edit

    q:\programs\perl\lib\5.10.0\os2\Config_heavy.pl

(sorry, I should've mentioned that before).

> One of the things that puzzles me is that in 
> 
> >   Perl thinks: [os2]
> >   Config says: [os2]
> 
> the "mismatched" strings are the same.

Yes. That message is extremely unhelpful. The two strings it actually
compared are the 'Have ... expected ...' paths listed on the line before
(which looks to me suspiciously like a debugging statement someone
forgot to take out). It then pulls out the architecture components and
displays them, even if that wasn't the problem.

Unfortunately, MakeMaker is one of the gnarliest parts of the perl
toolchain. Much of it is, frankly, a stinking mess. However, it
(usually) works, and it mustn't be broken, so fixing the mess is slow
and tedious work.

Ben


--- Internet Rex 2.31
 * Origin: The gateway at Omicron Theta (1:261/20.999)