At some level, I think your analysis maybe right - SOMETHING getting run probably involves a call to the OS which vectors through from the container to the underlying host, and that is not supported. I DONT think you have right, however, what program is doing that.
This test program is one I coded. If it had a call to a Windows API that was unavailable, that windows API would return with an error (#1) and the code would continue. That’s not what we are seeing.
More importantly, this issue is NOT restricted to just these test programs I built (compiled as part of the travisci build).
It ALSO happens to the ‘boost boostrapper’ program which prevents boost from building.
It ALSO happens to code I dont even BUILD, but simply extract from a zip file downloaded from the internet:
wget --quiet --no-check-certificate --tries=2 -O …/Origs-Cache/wix311-binaries.zip https://github.com/wixtoolset/wix3/releases/download/wix3111rtm/wix311-binaries.zip .
docker exec --workdir c:/Stroika buildContainer sh -c “cd ThirdPartyComponents/WIX/CURRENT/ && ./candle -v; echo $?”
1
(see https://api.travis-ci.com/v3/job/301395702/log.txt for this above script fragment/output)
WIX is a very widely used windows build tool. I cannot run even that and get the same ‘no output’ and ‘exit code 1’.
I tried using the powershell ‘unblock’ command on these executables (on the theorey it was some sort of antivirus thing). I’ve tried several such anti antivirus workarounds. NONE have worked. I’m not sure how to debug this without some sort of debugging access to these environments.
As I said, I’ve run this EXACT container on CircleCI without any problems, and on my own laptop. I THINK its pretty likely the difference stems from the version of the host (though I don’t have strong evidence for this).
Still looking for any ideas on how to move forward/fix this.
Do you have any examples of using travisci to run a docker container to build executables and run them?
THanks,
Lewis.