Our project already using the active perl. Changing to strawberry per
+l will be huge effort :(.
  
           And also i tried download DBD-mariaDB / DBD-mysql tar local
+ly and setup VC environment and compiled. Both getting same error. As
+ per your suggestion will remove the VC environment setting and try w
+ith Minguw and get back to you.
[download]

As per your suggestion will remove the VC environment setting and try with Mingw

If you want to use a mingw compiler with a perl built by MSVC++, then you should install ExtUtils::FakeConfig. Run cpan -i ExttUtils::FakeConfig .
However, it has been at least 10 years since I've used that module, and I don't know if it's still fit for purpose. Then, whenever you want to use the mingw compiler, you just set the PERL5OPT environment variable to -MConfig_m :

set PERL5OPT=-MConfig_m
[download]

You might be better off just persevering with your VC++ compiler.
It's hard for me to tell.

This command (from your first post) looks wrong to me:

perl Makefile.PL --cflags=-IC:\mysql\include --libs="-LC:\mysql\lib -l
+mysqlclient" --testdb=vms --testuser=root --testpassword=cisco@123 --
+testhost=127.0.0.1 --testport=3306
[download]

Usually you would have:

perl Makefile.PL INC=-IC:\mysql\include LIBS="-LC:\mysql\lib -lmysqlcl
+ient" ....
[download]

That should at least make the MySQL headers and libraries locatable if they are in fact located where you're saying they are. Does C:/mysql/lib/mysqlclient.lib exist ? (I don't know about the remaining arguments. Is there documentation that's telling you to provide these arguments in these ways ?)

Maybe just try starting with a plain perl Makefile.PL. That's what Strawberry Perl does:

>perl Makefile.PL
I will use the following settings for compiling and testing:

  cflags       (mysql_config ) = -IC:\_32\strawberry5.24.0_32int\c\bin
+\..\include\mysql_5
  libs         (mysql_config ) = -LC:\_32\strawberry5.24.0_32int\c\bin
+\..\lib -lmysql
  mysql_config (guessed      ) = mysql_config
  testdb       (User's choice) = test
  testhost     (default      ) =
  testpassword (User's choice) =
  testport     (default      ) =
  testsocket   (default      ) =
  testuser     (User's choice) =

To change these settings, see 'perl Makefile.PL --help' and
'perldoc DBD::MariaDB::INSTALL'.

Checking if libs and header files are available for compiling...
Checking if correct version of MariaDB or MySQL client is present...
Looks good.

Embedded server: not supported by client library

Client library deinitialize OpenSSL library functions: no

Using DBI 1.636 (for perl 5.024000 on MSWin32-x86-multi-thread) instal
+led in C:/_32/strawberry5.24.0_32int/perl/vendor/lib/auto/DBI/
Generating a dmake-style Makefile
Writing Makefile for DBD::MariaDB
"\x{0159}" does not map to cp850 at C:/_32/strawberry5.24.0_32int/perl
+/lib/ExtUtils/MakeMaker.pm line 1269.
"\x{0159}" does not map to cp850 at C:/_32/strawberry5.24.0_32int/perl
+/lib/ExtUtils/MakeMaker.pm line 1269.
"\x{0159}" does not map to cp850 at C:/_32/strawberry5.24.0_32int/perl
+/lib/ExtUtils/MakeMaker.pm line 1269.
Writing MYMETA.yml and MYMETA.json
[download]

Cheers,
Rob

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.

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

I have thought more about "Our project already using the active perl.".

Maybe this is an English language problem? Perhaps you mean that you are using the system's Perl?

If that is so, I don't understand because Windows doesn't have a system Perl. Unix has such a thing - all Unix systems have Perl installed for system functions. If you have Unix, you should install a separate Perl for your use aside from the system version. If you have Windows, then I for sure don't understand the question. Active Perl is a buzzword for "Active State Perl" - Perl from a company called Active State.

Rob and Marshall,

Thanks for the reply As per your suggestion we removed the VC environm
+ent and installed Mingw and tried the Perl DBD::mysql compilation but
+ some how  its refers the nmake from Visual Studio. not sure where it
+s referring from. completely removed VC reference from the environmen
+t settings. Also initially picked up the dmake later its changed to n
+make :(.

Generating a dmake-style Makefile
Writing Makefile for Devel::CheckLib
Writing MYMETA.yml and MYMETA.json
  MATTN/Devel-CheckLib-1.14.tar.gz
  C:\Perl\bin\perl.exe Makefile.PL -- OK
    :
    :
    :
to undefined at C:\perl\lib/ExtUtils/Install.pm line 1198.
NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x2'
Stop.
  RURBAN/Mock-Config-0.03.tar.gz
  "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.EX
+E" -- NOT OK
[download]

Thanks, Anitha.S

 Finally the compile picked the dmake and after that final execution f
+ailed with the following. Kindly help.

Generating a dmake-style Makefile
Writing Makefile for Mock::Config
Writing MYMETA.yml and MYMETA.json
  RURBAN/Mock-Config-0.03.tar.gz
  C:\Perl\bin\perl.exe Makefile.PL -- OK
Running make for R/RU/RURBAN/Mock-Config-0.03.tar.gz

Microsoft (R) Program Maintenance Utility Version 14.00.24210.0
Copyright (C) Microsoft Corporation.  All rights reserved.

Recompile perl with -DDEBUGGING to use -D switch (did you mean -d ?)
Recompile perl with -DDEBUGGING to use -D switch (did you mean -d ?)
Recompile perl with -DDEBUGGING to use -D switch (did you mean -d ?)
Recompile perl with -DDEBUGGING to use -D switch (did you mean -d ?)
Recompile perl with -DDEBUGGING to use -D switch (did you mean -d ?)
Recompile perl with -DDEBUGGING to use -D switch (did you mean -d ?)

to undefined at C:\perl\lib/ExtUtils/Install.pm line 1198.
NMAKE : fatal error U1077: 'C:\Perl\bin\perl.exe' : return code '0x2'
Stop.
  RURBAN/Mock-Config-0.03.tar.gz
  "C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\BIN\nmake.EX
+E" -- NOT OK
[download]

You have somehow managed to generate a Makefile written for dmake ... but then that Makefile gets processed by nmake, and nmake doesn't understand Makefiles that were written for dmake.

You have a perl that specifies that perl -V:cc is cl and that perl -V:make is nmake. If you wish to use a mingw compiler to build a DBD module for that perl then the first thing you must do is to install ExtUtils::FakeConfig. And the second thing you must do is to set PER5OPT=-MConfig_m set PERL5OPT=-MConfig_m (Thanks to hv for the correction.)
Next you check that perl -V:make reports dmake and that perl -V:cc reports gcc. (If that's not happening, then something is not right.)
Then you have a chance of success ... or we'll at least start seeing helpful error messages. I know this is something that can work.

I actually think that if you were to instead use your MS compiler && provide correct command line arguments to the perl Makefile.PL ... command, then you might achieve what you want. But I don't know if this is something that can work.

In my opinion, the simplest solution is to just install one of the later "portable" editions of Strawberry Perl, where both DBD::MySQL and DBD::MariaDB are already installed, and can be updated using the cpan command if an upgrade of those modules is needed.
This is also something that can work.

Cheers,
Rob