Re: [Mingw-w64-public] Issue in x264 - ffmpeg building and usage in different Windows versions
On 11/7/2011 13:20, Shiju Sasi wrote: > Hi, > > Do any of you have pointers on the below errors while I compile my windows > 32 DLL using static CRT ? Deployment of the application has issues, when we > have dynamic CRTs. Please guide. > > Thanks, > Shiju Unlinked compiler objects aren't guaranteed to be compatible, one of the symptoms are link errors like these. Only well known interfaces like DLLs are guaranteed to work with other compilers, since to use these DLLs, would be to conform to platform specifications, object files don't need to conform to any specification. The easiest way if you still want to use -MT is to build ffmpeg libraries as DLLs, and generate the export def from the DLLs with gendef or similar tools. Next would be to use MSVC lib.exe to generate MSVC compatible import libraries, you can now link with MSVC, but you need to distribute the ffmpeg DLLs with your programs. Otherwise, use GCC or MSVC for all your linking and avoid using other compilers entirely. signature.asc Description: OpenPGP digital signature -- 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
Re: [Mingw-w64-public] Issue in x264 - ffmpeg building and usage in different Windows versions
2011/11/7 Shiju Sasi : > Hi, > > Do any of you have pointers on the below errors while I compile my windows > 32 DLL using static CRT ? Deployment of the application has issues, when we > have dynamic CRTs. Please guide. > Thanks, > Shiju > > On Fri, Nov 4, 2011 at 10:33 AM, Shiju Sasi wrote: >> >> Hi, >> >> Here are the exact list of warnings/errors. >> >> >> 1>AveVideoControl.exp : warning LNK4078: multiple '.drectve' sections >> found with different attributes (0200) >> >> 1>libavcodec.a(utils.o) : warning LNK4217: locally defined symbol _isprint >> imported in function _av_get_codec_tag_string >> >> 1>libx264.a(common.o) : warning LNK4217: locally defined symbol __iob >> imported in function _x264_log_default >> >> 1>libavutil.a(log.o) : warning LNK4049: locally defined symbol __iob >> imported >> >> 1>libx264.a(common.o) : warning LNK4217: locally defined symbol __stricmp >> imported in function _x264_param_parse >> >> 1>libx264.a(common.o) : warning LNK4217: locally defined symbol __strnicmp >> imported in function _x264_param_default_preset >> >> 1>libmingwex.a(wcrtomb.o) : warning LNK4217: locally defined symbol >> ___lc_codepage imported in function _wcsrtombs >> >> 1>libmingwex.a(mbrtowc.o) : warning LNK4049: locally defined symbol >> ___lc_codepage imported >> >> 1>libmingwex.a(wcrtomb.o) : warning LNK4217: locally defined symbol >> ___mb_cur_max imported in function _wcsrtombs >> >> 1>libmingwex.a(mbrtowc.o) : warning LNK4049: locally defined symbol >> ___mb_cur_max imported >> >> 1>libavutil.a(eval.o) : warning LNK4217: locally defined symbol _isspace >> imported in function _av_expr_parse >> >> 1>libavcodec.a(utils.o) : error LNK2019: unresolved external symbol >> __imp__toupper referenced in function _ff_toupper4 >> >> 1>libavutil.a(dict.o) : error LNK2001: unresolved external symbol >> __imp__toupper >> >> 1>libavutil.a(avstring.o) : error LNK2001: unresolved external symbol >> __imp__toupper >> >> 1>libx264.a(encoder.o) : error LNK2019: unresolved external symbol >> __imp___fstat referenced in function _x264_encoder_open_118 >> >> 1>libx264.a(ratecontrol.o) : error LNK2001: unresolved external symbol >> __imp___fstat >> >> 1>libavutil.a(log.o) : error LNK2019: unresolved external symbol >> __imp___vsnprintf referenced in function _av_log_default_callback >> >> 1>libavutil.a(avstring.o) : error LNK2001: unresolved external symbol >> __imp___vsnprintf >> >> 1>.\ReleaseMinDependency\AveVideoControl.dll : warning LNK4088: image >> being generated due to /FORCE option; image may not run >> >> Thanks, >> Shiju >> On Thu, Nov 3, 2011 at 3:17 PM, JonY wrote: >>> >>> On 11/3/2011 13:04, Shiju Sasi wrote: >>> > Hi I build my Windows 32 bit DLL on Vista machine. This DLL works in a >>> > browser context to render Video using H264 video. I use x264 and ffmpeg >>> > libraries. My deployment can be any Windows machine ( Vista, 7, XP etc) >>> > >>> > I configured x264 using >>> > >>> > ./configure --cross-prefix=i686-w64-mingw32- --enable-shared >>> > --disable-swscale --disable-ffms --disable-asm --disable-thread >>> > >>> > Then did the make. >>> > >>> > Then I configured ffmpeg using. >>> > >>> > >>> > ./configure --enable-cross-compile >>> > --cross-prefix=i686-w64-mingw32- --enable-shared --disable-pthreads >>> > --arch=x86_32 --enable-postproc --enable-avfilter --disable-armv5te >>> > --disable-ffplay --disable-ffserver --disable-ffprobe --disable-doc >>> > --disable-debug --disable-encoders --disable-muxers --disable-neon >>> > --disable-pic --disable-decoders --enable-decoder=h264 --disable-bsfs >>> > --disable-protocols --disable-parsers --enable-parser=h264 >>> > --disable-filters --disable-demuxers >>> > then did make. >>> > >>> > Now my application DLL, I built using /MT so as to avoid any CRT mess >>> > up in >>> > the deployed machine. But the build fails with 3 linker errors - >>> > >>> >>> Do not use /MT. use /MD instead, mingw has not been designed to handle >>> static CRT since its inception, that is unless MS releases their C >>> runtime with an OSS compatible license. >>> >>> > *unresolved external symbol __imp__toupper , * >>> > * >>> > >>> > unresolved external symbol __imp___fstat, >>> > >>> > and >>> > >>> > unresolved external symbol __imp___vsnprintf >>> > >>> >>> Please do not hide any errors and post all of them, eg which object is >>> requiring them. >>> >> Shiju, if you want that your e-mail getting directly posted to this ML, please subscribe to it. Otherwise you need to wait until somebody of us is moderating it. To your linker issue: You need to add a library to your VC for linking, which includes those symbols. For mingw-w64 it would be libmsvcrt.a library. Regards, Kai -- 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.ne
Re: [Mingw-w64-public] Issue in x264 - ffmpeg building and usage in different Windows versions
Hi, Do any of you have pointers on the below errors while I compile my windows 32 DLL using static CRT ? Deployment of the application has issues, when we have dynamic CRTs. Please guide. Thanks, Shiju On Fri, Nov 4, 2011 at 10:33 AM, Shiju Sasi wrote: > Hi, > > Here are the exact list of warnings/errors. > > > 1>AveVideoControl.exp : warning LNK4078: multiple '.drectve' sections > found with different attributes (0200) > > 1>libavcodec.a(utils.o) : warning LNK4217: locally defined symbol _isprint > imported in function _av_get_codec_tag_string > > 1>libx264.a(common.o) : warning LNK4217: locally defined symbol __iob > imported in function _x264_log_default > > 1>libavutil.a(log.o) : warning LNK4049: locally defined symbol __iob > imported > > 1>libx264.a(common.o) : warning LNK4217: locally defined symbol __stricmp > imported in function _x264_param_parse > > 1>libx264.a(common.o) : warning LNK4217: locally defined symbol __strnicmp > imported in function _x264_param_default_preset > > 1>libmingwex.a(wcrtomb.o) : warning LNK4217: locally defined symbol > ___lc_codepage imported in function _wcsrtombs > > 1>libmingwex.a(mbrtowc.o) : warning LNK4049: locally defined symbol > ___lc_codepage imported > > 1>libmingwex.a(wcrtomb.o) : warning LNK4217: locally defined symbol > ___mb_cur_max imported in function _wcsrtombs > > 1>libmingwex.a(mbrtowc.o) : warning LNK4049: locally defined symbol > ___mb_cur_max imported > > 1>libavutil.a(eval.o) : warning LNK4217: locally defined symbol _isspace > imported in function _av_expr_parse > > 1>libavcodec.a(utils.o) : error LNK2019: unresolved external symbol > __imp__toupper referenced in function _ff_toupper4 > > 1>libavutil.a(dict.o) : error LNK2001: unresolved external symbol > __imp__toupper > > 1>libavutil.a(avstring.o) : error LNK2001: unresolved external symbol > __imp__toupper > > 1>libx264.a(encoder.o) : error LNK2019: unresolved external symbol > __imp___fstat referenced in function _x264_encoder_open_118 > > 1>libx264.a(ratecontrol.o) : error LNK2001: unresolved external symbol > __imp___fstat > > 1>libavutil.a(log.o) : error LNK2019: unresolved external symbol > __imp___vsnprintf referenced in function _av_log_default_callback > > 1>libavutil.a(avstring.o) : error LNK2001: unresolved external symbol > __imp___vsnprintf > > 1>.\ReleaseMinDependency\AveVideoControl.dll : warning LNK4088: image > being generated due to /FORCE option; image may not run > Thanks, > Shiju > > On Thu, Nov 3, 2011 at 3:17 PM, JonY wrote: > >> On 11/3/2011 13:04, Shiju Sasi wrote: >> > Hi I build my Windows 32 bit DLL on Vista machine. This DLL works in a >> > browser context to render Video using H264 video. I use x264 and ffmpeg >> > libraries. My deployment can be any Windows machine ( Vista, 7, XP etc) >> > >> > I configured x264 using >> > >> > ./configure --cross-prefix=i686-w64-mingw32- --enable-shared >> > --disable-swscale --disable-ffms --disable-asm --disable-thread >> > >> > Then did the make. >> > >> > Then I configured ffmpeg using. >> > >> > >> > ./configure --enable-cross-compile >> > --cross-prefix=i686-w64-mingw32- --enable-shared --disable-pthreads >> > --arch=x86_32 --enable-postproc --enable-avfilter --disable-armv5te >> > --disable-ffplay --disable-ffserver --disable-ffprobe --disable-doc >> > --disable-debug --disable-encoders --disable-muxers --disable-neon >> > --disable-pic --disable-decoders --enable-decoder=h264 --disable-bsfs >> > --disable-protocols --disable-parsers --enable-parser=h264 >> > --disable-filters --disable-demuxers >> > then did make. >> > >> > Now my application DLL, I built using /MT so as to avoid any CRT mess >> up in >> > the deployed machine. But the build fails with 3 linker errors - >> > >> >> Do not use /MT. use /MD instead, mingw has not been designed to handle >> static CRT since its inception, that is unless MS releases their C >> runtime with an OSS compatible license. >> >> > *unresolved external symbol __imp__toupper , * >> > * >> > >> > unresolved external symbol __imp___fstat, >> > >> > and >> > >> > unresolved external symbol __imp___vsnprintf >> > >> >> Please do not hide any errors and post all of them, eg which object is >> requiring them. >> >> > -- 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
Re: [Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception
On Sun, Nov 6, 2011 at 7:31 PM, Ruben Van Boxem
wrote:
> 2011/11/6 Ozkan Sezer
>>
>> On Sun, Nov 6, 2011 at 3:54 PM, Ruben Van Boxem
>> wrote:
>> > 2011/11/6 Ruben Van Boxem
>> >>
>> >> 2011/11/6 Ozkan Sezer
>> >>>
>> >>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
>> >>> 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
>> >>> > #include
>> >>> >
>> >>> > 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 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.
Re: [Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception
2011/11/6 Ozkan Sezer
> On Sun, Nov 6, 2011 at 3:54 PM, Ruben Van Boxem
> wrote:
> > 2011/11/6 Ruben Van Boxem
> >>
> >> 2011/11/6 Ozkan Sezer
> >>>
> >>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
> >>> 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
> >>> > #include
> >>> >
> >>> > 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 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
Re: [Mingw-w64-public] Possible bug in 64-bit std::thread-enabled 4.7.0 build
Hello List (and Ruben and Kai)!
We got the answer from comp.lang.c++, and it looks like it's
ill-formed code. (See below.)
(But Ruben, your build is still wacky!)
On Sun, Nov 6, 2011 at 10:18 AM, K. Frank wrote:
> Hello Ruben!
> ...
>> and I would like to urge you to put it up on SO nonetheless.
>> Specify platform (size of long, size_t), what you think should happen, and
>> what happens, and just ask for an explanation of he behavior. It's a nice
>> question IMHO, and chances are you'll get your answer fast.
> ...
> Okay, we'll give the experts a crack at this. I've posted the question to
> comp.lang.c++, rather than Stack Overflow, but we should be able to
> find some experts there, as well.
We got a quick answer over at comp.lang.c++
>
>> Ruben
>>
>> PS: send me a link to the question once posted, so I can fix it up a bit if
>> necessary and give you an upvote ;)
>> ...
>
> Okay, here's a link:
>
> groups.google.com/group/comp.lang.c++/browse_thread/thread/ce2528bce8c29935
You can see the discussion at the above link.
To summarize, the problem is in
if (pos != std::string::npos) { // 32-bit unsigned compared
against 64-bit size_t
std::string tmp(m_string.begin(), m_string.begin() + pos + 1);
Once the bad value of pos (unsigned 32-bit -1) leaks through the if
statement, we try to index into m_string with a bad iterator,:
((m_string.begin() + pos) + 1)
My understanding is that creating (or perhaps using) the bad iterator
constitutes undefined behavior, and, in practice, the compiler is probably
overwriting all kinds of things when trying to construct the string tmp.
I will say that I don't see this as a "language-lawyer" problem, but more
of a problem with my less-than-sharp eyes...
> ...
Thanks for everyone's help.
K. Frank
--
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
Re: [Mingw-w64-public] Possible bug in 64-bit std::thread-enabled 4.7.0 build
Hello Ruben! On Sun, Nov 6, 2011 at 7:47 AM, Ruben Van Boxem wrote: > 2011/11/6 K. Frank >> >> Hi Ruben (and Kai)! >> >> On Sat, Nov 5, 2011 at 6:35 PM, Ruben Van Boxem >> wrote: >> > Op 5 nov. 2011 22:58 schreef "K. Frank" het >> > volgende: >> >> ... >> >> On Sat, Nov 5, 2011 at 3:20 PM, Kai Tietz >> >> wrote: >> >> > 2011/11/5 K. Frank : >> >> >> Hello Everyone! >> >> >> >> >> >> I see the same behavior on a couple of other mingw-w64 versions. >> >> >> ... >> >> >> Okay, I tried this on two more compiler versions, and I get the same >> >> >> result, namely that the loop seems to "exit" early. >> >> >> >> >> >> These are two Ozkan Sezer builds: 4.4.5 and 4.5.2: >> >> >> >> >> >> g++ (GCC) 4.4.5 20101001 (release) [svn/rev.164871 - mingw-w64/oz] >> >> >> g++ (GCC) 4.5.2 20101002 (prerelease) [svn/rev.164902 - >> >> >> mingw-w64/oz] >> >> >> ... >> >> >> K. Frank >> >> > >> >> > The only thing it might could be here, is that erase-call raises an >> >> > exception, but why you see the goodbye message here than? >> >> >> >> Yes, I had thought of the exception possibility (although, as you say, >> >> it doesn't really make sense because of the goodbye message). So >> >> I actually put a try block in my test program (in main): >> >> ... >> >> The try wraps the calls to operator<< that trigger the calls to xsputn, >> >> so this would seem to show that no exception is being thrown (as no >> >> "exception caught" message is being printed out). >> > >> > I would take this to stackoverflow.com, try to reduce the code a bit >> > further... There's a lot of language lawyers there that should be able >> > to >> > formulate a correct answer if asked the right question. Be concise but >> > complete ;-) >> > >> > Ruben >> >> ... >> >> K. Frank >> >> I was thinking that because the bug shows up on a number of different >> mingw-w64 g++ versions, perhaps the bug is not mingw-w64-specific, >> but rather in the upstream (64-bit) g++. >> >> I don't have access to a 64-bit linux platform, but I wonder whether the >> same bug would show up when compiling and running the test program >> on linux with 64-bit g++. >> >> Also, I tired compiling the test code with the Comeau online compiler >> and it gave no errors or warnings. (The Comeau online compiler compiles >> code but doesn't link or run it.) (However, if there is some 32-bit / >> 64-bit >> conversion error in the code, and Comeau lives in a 32-bit world, then >> maybe it wouldn't see the problem.) >> >> I've tried to isolate the bug in simpler code, but haven't been able to >> yet. >> I've tried "top down" taking stuff out of the test program. It seems I >> need >> both the xsputn stuff and the while loop with the if statement inside. If >> I >> take too much out, the error goes away. >> >> I've also tried "bottom up" setting up a while loop / if statement, and >> that >> has the same signed / unsigned conversions, and I can't reproduce the >> error that way. (I can get the infinite loop, which is what I believe the >> correct behavior is.) >> >> Any thoughts as to whether this can be reproduced on linux? > > Try ideone.com, Okay, I gave ideone a try. (On the one hand, it's probably less useful than Comeau, because they're running g++ under the hood (rather than a totally independent compiler); on the other hand, it's more useful, because they actually run your code and give you the output.) On both settings (C++ (gcc-4.3.4), and C++0x (gcc-4.5.1)) the code compiles and run correctly, giving the following output: hello... xsputn: top of loop, pos = 0 Message 1 (with '\n')... xsputn: bottom of loop, pos = 24 xsputn: top of loop, pos = 24 xsputn: bottom of loop, pos = -1 xsputn: before return, n = 25, pos = -1 xsputn: top of loop, pos = 0 Message 2 (with '\n')... xsputn: bottom of loop, pos = 24 xsputn: top of loop, pos = 24 xsputn: bottom of loop, pos = -1 xsputn: before return, n = 25, pos = -1 goodbye! However, this test is probably not very informative, because it appears that ideone is using 32-bit g++. For example, ideone's size_t is 32 bits. > and I would like to urge you to put it up on SO nonetheless. > Specify platform (size of long, size_t), what you think should happen, and > what happens, and just ask for an explanation of he behavior. It's a nice > question IMHO, and chances are you'll get your answer fast. Okay, we'll give the experts a crack at this. I've posted the question to comp.lang.c++, rather than Stack Overflow, but we should be able to find some experts there, as well. > Ruben > > PS: send me a link to the question once posted, so I can fix it up a bit if > necessary and give you an upvote ;) > ... Okay, here's a link: groups.google.com/group/comp.lang.c++/browse_thread/thread/ce2528bce8c29935 (Again, it's comp.lang.c++, rather than Stack Overflow.) Thanks again. K. Frank -- RSA(R) Conference 2012 S
Re: [Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception
On Sun, Nov 6, 2011 at 3:54 PM, Ruben Van Boxem
wrote:
> 2011/11/6 Ruben Van Boxem
>>
>> 2011/11/6 Ozkan Sezer
>>>
>>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
>>> 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
>>> > #include
>>> >
>>> > 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 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
Re: [Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception
2011/11/6 Ruben Van Boxem
> 2011/11/6 Ozkan Sezer
>
>> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
>> 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
>> > #include
>> >
>> > 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 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
>> Sav
Re: [Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception
2011/11/6 Ozkan Sezer
> On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
> 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
> > #include
> >
> > 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 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!
>
>
> --
> 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
Re: [Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception
On Sun, Nov 6, 2011 at 3:31 PM, Ruben Van Boxem
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
> #include
>
> 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 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.
--
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
[Mingw-w64-public] winpthreads and shared std::thread "Operation not permitted" exception
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
#include
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 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.
--
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
Re: [Mingw-w64-public] Possible bug in 64-bit std::thread-enabled 4.7.0 build
2011/11/6 K. Frank > Hi Ruben (and Kai)! > > On Sat, Nov 5, 2011 at 6:35 PM, Ruben Van Boxem > wrote: > > Op 5 nov. 2011 22:58 schreef "K. Frank" het > volgende: > >> ... > >> On Sat, Nov 5, 2011 at 3:20 PM, Kai Tietz > wrote: > >> > 2011/11/5 K. Frank : > >> >> Hello Everyone! > >> >> > >> >> I see the same behavior on a couple of other mingw-w64 versions. > >> >> ... > >> >> Okay, I tried this on two more compiler versions, and I get the same > >> >> result, namely that the loop seems to "exit" early. > >> >> > >> >> These are two Ozkan Sezer builds: 4.4.5 and 4.5.2: > >> >> > >> >> g++ (GCC) 4.4.5 20101001 (release) [svn/rev.164871 - mingw-w64/oz] > >> >> g++ (GCC) 4.5.2 20101002 (prerelease) [svn/rev.164902 - > mingw-w64/oz] > >> >> ... > >> >> K. Frank > >> > > >> > The only thing it might could be here, is that erase-call raises an > >> > exception, but why you see the goodbye message here than? > >> > >> Yes, I had thought of the exception possibility (although, as you say, > >> it doesn't really make sense because of the goodbye message). So > >> I actually put a try block in my test program (in main): > >> ... > >> The try wraps the calls to operator<< that trigger the calls to xsputn, > >> so this would seem to show that no exception is being thrown (as no > >> "exception caught" message is being printed out). > > > > I would take this to stackoverflow.com, try to reduce the code a bit > > further... There's a lot of language lawyers there that should be able to > > formulate a correct answer if asked the right question. Be concise but > > complete ;-) > > > > Ruben > >> ... > >> K. Frank > > I was thinking that because the bug shows up on a number of different > mingw-w64 g++ versions, perhaps the bug is not mingw-w64-specific, > but rather in the upstream (64-bit) g++. > > I don't have access to a 64-bit linux platform, but I wonder whether the > same bug would show up when compiling and running the test program > on linux with 64-bit g++. > > Also, I tired compiling the test code with the Comeau online compiler > and it gave no errors or warnings. (The Comeau online compiler compiles > code but doesn't link or run it.) (However, if there is some 32-bit / > 64-bit > conversion error in the code, and Comeau lives in a 32-bit world, then > maybe it wouldn't see the problem.) > > I've tried to isolate the bug in simpler code, but haven't been able to > yet. > I've tried "top down" taking stuff out of the test program. It seems I > need > both the xsputn stuff and the while loop with the if statement inside. If > I > take too much out, the error goes away. > > I've also tried "bottom up" setting up a while loop / if statement, and > that > has the same signed / unsigned conversions, and I can't reproduce the > error that way. (I can get the infinite loop, which is what I believe the > correct behavior is.) > > Any thoughts as to whether this can be reproduced on linux? > Try ideone.com, and I would like to urge you to put it up on SO nonetheless. Specify platform (size of long, size_t), what you think should happen, and what happens, and just ask for an explanation of he behavior. It's a nice question IMHO, and chances are you'll get your answer fast. Ruben PS: send me a link to the question once posted, so I can fix it up a bit if necessary and give you an upvote ;) > Thanks. > > > K. Frank > > > -- > 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
Re: [Mingw-w64-public] Possible bug in 64-bit std::thread-enabled 4.7.0 build
Hi Ruben (and Kai)! On Sat, Nov 5, 2011 at 6:35 PM, Ruben Van Boxem wrote: > Op 5 nov. 2011 22:58 schreef "K. Frank" het volgende: >> ... >> On Sat, Nov 5, 2011 at 3:20 PM, Kai Tietz wrote: >> > 2011/11/5 K. Frank : >> >> Hello Everyone! >> >> >> >> I see the same behavior on a couple of other mingw-w64 versions. >> >> ... >> >> Okay, I tried this on two more compiler versions, and I get the same >> >> result, namely that the loop seems to "exit" early. >> >> >> >> These are two Ozkan Sezer builds: 4.4.5 and 4.5.2: >> >> >> >> g++ (GCC) 4.4.5 20101001 (release) [svn/rev.164871 - mingw-w64/oz] >> >> g++ (GCC) 4.5.2 20101002 (prerelease) [svn/rev.164902 - mingw-w64/oz] >> >> ... >> >> K. Frank >> > >> > The only thing it might could be here, is that erase-call raises an >> > exception, but why you see the goodbye message here than? >> >> Yes, I had thought of the exception possibility (although, as you say, >> it doesn't really make sense because of the goodbye message). So >> I actually put a try block in my test program (in main): >> ... >> The try wraps the calls to operator<< that trigger the calls to xsputn, >> so this would seem to show that no exception is being thrown (as no >> "exception caught" message is being printed out). > > I would take this to stackoverflow.com, try to reduce the code a bit > further... There's a lot of language lawyers there that should be able to > formulate a correct answer if asked the right question. Be concise but > complete ;-) > > Ruben >> ... >> K. Frank I was thinking that because the bug shows up on a number of different mingw-w64 g++ versions, perhaps the bug is not mingw-w64-specific, but rather in the upstream (64-bit) g++. I don't have access to a 64-bit linux platform, but I wonder whether the same bug would show up when compiling and running the test program on linux with 64-bit g++. Also, I tired compiling the test code with the Comeau online compiler and it gave no errors or warnings. (The Comeau online compiler compiles code but doesn't link or run it.) (However, if there is some 32-bit / 64-bit conversion error in the code, and Comeau lives in a 32-bit world, then maybe it wouldn't see the problem.) I've tried to isolate the bug in simpler code, but haven't been able to yet. I've tried "top down" taking stuff out of the test program. It seems I need both the xsputn stuff and the while loop with the if statement inside. If I take too much out, the error goes away. I've also tried "bottom up" setting up a while loop / if statement, and that has the same signed / unsigned conversions, and I can't reproduce the error that way. (I can get the infinite loop, which is what I believe the correct behavior is.) Any thoughts as to whether this can be reproduced on linux? Thanks. K. Frank -- 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
Re: [Mingw-w64-public] error with "#define always_inline __attribute__ ((always_inline))"
On Sat, Nov 5, 2011 at 10:24 PM, Vincent Torri wrote: > > > On Sat, Nov 5, 2011 at 10:40 AM, Ozkan Sezer wrote: > >> However Vincent should note that he should also use underscored >> attribute names in his macro like: >> #define always_inline __attribute__((__always_inline__)) >> > > I actually have 2 questions: > > 1) the gcc documentation does not mention __always_inline__, but just > always_inline: > > http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html > > So is it really safe to use __always_inline__ or should I use it since some > specific version of gcc ? > To my knowledge, the double-underscore attribute names have always been supported to avoid clashes with user macros > 2) The documentation says also : "For functions declared inline, this > attribute inlines the function etc..." > > Should I define the following macro: > > #define ALWAYS_INLINE __attribute__((__always_inline__)) > > or that one (according to the doc) : > > #define ALWAYS_INLINE inline __attribute__((__always_inline__)) > > ? I don't know how you will use your macro, so I cannot have any advice on that > > thank you > > Vincent Torri -- 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
Re: [Mingw-w64-public] error with "#define always_inline __attribute__ ((always_inline))"
On Sun, Nov 6, 2011 at 9:58 AM, Ozkan Sezer wrote:
> On Sat, Nov 5, 2011 at 10:24 PM, Vincent Torri
> wrote:
> >
> >
> > On Sat, Nov 5, 2011 at 10:40 AM, Ozkan Sezer wrote:
> >
> >> However Vincent should note that he should also use underscored
> >> attribute names in his macro like:
> >> #define always_inline __attribute__((__always_inline__))
> >>
> >
> > I actually have 2 questions:
> >
> > 1) the gcc documentation does not mention __always_inline__, but just
> > always_inline:
> >
> > http://gcc.gnu.org/onlinedocs/gcc/Function-Attributes.html
> >
> > So is it really safe to use __always_inline__ or should I use it since
> some
> > specific version of gcc ?
> >
>
> To my knowledge, the double-underscore attribute names have always
> been supported to avoid clashes with user macros
>
ok
>
> > 2) The documentation says also : "For functions declared inline, this
> > attribute inlines the function etc..."
> >
> > Should I define the following macro:
> >
> > #define ALWAYS_INLINE __attribute__((__always_inline__))
> >
> > or that one (according to the doc) :
> >
> > #define ALWAYS_INLINE inline __attribute__((__always_inline__))
> >
> > ?
>
> I don't know how you will use your macro, so I cannot have any advice
> on that
>
ALWAYS_INLINE void fct() { *** }
Vincent Torri
--
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
