6/INuEyOtC4oJOfGl8g6/lmVAiVo!C87x3v2clGzXusdjddZpyXIJJo3SZbxxQPg   
   ywcCrYzRcosgK4z2FtiTFhA+zUTrNpmj/m7Fsa/E!mg==   
   properly   
   p.os.os2.ecomstation:1120 comp.os.os2.misc:3731   
   From: Ben Morrow    
      
   [I should say first that I know nothing about OS/2, so I apologise if I   
   end up showing my ignorance...]   
      
   Quoth Shmuel (Seymour J.) Metz :   
   > I'm attempting to install a CPAN package for Perl 5.10 under   
   > eComStation 2.0 GA, a rebranded OS/2. I took the defaults when I ran   
   > 1.1. perl -MCPAN -e "shell". The kLIBC Paths application is mapping   
   > /perl and /perl5 to Q:\PROGRAMS\PERL. I get the following messages.   
      
   Is this a standard OS/2 build of perl from the perl source, or is it a   
   patched version from somewhere else? README.os2 doesn't mention anything   
   about any path remapping.   
      
   >    
   >   [h:\]cdd H:\vendors\cpan\HTML-Tagset-3.20   
   >   [h:\vendors\cpan\html-tagset-3.20]perl Makefile.PL   
   >   Have Q:/PROGRAMS/PERL/LIB/5.10.0/os2/Config.pm expected   
   > /perl5/lib/5.10.0/os2/Config.pm   
      
   The 'Have' path here is the path from @INC perl actually loaded   
   Config.pm from, and the 'expected' is the path where that copy of   
   Config.pm thought it had been installed. They ought to be the same,   
   since the default @INC is compiled into perl at the same time as the   
   installed version of Config.pm is written. (The subsequent message about   
   architectures is unnecessarily confusing, since incorrect arch is only   
   one possible cause of the paths being different.)   
      
   Is your build of perl changing its initial @INC based on the invoked   
   path to the binary? Normally that would only happen if   
      
       perl -V:userelocatableinc   
      
   says 'define', but if your perl's been patched it may do so anyway. If   
   it is, 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? I   
   don't know if CMD understands those remapped paths, so you may have more   
   luck under some sort of kLIBC-compatible shell.   
      
   That should make the warning go away, however...   
      
   >   Your perl and your Config.pm seem to have different ideas about the   
   >   architecture they are running on.   
   >   Perl thinks: [os2]   
   >   Config says: [os2]   
   >   This may or may not cause problems. Please check your installation   
   > of perl   
   >   if you have problems building this extension.   
   >   Note (probably harmless): No library found for -lsocket   
   >   Writing Makefile for HTML::Tagset   
   >   [h:\vendors\cpan\html-tagset-3.20]Q:\moztools\make.exe   
   >   make.exe: *** No rule to make target   
   > `/perl5/lib/5.10.0/os2/Config.pm', needed by `Makefile'.  Stop.   
      
   ...this suggests your make doesn't understand these remapped paths. Is   
   this the make used to build that copy of perl? The 'right' solution here   
   is to get a shell and a make and a perl all built against the same   
   libraries and using the same paths, so if your perl is built against   
   some sort of Unix compatibility layer you need a make that is as well...   
      
   > I assume that I need to edit a configuration file, but I didn't see   
   > anything obvious in the documentation.   
      
   ...on the other hand, you could try simply editing that copy of   
   Config.pm and globally replacing /perl and /perl5 with Q:/PROGRAMS/PERL.   
   (Back it up first, obviously.) If the path mapping is all that's wrong,   
   and the perl binary is happy using native rather than mapped paths, it   
   ought to be OK.   
      
   Ben   
      
      
   --- Internet Rex 2.31   
    * Origin: The gateway at Omicron Theta (1:261/20.999)