https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93471
--- Comment #3 from Keith Marshall <keith.marshall at mailinator dot com> ---
(In reply to Jakub Jelinek from comment #2)
> No idea what to look for, don't have any Windows around,
Nor do I ... I encountered this, initially when building a --target=mingw32
cross-compiler, on an up-to-date Manjaro-Linux, on which the native GCC is
GCC-9.2.0.
> and grep doesn't find any winsup strings in libgomp. Nor am aware of any
> mingw32/cygwin etc. related changes in libgomp recently.
IIRC, winsup is an artefact of cygwin's build system, which of course should
not really be applicable for builds on a GNU/Linux host. If it helps, the
problem initially manifests when running the configure script for the libgomp
component: configure aborts, stating that "Pthreads is required to build
libgomp", and the failure is the result of a link test, which cannot find
-lpthread. Once I've placed libpthread.a into the
${top_builddir}/mingw32/winsup/mingw directory, configure succeeds, the build
proceeds, and interestingly, grep finds no references to -lpthread in my build
log, (but does find -pthread references, which presumably implies -lpthread).
Although this initially manifests for libgomp, the actual source of the failure
may lie elsewhere within the GCC build system. After placing libpthread.a into
the ${top_builddir}/mingw32/winsup hierarchy, other components -- initially ada
-- fail in identical circumstances, with identical -L path specs, except that
it is -lws2_32 which cannot be found, unless it to is copied to the
${top_builddir}/mingw32/winsup hierarchy.
The real issue here seems to be: where do these bogus -L
.../mingw32/winsup/mingw -L .../mingw32/winsup/w32api/lib references originate,
and how do we fix them to reflect the correctly installed paths for the windows
support libraries?
