in reply to Re^4: DBD:Mysql compilation failed on windows
in thread DBD:Mysql compilation failed on windows

You write: "Our project already using the active perl."

If that is true, then why are you trying to "swim up a waterfall"?
I suspect that "going with the flow" will much easier!
I can think of some reasons why you might want to do what you are doing, but I'd like to hear your reasons "from the horse's mouth".

Your default should be to use the new AS tools to construct your build which will include the Maria DB.

When the PPM (Perl Package Manager) went away, AS (Active State) created a whole new ecosystem on their website. Basically you fork a branch off of one of their standard builds, then add what you want (like the Maria DB), then AS creates a complete .exe or .MSI file for you. This complete customized Perl version then comes to you already built. AS will allow you to re-distribute that installation file to anybody you want - that solves one licensing issue that previously existed.

In a classic, "do as I say, not as I do", I am still using an old AS Perl version because right now, I don't need anything more advanced. And there is some hassle in getting an AS version equivalent to what I have arrived at now with PPM. However, I have in the past built custom Perl versions for other Monks that they have successfully loaded on their machines. So the process does work. AS has sped the compile/build time up considerably - used to take about 20 min - but its a lot faster now.

When you make your build, you should include the cpan module. This includes (like it always has, a complier that is compatible with the rest of the build). Do not try to mix compliers. Including cpan will allow small stuff to be added directly from CPAN without having to go through the entire build process. But it sounds like this DB has enough dependencies etc that you are better off having AS do the build. If the AS GUI allows you to add this package to your new branch, it will build successfully.

As an update: As I remember the first time I used the new tools, it took several hours to arrive at a result. There was a bit of screwing up and redoing things... Also, this new process is still a "work in progress" and AS does make changes to the process. Were I to do it again, it would probably take several hours to figure out exactly what their tool currently does. However, I suspect that you've already spent more than that amount of time already being frustrated! Spend a morning or afternoon and see how it goes...

Updating again to be clear: Instead of just downloading the current AS "default build". Create a user account (its free). Fork a branch, add Maria DB, cpan, and other modules that you want. Have AS build it for you - if I remember right, you get an email when it is ready. I don't know whether your installation was pre or post installation program enhancements. It used to be that you could not just slam a new MSI onto an old installation - in theory you can do that now. But I recommend against that. Uninstall your Perl. Then run your downloaded new MSI containing Maria.

AS (Active State) cpan module comes with the gcc compiler. I suspect that trying to use any other will cause big problems. I actually have the gcc 32 bit C compiler for other reasons and sometimes it and the 64 bit version "fight". That is hassle enough! "Fighting" between VCC and gnu C sounds like even more trouble!

Update again: Ok, I found the last long thread about this from ~1 year ago: Perl5.26 installing Tk module manually. The URL for the build that I made probably doesn't work anymore, but the OP was able to install this thing when the URL was current and it appears to have been successful.

  • Comment on Re^5: DBD:Mysql compilation failed on windows

Replies are listed 'Best First'.
Re^6: DBD:Mysql compilation failed on windows
by syphilis (Archbishop) on Mar 13, 2022 at 01:03 UTC
    You write: "Our project already using the active perl."

    That statement the OP made about using Active Perl puzzled me.
    AFAIK, by the time perl-5.24.1 came along, ActiveState were using gcc to build their perls, yet the perl -V output provided by the OP tells us that perl has been built using an MS compiler.
    I suspect that, although it's built by MSVC, the OP's perl has been built by someone other than ActiveState.

    Do you (or anyone else) know something about this that I don't ?

    Cheers,
    Rob
[reply]
[d/l]
      The OP's statement also puzzled me!!!

      I am still on AS (ActiveState) 5.24 which is the last version with PPM. My version was built with 64 bit gcc. I have used the AS cpan module to install some stuff which was not available via PPM successfully - sometimes not! I have found that some make files can have fine differences between Unix and Windows.

      I do not know anything more about what AS (ActiveState) is doing than when I last looked into this a year ago (May 2021) as per the previous link I posted.

      I suppose that it is possible that AS has switched compliers? I don't know. The MS C compiler is now free for non-commercial use. I used to get that and MASM, etc via my .edu connections, but I don't need to do that anymore. Which is actually a bummer because I used to be able to get the O/S free also.

      AFIK, the process I described to get a custom AS Perl build still exists no matter what compiler that AS is currently using. You wind up with an .MSI file and there aren't any "build errors".

      I think the OP needs to clarify exactly how his/her build came to be installed!

      If ActiveState is the desired "flavor" of Perl, then I think my post and referenced links are appropriate. If not, what the OP wants is a whole different "ball game".

      Summary: I don't know exactly what the OP is talking about either!

      As an update: AFIK, the MS C compiler puts a forensic "footprint" into the object code. Meaning that it is possible to determine whether or not a particular set of bits was generated by a "free" vs a "licensed" version of MS code - this not just one byte. Something to consider.

[reply]
        I suppose that it is possible that AS has switched compliers?

        In the beginning, they produced perls built using MSVC++ version 6.0.
        Later on, IIRC, even though their perls were still being built by a Microsoft Compiler, it became possible to ppm install mingw, which would install a mingw port of gcc.
        That gcc compiler could then be used to build perl extensions (XS modules), etc.
        This was facilitated by software that shipped with the AS perl distro and provided the same capability as provided by ExtUtils::FakeConfig.

        Later again, ActiveState started building their perls with a mingw port of gcc, but I'm not sure when that change actually happened.
        I, too, still have an AS build of perl 5.24 - specifically a 64-bit perl-5.24.1 built with gcc-4.6.3.
        I know it's an AS build because the perl -V output contains: 
        Locally applied patches:
      ActivePerl Build 2402 [401627]

        [download]
        To me, it looks unlikely that ActiveState ever provided an MSVC-built perl-5.24.1 - but I don't really know.

        Cheers,
        Rob
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom