Fix MinGW Travis build issues

[neptoess]

Relative discussion in #3130

[edenhill]

Perfect, thank you!

[edenhill]

late comment, but these should be moved for the dynamic build script too.

[edenhill]

Hey @neptoess , pinging you here in lack of better communication alternatives:
The dynamic mingw build is failing (silently) because msys2 now uses gcc 11 which introduces a new _ZSt28__throw_bad_array_new_lengthv symbol, but the libstdc++ on the system is compiled with an older gcc that does not have this symbol, so trying to execute the test runner fails silently.
It is basically this issue:
stan-dev/pystan#294

But I'm not sure that solution (symlink/replace) is viable for our msys2 builder.

Do you have any ideas?

https://app.travis-ci.com/github/edenhill/librdkafka/jobs/564513967

[neptoess]

Added you on LinkedIn for a communication alternative (can also provide email if you'd like).
Let me play around with the build a bit on my local machine and see if I can come up with anything.

[neptoess]

v1.9.0-PRE11.build.log
Upgraded my msys2 packages and did the build. As the old joke goes, "works on my machine".

I also just realized that the build you linked was the dynamic build (pinging @ed-alertedh @edbordin since he was involved there), but the static build worked (https://app.travis-ci.com/github/edenhill/librdkafka/jobs/564513968). The build log you linked seems to cut off without even attempting to run the tests. Bizarre.

Adding a $msys2 pacman -Q to the end of travis-before-install.sh might be useful, so we can easily see exactly which packages, and which versions, are installed during the build.

[edenhill]

The build log you linked seems to cut off without even attempting to run the tests. Bizarre.

Yeah, turns out linkage errors are not emitted to the shell, the process just exits with a 127 return code.
Running it with strace, locally, did however show the symbol issue.

Do you think it would be possible just to version pin the gcc toolchain to a 10 release?

[neptoess]

Do you think it would be possible just to version pin the gcc toolchain to a 10 release?

That's kind of nasty (https://www.msys2.org/docs/package-management/#installing-a-specific-version-of-a-package-or-a-stand-alone-packages), but I'll play around with the dynamically linked build locally and see what I can figure out.