autoconf2.7 missing on scallywag?

[Glenn Strauss]

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