On Sun, Nov 6, 2011 at 3:54 PM, Ruben Van Boxem
<vanboxem.ru...@gmail.com> wrote:
> 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
If you remove the winpthread_internal.h include from clock.c and nanosleep.c
do they compile OK? AFAICS, those two don't need winpthread_internal.h.
--
O.S.
------------------------------------------------------------------------------
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
