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
