autoconf2.7 missing on scallywag?

[Brian Inglis]

On 2025-04-19 10:10, Glenn Strauss via Cygwin-apps wrote:
> 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.

That kind of thing would have to happen in the local Cygport or Scallywag CI 
Windows environment, as the calm infrastructure is Fedora.

Could we use gendef and nm/objdump to compare Cygwin definitions and uses, or is 
there some loader function to display unresolved symbols, or the Cygwin ABI 
required?

-- 
Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada

La perfection est atteinte                   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retrancher  but when there is no more to cut
                                 -- Antoine de Saint-Exupéry