ci: upstream libxml2 testing: windows and ruby_memcheck coverage

[flavorjones]

What problem is this PR intended to solve?

libxml2 2.11.0 is failing windows builds, and I think I probably could have caught the problem earlier if I was running the upstream builds on windows. This PR adds that integration testing.

libxml2 is also leaking memory, so this PR also adds ruby_memcheck testing on the upstream builds to try to detect these problems earlier.

[flavorjones]

@MSP-Greg Sorry to have to ask for help. I'm having a bit of trouble getting autotools/libtool to work properly on Windows. The error I'm seeing is, from the configure.log:

configure: error: cannot find required auxiliary files: ltmain.sh compile missing install-sh config.guess config.sub

despite trying to install these packages in the setup-ruby-pkgs config:

      - uses: ruby/setup-ruby-pkgs@v1
        with:
          ruby-version: "3.2"
          apt-get: "autogen libtool shtool"
          brew: "automake autogen libtool shtool"
          mingw: "_upgrade_ autotools"
          bundler-cache: true
          bundler: latest

I've tried a few variations of what packages I specify, under both mingw and msys2 keys, but the behavior seems to be the same no matter what I try.

Am I missing something obvious? Can you make a suggestion at what I should look at next?

[MSP-Greg]

@flavorjones

Sorry for the delay. I believe config.guess and config.sub need to be downloaded, I think ruby/ruby does so. Not sure about the other items. Build systems are not something I have much knowledge of.

Both files are 'small', so they could be added to the Windows 'build tool packages' that are installed by setup-ruby. Not sure where to put them.

I checked MSY2 and MSFT vcpkg, and neither have updated to libxml2 2.11.0, so looking at their build scripts probably won't be very helpful...

[flavorjones]

@MSP-Greg Thanks for responding, I appreciate your time. I have to apologize for not explaining better what I am having trouble with -- mostly because I'm not sure what's going wrong, so thanks for your patience.

I've tried explicitly installing libtool which contains the files being logged as missing. And they're still not being found.

Do you know: is there some sort of $PATH shenanigans that I need to be setting so that these scripts and files get found?

My next step is going to be digging into where pacman installs the files and what the paths are in the environment, but the feedback loops are slow here so I was hoping you'd spot something silly that I'm doing or not doing.

[flavorjones]

@MSP-Greg Apologies again, after some more digging I don't think this is related to the mingw packages, I think the problem is likely something in the Nokogiri build system that's causing the --with-xml2-source-dir flag to not work properly on windows. Sorry to have tagged you needlessly.

[MSP-Greg]

@flavorjones

I think 'libtool is already installed.

For the info on what packages are installed with setup-ruby, see

https://github.com/ruby/setup-msys2-gcc/actions/workflows/windows-build-tools.yml

The most recent workflow run shows jobs for MSYS2 and the various build archives that are available. The 'msys2 tools' jobs show that libtool is already installed.

As to the other jobs, they're pairs of MINGW64 & UCRT64 gcc tools and ruby build dependencies, with the -3.0 jobs containing current OpenSSL (now 3.1.0) and the other jobs containing the most recent OpenSSL 1.1.1 build.

Back to this issue, pacman -Qo config.guess should show which package 'owns' the file. Locally it reports error: No package owns config.guess, but as your link to the libtool info shows, they are installed locally on my system in the following folder:

C:/msys64/usr/share/libtool/build-aux

Do you know: is there some sort of $PATH shenanigans that I need to be setting so that these scripts and files get found?

The ruby/ruby build scripts copy some of the files into the src folder, in a tools directory. Not sure.

JFYI, I use nokogiri daily when updating https://msp-greg.github.io/. I also always use ruby master/head/trunk, so I never use the pre-compiled gem. This code has been in place for years. I normally had the --use-system-libraries option set, but I just yanked it and installed/compiled nokogiri with the vendored code in the gem. Installed fine, haven't run it yet. Not sure if you're doing something similar in CI here...

[flavorjones]

@MSP-Greg Just closing the loop with you -- see flavorjones/mini_portile#126 for the underlying fix. It was a matter of converting a windows path to a posix path so the configure script can correctly detect the aux files (like config.guess).