gcc hangs even on simple compile tasks

[Backwoods BC]

On Sun, Mar 22, 2026 at 7:55 AM Dick Pierce via Cygwin <cygwin@cygwin.com>
wrote:

> On 3/10/2026 9:08 AM, Brian Inglis via Cygwin wrote:
> > On 2026-03-06 17:29, Annihilannic via Cygwin wrote:
> >> On 07/03/2026 09:37, Dick Pierce via Cygwin wrote:
> >>> Starting the end of last week, gcc has started behaving badly. Whether
> I invoke
> >>> it from a makefile or directly from bash, almost ALL of the timer, it
> hangs
> >>> forever, and Task Manager shows cc1 as "running", but consuming no CPU
> as
> >>> far as I can tell. If I kill it through task manager, the prompt
> returns
> >>> in bash (or make dies with an "interrupted" error.
> >
> >>> But I'm stumped.
> >
> >> Smells like a hardware problem to me - I'd suggest testing it
> thoroughly with
> >> memtest86 or similar.
> >>
> >> Also run it through `strace -f gcc -o hello.exe hello.c` a few times
> and see
> >> if it's sticking in the same spot every time (which would indicate
> software)?
> >
> > Never blame hardware until you have eliminated the likelihood of BLODA
> (Big List
> > Of Dodgy Apps <https://www.cygwin.com/acronyms/#BLODA>: FAQ 4.44.
> >
>
> I went so far as wiping the machine completely of cygwin, pulled all
> references to cygwin out of the registry[1], and reinstalled cygwin
> from scratch: no change in behavior at all.
>
> After multiple dead end rabbit holes (redundant?), the problem was none
> of what anyone thought it was: it was MUCH simpler.
>
> Out of desperation and on a hunch, I did a search of the machine for all
> instances cygwin1.dll on the machine. I had 6 copies spread all over the
> place. Crucially, there was one in c:/windows/system. Got rid of that one,
> all of a sudden, gcc started working just fine. And since /windows/system
> has near the head of PATH, it was the one that got done first. Did a
> compare
> of that one to the one in /cygwin64/bin and, yes, it was different.
>
> So I then did a purge of my system of every instance of cygwin1.dll across
> the system I could find EXCEPT the one that came with the latest cygwin
> installation. How the crucial one ended up in /windows/system, I have
> NO idea. But often, looking at the simplest and, perhaps, dumbest cause
> of a problem is best done first.
>
> FOOTNOTES
> ==========
> [1] What does the Windows registry and Florida have in common? it's a place
>      where things go to die.
>
> --
> +-----------------------------------+
> |            Dick Pierce            |
> |         Diverse Pursuits          |
> | Technical Engineering/Development |
> |           cartchunk.org           |
> |       Boston - Spruce Head        |
> +-----------------------------------+
>
>
> --
> Problem reports:      https://cygwin.com/problems.html
> FAQ:                  https://cygwin.com/faq/
> Documentation:        https://cygwin.com/docs.html
> Unsubscribe info:     https://cygwin.com/ml/#unsubscribe-simple


That's an unsubtle reminder that you need to always check what your path is
when you have Cygwin. There are several executables that have the same name
in the Windows and Cygwin "bin" directories:
bash.exe
comp.exe
curl.exe
expand.exe
find.exe
HOSTNAME.EXE <> hostname.exe
PING.EXE <> ping.exe
shutdown.exe
sort.exe
tar.exe
timeout.exe
whoami.exe

You want to make sure that you are grabbing the correct one for your
context or bad/confusing things will happen. The default path is an
automated guess at what might be a good selection for your system, but I've
never had it be sufficient for proper operation in any of my many
installations over the years.

Also, those other 'cygwin1.dll' instances are likely the result of "quick
and dirty" ports of *nix apps to Windows. The apps may not work properly
when run under the current release. Or they may just fail because they
can't find 'cygwin1.dll' in the Windows path.