2011/11/6 Ruben Van Boxem <vanboxem.ru...@gmail.com>
> 2011/11/6 Ozkan Sezer <seze...@gmail.com>
>
>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
>> <vanboxem.ru...@gmail.com> wrote:
>> > Hi,
>> >
>> > As promised, I am investigating the shared libstdc++ std::thread problem
>> > with winpthreads. Basically, a simple "Hello from thread" test program
>> > throws an "Operation not permitted" std::system_error exception, which
>> is
>> > most likely a result from winpthreads setting errno to EPERM. Test
>> program
>> > below:
>> >
>> > #include <iostream>
>> > #include <thread>
>> >
>> > using namespace std;
>> >
>> > void f()
>> > {
>> > cout << "hello from thread!" << endl;
>> > }
>> >
>> > int main()
>> > {
>> > thread t1(f);
>> > thread t2(f);
>> >
>> > t1.join();
>> > t2.join();
>> > }
>> >
>> > Using any of my std::thread toolchains (4.6.3, 4.6.2-stdthread or
>> > 4.7.0-stdthread) you can easily see that when not compiling this with
>> > "-static", the program throws abovementioned exception.
>> >
>> > I did some looking into the issue, and came up with the following:
>> > 1. There are 16 occurrences of EPERM in winpthreads (although not all
>> are
>> > return codes I think), in pthreads-win32, there are only 6 discernable
>> > usages. This might be due to less correctness in pthreads-win32, but the
>> > difference is at the very least noticeable.
>> > 2. I recompiled winpthreads, disabling each EPERM usage on per-file
>> basis,
>> > messing up correct functionality, but hoping to disrupt some pthreads
>> error
>> > to libstdc++ exception conversion, but nothing there had any effect.
>> > 3. Due to number 2, I'm now assuming there's some bad code in libstdc++,
>> > resulting in always throwing an exception. Strange enough, Google
>> popped up
>> > this reverse situation for GCC 4.6 and Debian/glibc:
>> >
>> http://stackoverflow.com/questions/7090623/c0x-thread-static-linking-problem
>> >
>> > Could it be that in the libstdc++ dll, this function
>> __ghtread_active_p() is
>> > inlined in the dll (so to speak) to always cause this exception being
>> thrown
>> > due to some incompatibility with the assumed semantics of inline and
>> dll's?
>> >
>> > I'd see if building a libstdc++ dll with debug info helps, but frankly,
>> dll
>> > debug info has always been disappointing in comparison to Linux so debug
>> > info.
>> >
>> > Any thoughts on how to best proceed are much appreciated.
>> >
>> > Ruben
>> >
>> > PS: currently winpthreads is broken due to the recent pthread_time.h
>> change:
>> > In file included from
>> >
>> m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
>> > from
>> m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
>> >
>> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:84:28:
>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> 'nanosleep'
>> >
>> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:86:28:
>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> > 'clock_nanosleep'
>> > In file included from
>> >
>> m:\development\mingw64\bin\../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/time.h:284:0,
>> > from
>> m:/Development/Source/mingw-w64/experimental/winpthreads/src/cond.c:29:
>> >
>> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:87:28:
>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> > 'clock_getres'
>> >
>> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:88:28:
>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> > 'clock_gettime'
>> >
>> m:/Development/Source/mingw-w64/experimental/winpthreads/include/pthread_time.h:89:28:
>> > error: expected '=', ',', ';', 'asm' or '__attribute__' before
>> > 'clock_settime'
>> > I reincluded <pthread.h> for the time being in that file, working around
>> > this error. I notified Kai of this on IRC, but he hasn't responded yet,
>> so
>> > I'm repeating it here for the record.
>>
>> Rev. 4589 should fix it.
>>
>
> Wow, didn't notice the type :-/ Thanks!
>
Argh... pthread_internal.h needs the pthread_t type (and thus a pthread.h
include):
libtool: compile: x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
-I/m/Development/Source/mingw-w64/experimental/winpthreads
-I/m/Development/Source/mingw-w64/experimental/winpthreads/include
-DIN_WINPTHREAD -Wall -g -O2 -MT src/libwinpthread_la-clock.lo -MD -MP -MF
src/.deps/libwinpthread_la-clock.Tpo -c
/m/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c
-DDLL_EXPORT -DPIC -o src/.libs/libwinpthread_la-clock.o
In file included from
m:/Development/Source/mingw-w64/experimental/winpthreads/src/clock.c:10:0:
m:/Development/Source/mingw-w64/experimental/winpthreads/src/winpthread_internal.h:25:59:
error: unknown type name 'pthread_t'
Thanks,
Ruben
>>
>> ------------------------------------------------------------------------------
>> RSA(R) Conference 2012
>> Save $700 by Nov 18
>> Register now
>> http://p.sf.net/sfu/rsa-sfdev2dev1
>> _______________________________________________
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>
>
------------------------------------------------------------------------------
RSA(R) Conference 2012
Save $700 by Nov 18
Register now
http://p.sf.net/sfu/rsa-sfdev2dev1
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
