Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: sliwa at ifpan dot edu.pl
Target Milestone: ---
Created attachment 53050
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53050&action=edit
sample program demons
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67116
--- Comment #6 from Cezary Śliwa ---
Created attachment 36131
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36131&action=edit
config.log
libstdc++v3 config.log
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114
--- Comment #9 from Cezary Śliwa ---
One think I missed is that MinGW64 uses the winpthreads library. If using
winpthreads, there is no failure. However, as far as I understand,
pthreads-win32 is in use in MinGW.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67116
--- Comment #4 from Cezary Śliwa ---
OK, the newly built compiler cannot be used because we are cross-compiling. The
only thing that can be done is to move the trees to the target system and
finish building target libraries there. A warning or er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67116
--- Comment #2 from Cezary Śliwa ---
This is a quite special case, target and host architecture are the same, only
the thread models are different. I think libstdc++ uses the preinstalled
compiler rather that the one just built. Anyway, the prei
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114
--- Comment #7 from Cezary Śliwa ---
1. After applying the patch to GCC 5.2.0, the build fails (I do not see
PTW32_VERSION defined):
Making all in c++11
make[5]: Entering directory
`/home/czarek/src/nowe/build-pthreads/objdir-gcc/x86_64-w64-min
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sliwa at ifpan dot edu.pl
Target Milestone: ---
The configure script detects the thread model of the CXX compiler. When
building the tool chain it is the compiler for the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114
--- Comment #3 from Cezary Śliwa ---
Yes, I understand. The purpose of the patch is to point the problem. In
particular I don't know why operator< is needed and what are the required
semantics (i.e. comparing pointers vs. comparing thread sequenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67115
--- Comment #2 from Cezary Śliwa ---
It may be because they follow the OS specific standards, so to say.
ty: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: sliwa at ifpan dot edu.pl
Target Milestone: ---
A pthreads build on MinGW64 fails due to a name conflict:
* "CONST" is a macro in the system headers (#defined to c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67114
--- Comment #1 from Cezary Śliwa ---
Created attachment 36120
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36120&action=edit
complementary patch to the w32-pthreads library
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sliwa at ifpan dot edu.pl
Target Milestone: ---
Created attachment 36119
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36119&action=edit
proposed patch to GCC
Since operator< is not available
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: sliwa at ifpan dot edu.pl
Target Milestone: ---
Created attachment 36118
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36118&action=edit
proposed path
libstdc++ f
13 matches
Mail list logo
