MySQL 8.0.35 GCC library

[thockar]

I compiled mysql libraries 8.0.35 using gcc version 11.3.0 (Rev1, Built by MSYS2 project)
It makes it possible to install the latest DBD::mysql driver 5.xxx, which requires a mysqllib version 8.x.x.
It requires openssl 3.x.x (is compiled using 3.0.9) and an installed msvcr100.dll

You are free to implement it in to Strawberry Perl.
mysql_80035.zip

[shawnlaffan]

Thanks @thockar

Can you provide the build steps (if non-standard) and any patches that were applied?

[thockar]

I've build 8.0.35 , 8.1.0 and 8.2.0 .
8.0.35 and 8.2.0 are working with all DBD::mysql versions (4.x and 5.x). 8.1.0 was released before 8.0.35 and does'nt contain the fix for the handshake error in connections to server-versions < 5.5.
There are too many tweaks required to build (only) the mysql libraries. How ever I'll try to provide a diff file.

• special installations of some MSYS2 packages (manual installation)
• include the msvcr100 in the default gcc build definitions
• some cmake files require changes (skip boost, correctly detect SSL-Lib, build dynamic libs ....)
• several header files need changes (in various locations) - fix MSVC special instructions (for example __try ....except...) and wrong #include
• fix some preprocessor definitions which are accepted by MSVC but not by GCC
• several cc files need changes for the same reasons

Most of the changes are made without checking for available or missing (pre)compiler definitions - so they will only work in the build environment they were made for.

The mysql code uses definitions and instructions which are not provided by any STD GCC library (c, c++) - they require a msvc-runtime dll 90 or higher. I used the msvcr100, which should be available for every Windows Vista-Kernel or higher (I'm not sure about WinXP.x64).

I've attached the 8.2.0 zip.
mysql_80200.zip

[thockar]

here are some files which will help you to build the mysql 8.2.0 libs

good luck
files.zip

[shawnlaffan]

Thanks for that. I'll see if I can integrate the steps with the build system.

[bryan-valentine]

It requires openssl 3.x.x (is compiled using 3.0.9)

How do install this on a Windows server?

[thockar]

openssl 3.0.9 was build using MSYS2/mingw64
see the attached zip file
64bit_openssl-3.0.9-bin_20230621.zip

[dveeden]

@thockar did you submit bug reports to Oracle MySQL for the changes you had to make to the cmake files etc?

[thockar]

No, because GCC is official not supported by MySQL and the build environment I used, is only changed to build the MySQL libraries with/for GCC.

[rsomla1]

Since building with GCC on Windows is not officially supported by MySQL I would consider building it using MSVC compiler. That should produce the required DLL. It will still depend on msvc runtime and openssl dlls but I think there is no way around that. I am not 100% sure but I believe such DLL produced using MSVC can be happily used in another project that is built using GCC.

Regarding openssl libs for Win they are bundled inside MySQL server packages for that platform (check the bin/ folder inside ZIP packages)

[sisyphus]

I am not 100% sure but I believe such DLL produced using MSVC can be happily used in another project that is built using GCC.

I'd be interested to hear how it goes.
Please keep us informed.

I build Image::Magick on Strawberry Perl against MSVC-built ImageMagick.
It seems ok (and always passes its test suite), but I don't regard that as proving that such an approach can always be made to work.
Maybe it's just that the Image::Magick test suite doesn't do the thing(s) that break.

Mostly, I do it the other way around. That is, I use mingw-w64-built libraries (gmp, mpfr, mpc, mpfi) with perl built by VS 2022.
I find that as long as the mingw-w64 gcc compiler is a "UCRT" one (eg the one that currently ships with SP-5.40.0), then I get perfect mileage.
But if the gcc compiler is an "MSVCRT" one, then I have to avoid calling all library functions that take a filehandle as an argument.