in reply to Re: B::Generate for Win32?
in thread B::Generate for Win32?

Set me straight about that error message, "Error: no suitable installation target found for package...".

Given that the ppd contains:

<SOFTPKG NAME="B-Generate" VERSION="0,06,0,0"> <TITLE>B-Generate</TITLE> <ABSTRACT></ABSTRACT> <AUTHOR></AUTHOR> <IMPLEMENTATION> <OS NAME="MSWin32" /> <ARCHITECTURE NAME="MSWin32-x86-multi-thread" /> <CODEBASE HREF="http://ppd.develop-help.com/ppd/data/B-Generate-0.06.t +ar.gz" /> </IMPLEMENTATION> </SOFTPKG>

And my perl installation lists:

P:\test>perl -V Summary of my perl5 (revision 5 version 8 subversion 4) configuration: Platform: osname=MSWin32, osvers=4.0, archname=MSWin32-x86-multi-thread [snip]

PPM is rejecting the install attempt because??

I googled for the error message, and it turns up a lot in questions, but rarely any answers.

When it does receive an answer, it is usually some speculation that "Your ppm installation is broken" or "PPM can't find you perl installation and so doesn't know where to install the package". Both of which are clearly wrong as I can successfully install any number of packages using PPM.

After looking at the ppd's of one or two packages I can install using PPM, I find they tend to look like this:

<SOFTPKG NAME="FFI" VERSION="1,00,0,0"> <TITLE>FFI</TITLE> <ABSTRACT>Foreign Function Interface for Perl</ABSTRACT> <AUTHOR>Paul Moore &lt;gustav@morpheus.demon.co.uk&gt;</AUTHOR> <IMPLEMENTATION> <OS NAME="MSWin32" /> <ARCHITECTURE NAME="MSWin32-x86-multi-thread" /> <CODEBASE HREF="FFI-1.00-PPM.5.6.tar.gz" /> </IMPLEMENTATION> <IMPLEMENTATION> <OS NAME="MSWin32" /> <ARCHITECTURE NAME="MSWin32-x86-multi-thread-5.8" /> <CODEBASE HREF="FFI-1.00-PPM.5.8.tar.gz" /> </IMPLEMENTATION> </SOFTPKG>

Which seems to indicate to me that in .ppds, the architecture name: "MSWin32-x86-multi-thread", really means ""MSWin32-x86-multi-thread-5.6"?

And that despite that Perl (5.8.x) itself lists the architecture as "MSWin32-x86-multi-thread", PPM knows better?

So what that error message ("Error: no suitable installation target found for package...") should really saying is:

"Error: no suitable installation source found for package..."

Or maybe "Error: 'xxxxx.ppd' doesn't contain an installation source for your architecture ('MSWin32-x86-multi-thread-5.8')".


Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon

Replies are listed 'Best First'.
Re^3: B::Generate for Win32?
by PodMaster (Abbot) on Aug 21, 2004 at 21:11 UTC
    Exactly.

    ActiveState completely screwed the pooch.

    MSWin32-x86-multi-thread means for 5.6.x, MSWin32-x86-multi-thread-5.8 means for 5.8.x.

    ActiveState released perl 5.8 with perl-V:archname reporting the same as that for 5.6.x, and nobody noticed for a while because ppm was requesting stuff from the activestate 5.8 repository. When people started adding other repositories a while later, the bug was reported and the brilliant fix was to patch ppm. Config.pm was left untouched, and if you modify Config.pm, you'll break ppm (and maybe MakeMaker or Module::Build, because one/both of them have the same workaround).

    If you have ppm3, you have nothing to worry about, if you have ppm2, you need my patch (7258).

    I've also read (don't recall exactly where) that "Error: no suitable installation target found for package" can also occur if the ppd is some kind of malformed utf8 or something like that.

    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.6.x and 5.8.x -- I take requests (README).
    ** The third rule of perl club is a statement of fact: pod is sexy.

      Okay. One mystery solved. This kinda reminds me of your sig.

      You can't make shit up for your error messages and expect the user to know what you mean retardo!

      But now another mystery to solve. I've seen people (mostly you actually :), talking about ppm2 and ppm3. I don't ever recall having been asked which I want to use, or even being made aware that there are different versions. I just type "ppm".

      P:\test>ppm PPM - Programmer's Package Manager version 3.1. Copyright (c) 2001 ActiveState Corp. All Rights Reserved. ActiveState is a devision of Sophos. Entering interactive shell. Using Term::ReadLine::Stub as readline lib +rary. Type 'help' to get started. ppm> quit P:\test>ppm3 PPM - Programmer's Package Manager version 3.1. Copyright (c) 2001 ActiveState Corp. All Rights Reserved. ActiveState is a devision of Sophos. Entering interactive shell. Using Term::ReadLine::Stub as readline lib +rary. Type 'help' to get started. ppm> quit P:\test>ppm2 Can't locate PPM.pm in @INC (@INC contains: c:/Perl/lib c:/Perl/site/l +ib .) at c:\perl561\bin/ppm2.bat line 21. BEGIN failed--compilation aborted at c:\perl561\bin/ppm2.bat line 21.

      From that, is it safe to assume that:

      1. The PPM I get when I type PPM is indeed v3.1? (or is that version info another red herring? (feeling kippered!)).
      2. I don't need a patch for that. (Or rather, your ppd2 patch won't help me)?

      If, given your detective work above, B::Generate builds elsewhere but not on Win32, then the problem lies not in the module, but in the Module::Build mechanism for Win32?

      I've been trying to work my way through the process, but so far I cannot even drop the warnings level (-W3 to -W2) successfully.

      First, I modified Generate.ccs, but that gets regenerated by the build process. So then I disabled the generation (by temporarially hacking C:\Perl\site\lib\Module\Build\Platform\Windows.pm )

      sub _generic_write_compiler_script { my ($self, %spec) = @_; my $script = File::Spec->catfile( $spec{srcdir}, $spec{basename} . '.ccs' ); $self->add_to_cleanup($script); print "Generating script **DISABLED** '$script'\n"; =disabled open( SCRIPT, ">$script" ) or die( "Could not create script '$script': $!" ); print SCRIPT join( "\n", map { ref $_ ? @{$_} : $_ } grep defined, delete( @spec{ qw(includes cflags optimize defines perlinc) } ) ); close SCRIPT; =cut push @{$spec{includes}}, qq{\@"$script"}; return %spec; }

      But even though I dropped -W3 -> -W2 and removed the (duplicated) -O1 optimisation flag in Generate.ccs

      -nologo -Gf -W2 <<<<<<<<<<<<<<<<< -MD -Zi -DNDEBUG -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_READFIX -MD -Zi -DNDEBUG -I"C:\Perl\lib\CORE" -I"C:\cl\include"

      Something somewhere comes along and sticks these back onto the command line anyway:

      P:\packages\B-Generate-1.06>nmake Microsoft (R) Program Maintenance Utility Version 7.00.9466 Copyright (C) Microsoft Corporation. All rights reserved. c:\Perl\bin\perl.exe Build Generating script **DISABLED** 'lib\B\Generate.ccs' cl -nologo -c @"lib\B\Generate.ccs" -nologo -Gf -W3 -MD -Zi -DNDEBUG - +O1 -DWIN32 -D_CONSOLE -DNO_STRICT -DHAVE_DES_FCRYPT -DNO_HASH_SEED -D +PERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DUSE_PERLIO -DPERL_MSVCRT_ +READFIX -MD -Zi -DNDEBUG -O1 -I"C:\Perl\lib\CORE" -I"C:\cl\include" - +I"C:\hla\include" -I"C:\Perl\lib\CORE" -Fo"lib\B\Generate.obj" "lib\B +\Generate.c" cl : Command line warning D4025 : overriding '/W2' with '/W3' cl : Command line warning D4029 : optimization is not available in the + standard edition compiler Generate.c Generate.xs(102) : warning C4101: 'val' : unreferenced local variable Generate.xs(220) : warning C4101: 'value' : unreferenced local variabl +e Generate.xs(241) : warning C4101: 'value' : unreferenced local variabl +e Generate.xs(463) : warning C4133: '=' : incompatible types - from 'SV +*' to 'B__CV' Generate.xs(617) : warning C4244: '=' : conversion from 'I32' to 'U16' +, possible loss of data Generate.c(883) : warning C4101: 'RETVAL' : unreferenced local variabl +e Generate.xs(638) : warning C4244: '=' : conversion from 'I32' to 'U16' +, possible loss of data Generate.xs(645) : warning C4013: 'fold_constants' undefined; assuming + extern returning int Generate.xs(645) : warning C4047: '=' : 'B__OP' differs in levels of i +ndirection from 'int' Generate.c(914) : warning C4101: 'RETVAL' : unreferenced local variabl +e Generate.c(1482) : warning C4244: '=' : conversion from 'U32' to 'U16' +, possible loss of data Generate.c(1506) : warning C4244: '=' : conversion from 'U32' to 'U16' +, possible loss of data Generate.xs(1037) : error C2106: '=' : left operand must be l-value Generate.c(2007) : warning C4244: '=' : conversion from 'line_t' to 'U +16', possible loss of data error building dll file from 'lib\B\Generate.c' at C:\Perl\site\lib/Mo +dule/Build/Platform/Windows.pm line 106. NMAKE : fatal error U1077: 'c:\Perl\bin\perl.exe' : return code '0x2' Stop. P:\packages\B-Generate-1.06>

      I was kind of hoping to be able to go to p5p with something that actually fixed the problem, or at least narrowed the target area of where to look, but so far (as is all too typical with every attempt I've made to understand this sh...stuff), even the simplest changes to the build process are just impossible.

      Any thoughts or advice welcomed.


      Examine what is said, not who speaks.
      "Efficiency is intelligent laziness." -David Dunham
      "Think for yourself!" - Abigail
      "Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
        Yes, you have ppm3. That's the version not on CPAN. Anyone can get it from http://downloads.activestate.com/PPM/. IIRC, ActivePerl 5.6 originally came with ppm2 (still called it ppm), while ActivePerl 5.8 came with ppm3.
         
        If, given your detective work above, B::Generate builds elsewhere but not on Win32, then the problem lies not in the module, but in the Module::Build mechanism for Win32?
        No, Module::Build is not the problem, and neither is win32. It shouldn't build on any platform ( 'fold_constants' isn't exported anywhere). From what I can tell you'd have to build from the perl (5.8+) source tree (PERL_CORE), and you'd have to link in op.obj, but there is no mention of this anywhere.

        Or, you have to build a perl which exports fold_constants (or Perl_fold_constants).

        Maybe you need to build a new perl? Hmm, yeah, maybe you need to make perl. I can't tell, nor can I test (that part is horribly broken on win32, use of cat everywhere, excedes commandline (i got tons of extensions installed) ... horrible).

        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.6.x and 5.8.x -- I take requests (README).
        ** The third rule of perl club is a statement of fact: pod is sexy.