http://qs1969.pair.com?node_id=615871


in reply to Compiling C/C++ based Modules under ActiveState using MinGW

I had problems with the MinGW installer you pointed to (5.0.3); but the latest one (5.1.3) worked o.k.

I encountered an error whilst dmaking a certain module:

Undefined subroutine &main::UpdateHTML_blib called at -e line 1.
(This call is generated by perl Makefile.PL.) The solution is to delete or rename Perl\site\lib\ActivePerl out of the way. The one in Perl\lib is newer, but isn't found due to the order of entries in @INC. (I hit this problem in ActiveState build 819.)

There was another error (or warning): the generated Makefiles call false at least once, but the MinGW installation doesn't include this executable. However, this error can be ignored, AFAICT.

Also, heed the admonition to run dmake -S -S if you receive it.

I think it would helpful if you'd mention what values you put in dmake's config.mk file (or any other files), since the dmake documentation doesn't really provide any guidance. I used the following, but I'm really not sure if/why it works:

OS *:= winnt OSRELEASE *:= mingw OSENVIRONMENT *:= gcc

A word spoken in Mind will reach its own level, in the objective world, by its own weight

Replies are listed 'Best First'.
Re^2: Compiling C/C++ based Modules under ActiveState using MinGW
by syphilis (Archbishop) on May 17, 2007 at 03:44 UTC
    I had problems with the MinGW installer you pointed to (5.0.3); but the latest one (5.1.3) worked o.k.

    Oh ... I thought my link was to the latest available .... but apparently not. Can you send me the correct link(s) and I'll amend the post.

    I encountered an error whilst dmaking a certain module

    Which module ? I know I've seen that error, but that's about all I can recall about it.

    The solution is to delete or rename Perl\site\lib\ActivePerl out of the way. The one in Perl\lib is newer ...

    I don't quite follow. What exactly is it in Perl\lib that's "newer" ? Also Perl\site\lib\ActivePerl doesn't exist on build 819 (or 820).

    I can't recall ever seeing any warnings or errors in relation to false - and I've never been asked to run dmake -S -s. (Do you have any further info on these aspects ?)

    I think it would helpful if you'd mention what values you put in dmake's config.mk file (or any other files)

    I've never put anything in dmake's config.mk file (or any other dmake files). All I ever do is place the startup directory and dmake.exe in the same location, and make sure that location is in the path. Perhaps that's what I should have said in my post - instead of referring to the dmake distro's Readme.txt ?

    Thanks for taking the time to raise all of this, btw.

    Cheers,
    Rob
      Can you send me the correct link(s) and I'll amend the post.

      If you do that, it will be out of date soon enough again. Instead, link to MinGW.exe download from SourceForge, which always shows the "current".

      Which module?

      If it mattered, I would have included it. The point is to prepare people for this event regardless of which module they're installing when it happens.

      What exactly is it in Perl\lib that's "newer" ?

      Perl\lib\ActivePerl is newer than Perl\site\lib\ActivePerl.

      Perl\site\lib\ActivePerl doesn't exist on build 819

      Ah, that may be true. It's probably left over from when I upgraded from an earlier build. At any rate, if I had this problem, others may as well.

      Do you have any further info on these aspects?

      Sorry, no. I figured it may not be a usual thing, which is why I said "if you receive it".

      Perhaps that's what I should have said in my post - instead of referring to the dmake distro's Readme.txt?

      Sure.

      Thanks for taking the time to raise all of this, btw.

      My pleasure. Thanks for writing the tutorial in the first place! You saved me (and many others, I'm sure) countless hours of tedious rediscovery.

      A word spoken in Mind will reach its own level, in the objective world, by its own weight
Re^2: Compiling C/C++ based Modules under ActiveState using MinGW
by syphilis (Archbishop) on May 18, 2007 at 01:26 UTC
    Undefined subroutine &main::UpdateHTML_blib called at -e line 1.

    Aaah ... it comes back to me now (with the help of Mr. Google). You would have had exactly the same problem with nmake - and removing Perl\site\lib\ActivePerl will fix that problem, though there may be other issues that need to be dealt with. Build 819 does not have Perl\site\lib\ActivePerl, but earlier builds do. When you install 819 over the top of an earlier build, Perl\site\lib\ActivePerl from that earlier build remains in place - and will be found before 819's Perl\lib\ActivePerl. In this particular instance, the wrong version of DocTools.pm is being loaded.

    Here's a posting from Jan Dubois on the same issue (raised elsewhere):
    -- quote --
    I assume you installed AP819 on top of a previous ActivePerl installation. This is a problem because 819 has all bundled modules installed in the lib tree and not in the site/lib tree. It also changes the order of entries in @INC to put site/lib in front of lib. This allows you to update bundled modules with the new PPM4 and have those new modules override the old ones in lib. If you install on top of an older ActivePerl, then you will have old module versions in site/lib that now shadow the new entries in lib. It would be best to do a clean install of AP819.
    -- end quote --

    I think this is an issue that relates only to build 819 - with build 820 onwards, attempting to install over the top of a pre-819 build is detected and disallowed.

    Cheers,
    Rob