https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93471
Bug ID: 93471
Summary: GCC-9.2.0 libgomp configuration passes bogus mingw32
library search paths
Product: gcc
Version: 9.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: keith.marshall at mailinator dot com
CC: jakub at gcc dot gnu.org
Target Milestone: ---
Building GCC-9.2.0 for mingw32 target, initially as GNU/Linux hosted
cross-compiler, and subsequently using that cross-compiler to build
cross-native for Win32 deployment, both builds fail at libgomp configuration
step, because libpthread.a cannot be found ... in spite of it being available
at its correctly installed location, relative to the associated pthreads header
files, which are found.
Specifically, failure to find the library is because the GCC-9.2.0 build
system, which does pass valid -I search paths, passes two entirely bogus -L
search paths, and no valid -L path, to the linker; both -L paths which are
passed lie within the non-existent, and never created,
${top_builddir}/mingw32/winsup hierarchy.
I can kludge around this, by manually creating the
${top_builddir}/mingw32/winsup/mingw directory, and creating libpthread.a
within it, as a hard link to the properly installed library, (which in my build
case is /home/keith/mingw32/lib/pthread.a), but that's a hideous kludge, to
work around a failing of the build system itself. Furthermore, it does have to
be a hard link, or a physical copy ... logically I had hoped that creating
${top_builddir}/mingw32/winsup as a physical directory hierarchy, with mingw as
a symbolic link within that, as a reference to /home/keith/mingw32/lib, would
have been sufficient, but apparently it is not.
I've never encountered any such issue, building previous GCC versions back as
far as GCC-4.8.2, and through to GCC-8.2.0, so it appears that this is a newly
introduced build system defect, with GCC-9.x
