On Sat, Apr 19, 2025 at 04:33:24PM +0100, Jon Turney via Cygwin-apps wrote: > On 15/04/2025 16:41, Andrew Schulman via Cygwin-apps wrote: > > On Mon, 14 Apr 2025 18:24:15 -0400, in gmane.os.cygwin.applications > > Ken Brown wrote: > > > > > I've had two packages fail to build on scallywag with the error message > > > > > > *** ERROR: autoconf2.7 is required to build this package > > > > > > But cygport requires autoconf which requires autoconf2.7. Any idea > > > what's going on? > > > > > > Ken > > > > screen builds are also failing, with the same error. > > Thanks for pointing this out. > > I was finally was able to do a little digging into this: > > So, firstly, autoconf2.7 is being installed, as the logs show. > > However, autoconf is a perl script, and it seems that perl is exiting with > code 127. stracing it just hangs. > > This baffled me for a bit until the brain fog cleared: This is just what we > expect when strace is sitting there with an dialog box from the Windows > module loader (that nobody can see on the screen of the VM) due to an > unresolved export. > > So, it seems we were running the combination of cygwin-3.5.7-1 and > perl-5.40.2-1, which won't work (because perl now makes used the "new in > 3.6.0" setproctitle API). > > I've removed the cygwin=3.5.7-1 pin in scallywag, since the issue I was > worried about there seems to have been imaginary. > > Please try rerunning the builds now. > > > > I wish there was a way to surface these kind of loader errors to the > console, so these failures weren't so inscrutable, but last time I looked at > it, that appeared to be impossible. > > It would also be nice if we recorded a package's dependency on cygwin in a > more sophisticated way (against the API level, I guess) so the depsolver > would have the information to avoid these kind of breakages in the first > place, but again SHTDI :(.
What used to be nearly impossible might now be possible with powershell redirection. I am not a Windows machine to test any of this, but a quick search turned up some ideas to try. Might try starting a bash shell through powershell with console redirection, rather than starting a bash shell directly. https://learn.microsoft.com/en-us/powershell/scripting/samples/redirecting-data-with-out---cmdlets?view=powershell-7.5 https://stackoverflow.com/questions/72272584/windows-batch-redirect-output-to-console https://superuser.com/questions/1347898/force-output-to-console-in-a-batch-script-with-output-redirected-to-a-file https://github.com/ritchielawrence/mtee Regarding depsolver, MS provides https://www.dependencywalker.com/ and a 2019 paper exploring windows native loader might be interesting. "DLL shell game and other misdirections: the Windows’s native loader is a magician" https://www.sstic.org/media/SSTIC2019/SSTIC-actes/dll_shell_game_and_other_misdirections/SSTIC2019-Article-dll_shell_game_and_other_misdirections-georges.pdf Yes, SHTDI. I might toy around if I find myself in a Windows environment, but that is admittedly rare. Cheers, Glenn
