Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

[lh mouse]

LRN, the author of the libitm patch of MSYS2 gcc package, suggested disabling 
it:

[22:57:27]  LRN, wasn't you the guy who wrote the enable-libitm patch 
for MSYS2 ?
[22:57:36]  s/wasn't/weren't/
[22:57:42]  that is quite possible
[22:58:02]  possible ? :S
[22:58:07]  I don't remember
[22:58:13]  oh my god.
[22:58:46]  If i did do that, i'm sure it was accompanied by a "I have no 
idea what libitm does, i can only assure you that it compiles" disclaimer :)
[23:00:11]  fair enough. you have answered what I was going to ask. :>
[23:00:59]  no there isn't such a disclaimer.
[23:01:00]  
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-gcc-git/0012-MinGW-w64-Enable-libitm.patch
[23:01:02]  Title: MINGW-packages/0012-MinGW-w64-Enable-libitm.patch at 
master · Alexpux/MINGW-packages · GitHub (at github.com)
[23:01:31]  Sweet! Somebody ate it!
[23:02:57] * mikedld|w (~mikedld|w@128.140.241.11) has joined
[23:02:59]  the disclaimer might have been verbal only
[23:03:12]  i don't usually put stuff into .patch file headers
[23:03:51] * AmineKhaldi has quit (Ping timeout: 480 seconds)
[23:04:10]  Well you should. Otherwise people would turn to you if it 
is broken. And it seems broken now.
[23:04:28]  yep, it was me
[23:05:09]  on 2014-01-21 i've updated gcc-4.8.2 package to the 2nd 
revision. Changelog states, among other things: "Build libatomic, libitm"
[23:05:30] * lh_mouse stretches himself.
[23:07:13]  On 2015-01-07 i've made gcc-4.9.2 package. Changelog states, 
beside the obligatory "Updated from upstream": "Don't build sanitizer and 
libitm (both fail at runtime)"
[23:07:53]  this was also the last gcc package i've made, i've been using 
that build since then
[23:09:06]  Most likely, i've found some example code for libitm, tried it 
out, and it didn't work, which prompted me to not to build libitm anymore
[23:09:15]  I thought you should submit a Pull Request to remove that 
patch, should libitm be broken at runtime.
[23:10:07]  Well, i don't want to shift the blame here, but i'm not really 
involved into MSYS2 development directly
[23:10:55]  I do my own stuff, and then alexey picks it up (usually after 
my notification, sometimes by himself)
[23:11:07]  and i pick up his stuff whenever i update things
[23:11:25]  i guess i never told him about libitm, and he never asked
[23:11:38]  That was the problem, exactly.
[23:12:09]  anyway: Now you know, and knowledge the battle!
[23:12:26]  Would you mind my sending this conversion to MSYS2 ML? 
RiCON is waiting for a solution.
[23:14:16]  feel free to do so
[23:14:24]  Thanks.

--   
Best regards,
lh_mouse
2016-07-26


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

[lh mouse]

I have compiled ffmpeg with LDFLAGS='-static-libgcc -static-libstdc++' and
Stud_PE says ffmpeg.exe doesn't import anything from libitm, nor does it import
anything from libstdc++, libgcc, libiconv, etc.

I also asked it on #mingw-w64 on OFTC and people said it seemed mere
undefined references instead of linking 64-bit and 32-bit code together.

[18:03:22]  ktietz, are you familiar with this error?   
C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x2c):
 relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU1'
[18:13:57]  mooo
[18:15:34]  lh_mouse: add -litm?
[18:16:07]  or maybe its a implicit declaration
[18:16:16]  jon_y, this is a question that was sent to msys2 ML 
yesterday.
[18:16:44]  yeah, doublecheck the source
[18:16:46]  I am curious about the 'relocation truncated' thing.
[18:17:01]  thats noise
[18:17:10]  :<
[18:17:14]  more impotantly - undefined symbol `_ITM_RU1'
[18:18:23]  possibly a mix of libraries which are of different bitnesses
[18:20:50]  adrien, that was also my opinion.
[18:21:05]  It _was_, at least yesterday.
[18:21:42]  it probably prints something like that whenever there is an 
undefined symbol
[18:23:18]  well, what's your command-line?
[18:23:55]  yeah, it something like a symbol which is 0 because it's 
undefined would need to be truncated to fit in a 32-bit relocation
[18:24:36]  the fact that it's undefined is much more important :)
[18:26:19]  lh_mouse this message looks like an undefined symbol
[18:26:52]  so it sounds caused by undefined  symbols in itm.
[18:27:01]  pretty similar issues you can get, if you try to use short 
code-model on x64 in some cases.  but this seems not to be your issue here
[18:27:21]  it was not my issue...
[18:28:04]  the issue here is the pseudo-relocation code. we need to 
create symbols for aliases, which might lead to such messages
[18:29:13]  there is a symbol, but sadly it isn't here for real ... :/

It may have something to do with MSYS2's libitm but I am not sure.

--   
Best regards,
lh_mouse
2016-07-25

-
发件人：Ricardo Constantino <wiia...@gmail.com>
发送日期：2016-07-25 09:30
收件人：lh mouse
抄送：msys2-users,mingw-w64-public
主题：Re: Re: [Msys2-users] Relocation errors when linking with static
 libstdc++ starting with GCC 6 (64-bit only)

Recompiling GCC with
https://github.com/Alexpux/MINGW-packages/pull/1588/commits/ba282a67e971e045131291fd0f21ef786b82b1b1
seems to fix the issue for me.
I don't know enough to be sure this doesn't break anything else. The
alternative would be disabling the patch that enables libitm, but I assumed
just disabling weak references in x86_64 wouldn't remove any feature unlike
the former.


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

[lh mouse]

I have compiled ffmpeg with LDFLAGS='-static-libgcc -static-libstdc++' and
Stud_PE says ffmpeg.exe doesn't import anything from libitm, nor does it import
anything from libstdc++, libgcc, libiconv, etc.

I also asked it on #mingw-w64 on OFTC and people said it seemed mere
undefined references instead of linking 64-bit and 32-bit code together.

[18:03:22]  ktietz, are you familiar with this error?   
C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x2c):
 relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU1'
[18:13:57]  mooo
[18:15:34]  lh_mouse: add -litm?
[18:16:07]  or maybe its a implicit declaration
[18:16:16]  jon_y, this is a question that was sent to msys2 ML 
yesterday.
[18:16:44]  yeah, doublecheck the source
[18:16:46]  I am curious about the 'relocation truncated' thing.
[18:17:01]  thats noise
[18:17:10]  :<
[18:17:14]  more impotantly - undefined symbol `_ITM_RU1'
[18:18:23]  possibly a mix of libraries which are of different bitnesses
[18:20:50]  adrien, that was also my opinion.
[18:21:05]  It _was_, at least yesterday.
[18:21:42]  it probably prints something like that whenever there is an 
undefined symbol
[18:23:18]  well, what's your command-line?
[18:23:55]  yeah, it something like a symbol which is 0 because it's 
undefined would need to be truncated to fit in a 32-bit relocation
[18:24:36]  the fact that it's undefined is much more important :)
[18:26:19]  lh_mouse this message looks like an undefined symbol
[18:26:52]  so it sounds caused by undefined  symbols in itm.
[18:27:01]  pretty similar issues you can get, if you try to use short 
code-model on x64 in some cases.  but this seems not to be your issue here
[18:27:21]  it was not my issue...
[18:28:04]  the issue here is the pseudo-relocation code. we need to 
create symbols for aliases, which might lead to such messages
[18:29:13]  there is a symbol, but sadly it isn't here for real ... :/

It may have something to do with MSYS2's libitm but I am not sure.

--   
Best regards,
lh_mouse
2016-07-25

-
发件人：Ricardo Constantino <wiia...@gmail.com>
发送日期：2016-07-25 09:30
收件人：lh mouse
抄送：msys2-users,mingw-w64-public
主题：Re: Re: [Msys2-users] Relocation errors when linking with static
 libstdc++ starting with GCC 6 (64-bit only)

Recompiling GCC with
https://github.com/Alexpux/MINGW-packages/pull/1588/commits/ba282a67e971e045131291fd0f21ef786b82b1b1
seems to fix the issue for me.
I don't know enough to be sure this doesn't break anything else. The
alternative would be disabling the patch that enables libitm, but I assumed
just disabling weak references in x86_64 wouldn't remove any feature unlike
the former.




--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

[lh mouse]

It looks normal.
I thought it could be caused by linking a 64-bit object file against a 32-bit 
library.
Fortunately, it isn't the case.

FWIW, two months ago I sent a pull request about the GCC relocation bug here:
https://github.com/Alexpux/MINGW-packages/pull/1444
A few days ago on IRC, alexey mentioned that I had forgot something in PKGBUILD 
and he fixed it a little.
I pulled the new script but didn't test it.

I guess it is the removal of the two command line options that might be the 
cause of this problem,
because I don't split packages and the file `libstdc++.a` in question has been 
installed into
a slightly different directory ("C:\MinGW\MSYS2\mingw64\lib\libstdc++.a") and I 
don't have this problem.
But we had better ask alexey for sure.

--   
Best regards,
lh_mouse
2016-07-24

-
发件人：Ricardo Constantino <wiia...@gmail.com>
发送日期：2016-07-24 23:19
收件人：lh mouse,msys2-users,mingw-w64-public
抄送：
主题：Re: [Msys2-users] Relocation errors when linking with static
 libstdc++ starting with GCC 6 (64-bit only)


On 2016-07-24 16:14, lh mouse wrote:
> Try this command and reply with its output:
> 
> objdump -f 
> "C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a"
>  | grep "cow-stdexcept.o"
> 

$ objdump -f 
"C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a"
 | grep "cow-stdexcept.o"
cow-stdexcept.o: file format pe-x86-64



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Msys2-users] Relocation errors when linking with static libstdc++ starting with GCC 6 (64-bit only)

[lh mouse]

Try this command and reply with its output:

objdump -f 
"C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a"
 | grep "cow-stdexcept.o"

--   
Best regards,
lh_mouse
2016-07-24

-
发件人：Ricardo Constantino 
发送日期：2016-07-24 23:10
收件人：msys2-users
抄送：
主题：[Msys2-users] Relocation errors when linking with static libstdc++
 starting with GCC 6 (64-bit only)

Both FFmpeg and mpv when linking with -lstdc++ fail with these exact errors 
when compiling with x86_64-w64-mingw32 GCC 6.1

There errors are only fixed by not including libs which need libstdc++ and use 
exceptions or by reverting to GCC 5.4. Haven't tried not using static 
libstdc++, since I'd prefer not depending on DLLs not included with Windows.

Something like this probably needs to be done in mingw64 as well: 
https://github.com/gcc-mirror/gcc/commit/40c727c8722ab47a821e2fe371f1b6b96be0200d


C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x2c):
 relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU1'
C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x39):
 relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`transaction clone for operator new[](unsigned long long)'
C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z35_txnal_cow_string_C1_for_exceptionsPvPKcS_+0x5d):
 relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`_ITM_memcpyRtWn'
C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z23_txnal_cow_string_c_strPKv+0x1):
 relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z23_txnal_sso_string_c_strPKv+0x1):
 relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z20_txnal_cow_string_D1Pv+0x5):
 relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_Z20_txnal_cow_string_D1Pv+0x1e):
 relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`_ITM_addUserCommitAction'
C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_ZGTtNSt11logic_errorC1EPKc+0x2e):
 relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`_ITM_memcpyRnWt'
C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_ZGTtNSt11logic_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x2e):
 relocation truncated to fit: R_X86_64_PC32 against undefined symbol 
`_ITM_memcpyRnWt'
C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_ZGTtNSt11logic_errorC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE+0x36):
 relocation truncated to fit: R_X86_64_PC32 against undefined symbol `_ITM_RU8'
C:/builds/ab/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0\libstdc++.a(cow-stdexcept.o):(.text$_ZGTtNSt11logic_errorD0Ev+0x1a):
 additional relocation overflows omitted from the output
collect2.exe: error: ld returned 1 exit status


It can be reproduced with:

```
(open mingw64-shell)

export CC=gcc
#MINGW_PREFIX=/mingw64

git clone https://github.com/lachs0r/rubberband.git
cd rubberband
make -j4 PREFIX="$MINGW_PREFIX" install-static

git clone https://git.ffmpeg.org/ffmpeg.git
cd ffmpeg
./configure --enable-librubberband --pkg-config-flags=--static --arch=x86_64 \
--disable-everything --enable-filter=rubberband --enable-gpl
make -j4
```

Should error out in the end, linking ffmpeg.exe.

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Msys2-users mailing list
msys2-us...@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/msys2-users



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the 

Re: [Mingw-w64-public] g++ throwing compiler out with the bathwater

[lh mouse]

The only valid syntax to declare a const reference to an std::string
is 'std::string const & first' or 'const std::string & first'. Putting
the const qualifier elsewhere is an error.

Get a C++ book, teach yourself and stop spamming this list.
Your questions are not only too basic but also off-topic. That is
a warning. I am not willing to be unhelpful but at the moment
the only thing helpful (to this list) is telling you to STFU. If you don't,
someone would have to make it happen by force.


--   
Best regards,
lh_mouse
2016-07-17

-
发件人：Jim Michaels 
发送日期：2016-07-17 01:46
收件人：mingw64 users
抄送：
主题：[Mingw-w64-public] g++ throwing compiler out with the bathwater

build 0708 (internally 0609)

#include 
#include 
#include 
namespace str {
 //string type for S like std::string, std::wstring, etc.
 int compare(std::string& first const, std::string& second const, 
bool iCase=false, size_t firstPos=0) const {
...

}

I had thought the problem might be the & reference, so I dropped those 
and same error message.  g++ seems to now be throwing errors on any 
syntax. it must be royally confused. and it still doesn't like ) on 
functions.


Sat 07/16/2016 
10:37:03.31|C:\Users\Kristina\Desktop\prj\eolconvert\1.0\win|>g++ -v 
-save-temps -DTEST -s -static -lstdc++ -std=c++11 -o 32\eolconvert.exe
eolconvert.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/gcc-7-win32/bin/../libexec/gcc/i686-w64-mingw32/7.0.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: /home/cauchy/vcs/svn/gcc/trunk/configure 
--prefix=/home/cauchy/native/gcc-7-win32 
--with-sysroot=/home/cauchy/native/gcc-7-win32 --build=x
86_64-unknown-linux-gnu --host=i686-w64-mingw32 
--target=i686-w64-mingw32 --disable-multilib --disable-nls 
--disable-win32-registry --disable-gcov-tool --e
nable-checking=release --enable-languages=c,c++,fortran 
--enable-fully-dynamic-string --with-arch=core2 --with-tune=generic
Thread model: win32
gcc version 7.0.0 20160609 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'TEST' '-s' '-static' 
'-std=c++11' '-o' '32\eolconvert.exe' '-mtune=generic' '-march=core2'
  c:/gcc-7-win32/bin/../libexec/gcc/i686-w64-mingw32/7.0.0/cc1plus.exe 
-E -quiet -v -iprefix 
c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/ -isysroot
  c:\gcc-7-win32\bin\../../gcc-7-win32 -U_REENTRANT -D TEST 
eolconvert.cpp -mtune=generic -march=core2 -std=c++11 -fpch-preprocess 
-o eolconvert.ii
ignoring duplicate directory 
"c:/gcc-7-win32/lib/gcc/../../lib/gcc/i686-w64-mingw32/7.0.0/../../../../include/c++/7.0.0"
ignoring duplicate directory 
"c:/gcc-7-win32/lib/gcc/../../lib/gcc/i686-w64-mingw32/7.0.0/../../../../include/c++/7.0.0/i686-w64-mingw32"
ignoring duplicate directory 
"c:/gcc-7-win32/lib/gcc/../../lib/gcc/i686-w64-mingw32/7.0.0/../../../../include/c++/7.0.0/backward"
ignoring duplicate directory 
"c:/gcc-7-win32/lib/gcc/../../lib/gcc/i686-w64-mingw32/7.0.0/include"
ignoring nonexistent directory 
"c:\gcc-7-win32\bin\../../gcc-7-win32/home/cauchy/native/gcc-7-win32/lib/gcc/i686-w64-mingw32/7.0.0/../../../../include"
ignoring duplicate directory 
"c:/gcc-7-win32/lib/gcc/../../lib/gcc/i686-w64-mingw32/7.0.0/include-fixed"
ignoring duplicate directory 
"c:/gcc-7-win32/lib/gcc/../../lib/gcc/i686-w64-mingw32/7.0.0/../../../../i686-w64-mingw32/include"
ignoring nonexistent directory 
"c:\gcc-7-win32\bin\../../gcc-7-win32/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
  
c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/../../../../include/c++/7.0.0
  
c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/../../../../include/c++/7.0.0/i686-w64-mingw32
  
c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/../../../../include/c++/7.0.0/backward
  c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/include
  c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/include-fixed
  
c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/../../../../i686-w64-mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'TEST' '-s' '-static' 
'-std=c++11' '-o' '32\eolconvert.exe' '-mtune=generic' '-march=core2'
  c:/gcc-7-win32/bin/../libexec/gcc/i686-w64-mingw32/7.0.0/cc1plus.exe 
-fpreprocessed eolconvert.ii -quiet -dumpbase eolconvert.cpp 
-mtune=generic -march=co
re2 -auxbase eolconvert -std=c++11 -version -o eolconvert.s
GNU C++11 (GCC) version 7.0.0 20160609 (experimental) (i686-w64-mingw32)
 compiled by GNU C version 7.0.0 20160609 (experimental), GMP 
version 6.1.0, MPFR version 3.1.4-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++11 (GCC) version 7.0.0 20160609 (experimental) (i686-w64-mingw32)
 compiled by GNU C version 7.0.0 20160609 (experimental), GMP 
version 6.1.0, MPFR version 3.1.4-p2, MPC version 1.0.3, isl version 

Re: [Mingw-w64-public] bug in 20160708 x32 x32, STDERR not defined in stdio.h

[lh mouse]

It is not a bug. The macro for the standard error stream is `stderr` rather 
than `STDERR`.

--   
Best regards,
lh_mouse
2016-07-16

-
发件人：Jim Michaels 
发送日期：2016-07-16 11:59
收件人：mingw64 users
抄送：
主题：[Mingw-w64-public] bug in 20160708 x32 x32,
STDERR not defined in stdio.h

#include
fprintf(STDERR, "eolconvert:ERROR: unable to open file 
\"%s\" for input\r\n", "abc");

STDERR is not defined in stdio.h.

also, why does 0708's date say 7.0.0 20160609? I suspect there's a 
version problem.

Fri 07/15/2016 
17:26:18.94|C:\Users\Kristina\Desktop\prj\eolconvert\1.0\win|>g++ -v 
-save-temps -DTEST -s -static -lstdc++ -std=c++11 -o 32\eolconvert.exe
eolconvert.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=c:/gcc-7-win32/bin/../libexec/gcc/i686-w64-mingw32/7.0.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: /home/cauchy/vcs/svn/gcc/trunk/configure 
--prefix=/home/cauchy/native/gcc-7-win32 
--with-sysroot=/home/cauchy/native/gcc-7-win32 --build=x
86_64-unknown-linux-gnu --host=i686-w64-mingw32 
--target=i686-w64-mingw32 --disable-multilib --disable-nls 
--disable-win32-registry --disable-gcov-tool --e
nable-checking=release --enable-languages=c,c++,fortran 
--enable-fully-dynamic-string --with-arch=core2 --with-tune=generic
Thread model: win32
gcc version 7.0.0 20160609 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'TEST' '-s' '-static' 
'-std=c++11' '-o' '32\eolconvert.exe' '-mtune=generic' '-march=core2'
  c:/gcc-7-win32/bin/../libexec/gcc/i686-w64-mingw32/7.0.0/cc1plus.exe 
-E -quiet -v -iprefix 
c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/ -isysroot
  c:\gcc-7-win32\bin\../../gcc-7-win32 -U_REENTRANT -D TEST 
eolconvert.cpp -mtune=generic -march=core2 -std=c++11 -fpch-preprocess 
-o eolconvert.ii
ignoring duplicate directory 
"c:/gcc-7-win32/lib/gcc/../../lib/gcc/i686-w64-mingw32/7.0.0/../../../../include/c++/7.0.0"
ignoring duplicate directory 
"c:/gcc-7-win32/lib/gcc/../../lib/gcc/i686-w64-mingw32/7.0.0/../../../../include/c++/7.0.0/i686-w64-mingw32"
ignoring duplicate directory 
"c:/gcc-7-win32/lib/gcc/../../lib/gcc/i686-w64-mingw32/7.0.0/../../../../include/c++/7.0.0/backward"
ignoring duplicate directory 
"c:/gcc-7-win32/lib/gcc/../../lib/gcc/i686-w64-mingw32/7.0.0/include"
ignoring nonexistent directory 
"c:\gcc-7-win32\bin\../../gcc-7-win32/home/cauchy/native/gcc-7-win32/lib/gcc/i686-w64-mingw32/7.0.0/../../../../include"
ignoring duplicate directory 
"c:/gcc-7-win32/lib/gcc/../../lib/gcc/i686-w64-mingw32/7.0.0/include-fixed"
ignoring duplicate directory 
"c:/gcc-7-win32/lib/gcc/../../lib/gcc/i686-w64-mingw32/7.0.0/../../../../i686-w64-mingw32/include"
ignoring nonexistent directory 
"c:\gcc-7-win32\bin\../../gcc-7-win32/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
  
c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/../../../../include/c++/7.0.0
  
c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/../../../../include/c++/7.0.0/i686-w64-mingw32
  
c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/../../../../include/c++/7.0.0/backward
  c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/include
  c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/include-fixed
  
c:\gcc-7-win32\bin\../lib/gcc/i686-w64-mingw32/7.0.0/../../../../i686-w64-mingw32/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-D' 'TEST' '-s' '-static' 
'-std=c++11' '-o' '32\eolconvert.exe' '-mtune=generic' '-march=core2'
  c:/gcc-7-win32/bin/../libexec/gcc/i686-w64-mingw32/7.0.0/cc1plus.exe 
-fpreprocessed eolconvert.ii -quiet -dumpbase eolconvert.cpp 
-mtune=generic -march=co
re2 -auxbase eolconvert -std=c++11 -version -o eolconvert.s
GNU C++11 (GCC) version 7.0.0 20160609 (experimental) (i686-w64-mingw32)
 compiled by GNU C version 7.0.0 20160609 (experimental), GMP 
version 6.1.0, MPFR version 3.1.4-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++11 (GCC) version 7.0.0 20160609 (experimental) (i686-w64-mingw32)
 compiled by GNU C version 7.0.0 20160609 (experimental), GMP 
version 6.1.0, MPFR version 3.1.4-p2, MPC version 1.0.3, isl version 0.15
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 85f4626b884448f9672ebbd3379aa3ed
eolconvert.cpp:106:146: error: explicit qualification in declaration of 
'std::__cxx11::string str::str_replace(std::__cxx11::string&, 
std::__cxx11::string&
, std::__cxx11::string&, size_t, bool, bool)'
   std::string str::str_replace(std::string& target, std::string& 
findwhat, std::string& replacewith, size_t pos=0, bool iCase=false, bool 
all=true) {
^
eolconvert.cpp: In function 'int main(int, char**)':
eolconvert.cpp:191:12: error: 'STDERR' was not declared in this scope
 

Re: [Mingw-w64-public] Prebuilt GCC binaries 6.1.1 for x86 and x64 with MCF thread model

[lh mouse]

On the same page, the very first clause...
https://github.com/lhmouse/mcfgthread/wiki#introduction

The most important selling point is efficiency of course. With contention of 4 
threads
incrementing the same non-atomic integer protected by a mutex, mcfgthread mutex 
is
10x faster than the libgcc one in gthr-win32.c. mcfgthread condition variable 
is even
more efficient than the libgcc one or winpthread one because of fewer atomic 
operations
and syscalls. It also consumes fewer resources.


--   
Best regards,
lh_mouse
2016-07-13

-
发件人：niXman <i.nix...@autistici.org>
发送日期：2016-07-13 00:34
收件人：mingw-w64-public
抄送：
主题：Re: [Mingw-w64-public] Prebuilt GCC binaries 6.1.1 for x86 and x64
 with MCF thread model

lh mouse 2016-07-12 19:03:
> https://github.com/lhmouse/mcfgthread/wiki#how-to-integrate-with-gcc
> 
> Thanks for your interest. :joy:

In what's the difference between winpthreads and mcfgthread?
I want to understand why I should use mcfgthread...


-- 
Regards, niXman
___
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Prebuilt GCC binaries 6.1.1 for x86 and x64 with MCF thread model

[lh mouse]

https://github.com/lhmouse/mcfgthread/wiki#how-to-integrate-with-gcc

Thanks for your interest. :joy:

--   
Best regards,
lh_mouse
2016-07-13

-
发件人：niXman <i.nix...@autistici.org>
发送日期：2016-07-13 00:01
收件人：mingw-w64-public
抄送：
主题：Re: [Mingw-w64-public] Prebuilt GCC binaries 6.1.1 for x86 and x64
 with MCF thread model

lh mouse 2016-07-12 18:53:
> Hello everyone,

Hi,

>   I have been bootstrapping GCC with MCF thread model for months and I
> think it is
> time to make it known. Tests and reports are welcome.
> 
> Packages of prebuilt binaries can be found here:
>   http://96.44.178.21/gcc-mcf/
> The part in the back of a file name is the SHA-1 checksum of that file.
> 
> Brief
> 0) GCC version
>These packages are usually built from the HEAD of the GCC major
> version branch
>that it belonds to. For example, GCC 6.1.1 is built from 
> gcc-6-branch.
> 1) Languages
>Only C, C++ and LTO are enabled.
> 2) Binutils, mcfgthread and others
>These packages include the latest mcfgthread library from
>https://github.com/lhmouse/mcfgthread.
>These packages include the latest binutils and GDB from MSYS2 
> sources.
> 
> Advantage
> 0) Fast interprocess synchronization primitives, which GCC libraries
> also make use of.
> 1) Availability of C++11 thread from libstdc++.
> 2) Partially standard-conforming C11 thread header 
> .
>(Functions required by ISO C are defined as macros. You must not
> #undef them or
>declare these functions manually, otherwise you may get undefined
> references.)
> 


Where can I find the man about how to build gcc with mcfgthread?

Thanks.


-- 
Regards, niXman
___
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Prebuilt GCC binaries 6.1.1 for x86 and x64 with MCF thread model

[lh mouse]

Hello everyone,
  I have been bootstrapping GCC with MCF thread model for months and I think it 
is
time to make it known. Tests and reports are welcome.

Packages of prebuilt binaries can be found here:
  http://96.44.178.21/gcc-mcf/
The part in the back of a file name is the SHA-1 checksum of that file.

Brief
0) GCC version
   These packages are usually built from the HEAD of the GCC major version 
branch
   that it belonds to. For example, GCC 6.1.1 is built from gcc-6-branch.
1) Languages
   Only C, C++ and LTO are enabled.
2) Binutils, mcfgthread and others
   These packages include the latest mcfgthread library from
   https://github.com/lhmouse/mcfgthread.
   These packages include the latest binutils and GDB from MSYS2 sources.

Advantage
0) Fast interprocess synchronization primitives, which GCC libraries also make 
use of.
1) Availability of C++11 thread from libstdc++.
2) Partially standard-conforming C11 thread header .
   (Functions required by ISO C are defined as macros. You must not #undef them 
or
   declare these functions manually, otherwise you may get undefined 
references.)

--
Best regards,
lh_mouse
2016-07-12


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Confirmation of a potential bug of g++ 6.1 targeting i686 requested

[lh mouse]

__builtin_memcpy() works fine there without any ICE.

```
E:\Desktop>cat test.cpp
auto p = &__builtin_memcpy;

E:\Desktop>gcc test.cpp -c

E:\Desktop>
```
--   
Best regards,
lh_mouse
2016-07-05

-
发件人：NightStrike 
发送日期：2016-07-05 04:19
收件人：mingw-w64-public
抄送：
主题：Re: [Mingw-w64-public] Confirmation of a potential bug of g++ 6.1
 targeting i686 requested

What happens if you use the built in version?


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Confirmation of a potential bug of g++ 6.1 targeting i686 requested

[lh mouse]

Have you guys got g++ 6.1? I am now suffering from an ICE, but
I am not sure whether it is a bug of GCC. I am looking forward to
your opinions. If this is indeed a GCC bug I will file it soon.

** Note: the function `memcpy` is declared manually to avoid
#include'ing any system headers. The prototype MUST match
the one in the standard library. Renaming it or changing its
parameters is not allowed in order to reproduce the ICE. **
```
D:\Desktop>cat test.cpp
extern "C" void *__attribute__((__cdecl__)) memcpy(void *, const void *, 
unsigned);
auto p = 

D:\Desktop>i686-w64-mingw32-gcc test.cpp
test.cpp:2:11: internal compiler error: Segmentation fault
 auto p = 
   ^~

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.

test.cpp:2:11: internal compiler error: Aborted

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
i686-w64-mingw32-gcc: internal compiler error: Aborted (program cc1plus)
```

--
Best regards,
lh_mouse
2016-07-02


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Proposal for a C11 header and announcement of mcfgthread, a library that implements efficient C11 and C++11 thread support without using winpthread

[lh mouse]

Yes. There are two major reasons at the moment:

0. The gthread and c11 thread use global BSTs to translate thread IDs to HANDLEs
upon *_join() or *_detach() calls, which would be problematic if mcfgthread is 
linked
statically, since each dynamic library as well as the executable is going to 
have
separated maps, and calls to such functions have to be done in the same module
that has created the thread.

1. It is essential to use the DllMain() function to clean up TLS objects and 
invoke 
thread exit callbacks. Without a dynamic library (for example, in the mingw-64 
case),
a TLS callback  is an option but It requires an IMAGE_TLS_DIRECTORY to work. 
The mingw-w64 CRT places it in one of the startup files (crt?.o). It is also 
possible
to place it in a static library then reference it somewhere in the startup 
files (if it is not
referenced the linker would ignore it or strip it). In both cases the startup 
code 
has to be modified which requires extra inter-project work that I am not very 
willing to
bother myself to do.

--   
Best regards,
lh_mouse
2016-06-29

-
发件人：Norbert Pfeiler 
发送日期：2016-06-29 04:53
收件人：mingw-w64-public
抄送：
主题：Re: [Mingw-w64-public] Proposal for a C11 header and announcement
 of mcfgthread,
 a library that implements efficient C11 and C++11 thread support without
 using winpthread

Hi, sorry for being so late.
I welcome a proper native thread implementation for windows gcc. I have one
point to address:
I like the fact that i can easily build static executables with mingw-w64.
In a few statements it was suggested that this will not be possible for
mcfgthread but i didn’t come across an explanation why.
Could you elaborate on that?


--
Attend Shape: An AT Tech Expo July 15-16. Meet us at AT Park in San
Francisco, CA to explore cutting-edge tech and listen to tech luminaries
present their vision of the future. This family event has something for
everyone, including kids. Get more information and register today.
http://sdm.link/attshape
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Proposal for a C11 header and announcement of mcfgthread, a library that implements efficient C11 and C++11 thread support without using winpthread

[lh mouse]

> Is this set in stone, or is it foreseen to change it to a more liberal 
> licence?
The choice of that license was an ... accident. XD XD XD
Since the library is expected to be linked dynamically it shouldn't matter 
much. If you consider it problematic, please let me know.

> Another question is: is it still possible to use pthreads (via winpthreads)
> if gcc is configured with --enable-threads=mcf?
I don't think pthread_*() functions would break, but they will not work with 
threads created with thrd_create() or std::thread() which would not be created 
via pthread_create(), apparently.
Certain construction of GCC and GCC libraries, for example, `__thread`, the C11 
`_Thread_local`, the C++11 `thread_local` and the C++ exception handler, 
requires a gthread library to work (this is usually done with a header that 
redirects __gthread calls to other libraries such as winpthread or the 
gthr-win32 one in libgcc). 

> and finally: is it really necessary to rely on "undocumented NT system
> calls for efficiency reasons"?
All efforts have been made to make **little cost** mutexes and condition 
variables - they consume no system resources except the bytes where they reside 
in.
It isn't necessary, only if we drop WIndows 7 support, because Microsoft has 
plagiarized the Linux futex APIs somehow: 
https://msdn.microsoft.com/en-us/library/windows/desktop/hh706898(v=vs.85).aspx 
(Note that these APIs are available only since Windows 8.)
Windows 7 has the awesome SRW locks and condition variables, which, as usual, 
are over-specific for Microsoft people's own usage. Their SRW locks do not 
support timed waits and their condition variables do not support any mutexes 
other than SRW locks and critical sections.
The keyed event APIs (http://locklessinc.com/articles/keyed_events/) are 
undocumented but turn out to be much powerful. If Microsoft people haven't 
implemented timed mutexes or generic condition variables, then it is we that 
should implement them.

--   
Best regards,
lh_mouse
2016-06-20

-
发件人：Carl Kleffner <cmkleff...@gmail.com>
发送日期：2016-06-20 19:29
收件人：mingw-w64-public
抄送：
主题：Re: [Mingw-w64-public] Proposal for a C11 header and announcement
 of mcfgthread,
 a library that implements efficient C11 and C++11 thread support without
 using winpthread

Hi,

most of the mcfgthread code is LGPL licenced (MCFLicense.txt
<https://github.com/lhmouse/mcfgthread/blob/master/MCFLicense.txt>). Is
this set in stone, or is it foreseen to change it to a more liberal licence?

Another question is: is it still possible to use pthreads (via winpthreads)
if gcc is configured with --enable-threads=mcf?

and finally: is it really necessary to rely on "undocumented NT system
calls for efficiency reasons"?

Just a few points that come into my mind after a quick scan of your
repository. The idea to overcome the schism of mingw-w64 thread
configurations is really great.

Regards

Carl


2016-06-18 21:10 GMT+02:00 lh mouse <lh_mo...@126.com>:

> Hello everyone,
>
> It is with great honor that I bring you the C11-conforming header for
> thread support of mcfgthread, c11thread.h:
> https://github.com/lhmouse/mcfgthread/blob/master/src/env/c11thread.h
> All headers in the mcfgthread project have been put into the public domain.
>
> As JonY suggested a few days ago, it would be nice for mingw-w64 to have
> C11 thread support.
> This announcement is not only a call for testers, but also a proposal for
> a C11 header for mingw-w64. We can have both C11 and C++11 threads from
> today.
>
> The following code illustrates how to use C11 threads:
> ```
> E:\Desktop>expand -t4 test.c
> #include 
> #include 
> #include 
>
> int thread_proc(void *param){
> printf("thread running: tid = %u, param = %p\n",
> (unsigned)thrd_current(), param);
> for(int i = 0; i < 5; ++i){
> printf("thread going to sleep for one second...\n");
> struct timespec ts;
> ts.tv_sec = 1;
> ts.tv_nsec = 0;
> thrd_sleep(, 0);
> }
> int exit_code = 67890;
> printf("thread exiting: exit_code = %d\n", exit_code);
> return exit_code;
> }
>
> int main(){
> thrd_t tid;
> int err;
> if((err = thrd_create(, _proc, (void *)0x12345)) !=
> thrd_success){
> printf("thrd_create() returned %d\n", err);
> abort();
> }
> printf("created thread: tid = %u\n", (unsigned)tid);
> int exit_code;
> if((err = thrd_join(tid, _code)) != thrd_success){
> printf("thrd_join() returned %d\n", err);
> abort();
> }
> printf("joined thread: exit_code = %d\n", exit_code);
> }
>
&

[Mingw-w64-public] Proposal for a C11 header and announcement of mcfgthread, a library that implements efficient C11 and C++11 thread support without using winpthread

[lh mouse]

Hello everyone,

It is with great honor that I bring you the C11-conforming header for thread 
support of mcfgthread, c11thread.h:
https://github.com/lhmouse/mcfgthread/blob/master/src/env/c11thread.h
All headers in the mcfgthread project have been put into the public domain.

As JonY suggested a few days ago, it would be nice for mingw-w64 to have C11 
thread support.
This announcement is not only a call for testers, but also a proposal for a C11 
header for mingw-w64. We can have both C11 and C++11 threads from today.

The following code illustrates how to use C11 threads:
```
E:\Desktop>expand -t4 test.c
#include 
#include 
#include 

int thread_proc(void *param){
printf("thread running: tid = %u, param = %p\n", (unsigned)thrd_current(), 
param);
for(int i = 0; i < 5; ++i){
printf("thread going to sleep for one second...\n");
struct timespec ts;
ts.tv_sec = 1;
ts.tv_nsec = 0;
thrd_sleep(, 0);
}
int exit_code = 67890;
printf("thread exiting: exit_code = %d\n", exit_code);
return exit_code;
}

int main(){
thrd_t tid;
int err;
if((err = thrd_create(, _proc, (void *)0x12345)) != 
thrd_success){
printf("thrd_create() returned %d\n", err);
abort();
}
printf("created thread: tid = %u\n", (unsigned)tid);
int exit_code;
if((err = thrd_join(tid, _code)) != thrd_success){
printf("thrd_join() returned %d\n", err);
abort();
}
printf("joined thread: exit_code = %d\n", exit_code);
}

E:\Desktop>gcc test.c -std=c11 -Wall -Wextra -pedantic -lmcfgthread

E:\Desktop>a.exe
created thread: tid = 9876
thread running: tid = 9876, param = 00012345
thread going to sleep for one second...
thread going to sleep for one second...
thread going to sleep for one second...
thread going to sleep for one second...
thread going to sleep for one second...
thread exiting: exit_code = 67890
joined thread: exit_code = 67890

E:\Desktop>
```

In order to use C++11 std::thread (as well as std::mutex, 
std::condition_variable, etc) you must rebuild GCC and its libraries.
A few instructions can be found here: https://github.com/lhmouse/mcfgthread/wiki


--
Best regards,
lh_mouse
2016-06-19


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://sdm.link/zohomanageengine
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Autotools & git

[lh mouse]

Lack of a running `configure` script might results in the following output in 
your user's terminal:
(This is partially a joke. So please enjoy.)

---
LH_Mouse@LH-PC  /e/Desktop/gcc
$ autoreconf -i
configure.ac:33: error: Please use exactly Autoconf 2.64 instead of 2.69.
config/override.m4:12: _GCC_AUTOCONF_VERSION_CHECK is expanded from...
configure.ac:33: the top level
autom4te: /usr/bin/m4 failed with exit status: 1
aclocal-1.15: error: echo failed with exit status: 1
autoreconf: aclocal failed with exit status: 1

LH_Mouse@LH-PC  /e/Desktop/gcc

---




--   
Best regards,
lh_mouse
2016-06-07

-
发件人：Hugo Beauzée-Luyssen 
发送日期：2016-06-07 00:37
收件人：mingw-w64-public@lists.sourceforge.net
抄送：
主题：[Mingw-w64-public] Autotools & git

Hi,

I'm wondering about the rational for having all autotools generated 
files commited to the git repository.
Is there a specific reason for that? Or would it be OK to provide a 
patch that adds a bootstrap script for all project & removes the said 
generated files?

Regards,

--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
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, pthread_setschedparam, and detached threads

[lh mouse]

Note that in most cases threads other than the one calling `pthread_detach()` 
can terminate at anytime. After a call `pthread_detach()`, if the thread 
terminates, its resources are freed automatically, rendering the `pthread_t` no 
longer valid. It is impossible to tell whether a `pthread_t` is designating a 
thread that has terminated. It may even be designating a thread that is 
different from the one the user expects because thread IDs can be reused.
By calling `pthread_detach()` on a `pthread_t` you _semantically_ destroy/close 
it and should not use it any more.

--   
Best regards,
lh_mouse
2016-06-01

-
发件人："Burkhardt, Glenn BUTAS" 
发送日期：2016-05-31 23:11
收件人：mingw-w64-public@lists.sourceforge.net
抄送：
主题：[Mingw-w64-public] winpthreads, pthread_setschedparam,
and detached threads

The way the winpthreads code is writing, the Windows handle for the thread is 
cleared when the thread is made detached.  That means that the 
pthread_setschedparam() call can't work.  So thread priorities for detached 
threads can only be set once, at thread creation, before the thread is 
detached, or as part of the pthread_create() call.

Is there a reason for this?  For me, it's unexpected behavior.


--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity 
planning reports. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Need a prebuild MinGW-w64 with configuration of "--enable-nls"

[lh mouse]

Your attachment seemed swallowed.

Anyway, if you have a problem about MSYS2 patches or packages you can open an 
issue or pull request on GitHub.

--   
Best regards,
lh_mouse
2016-05-13

-
发件人：hua andy 
发送日期：2016-05-12 00:50
收件人：mingw-w64-public
抄送：
主题：Re: [Mingw-w64-public] Need a prebuild MinGW-w64 with configuration
 of "--enable-nls"

I'm  apply msys2's patches to gettext on i686-w64-mingw32, the test files
uploads in email attachment.
extract password : test


--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] ignoring missing symbols doesn't seem to work

[lh mouse]

Usually a static archive (.a file) is created with 'ar' rather than 'g++'.

To create an object file (.o file) that can be linked later on, use the 
following command:
  ld -r -o  
I never use gcc/g++ to do that.


--   
Best regards,
lh_mouse
2016-05-11

-
发件人：Tamir Duberstein 
发送日期：2016-05-10 23:57
收件人：mingw-w64-public
抄送：
主题：[Mingw-w64-public] ignoring missing symbols doesn't seem to work

Hello!

I've been attempting to cross-compile CockroachDB to Windows using
mingw-w64. The compilation strategy used for CockroachDB involves
producing static archives with missing symbols (this is due to how
golang's tooling compiles c/c++ code).

In our linux builds, we pass `-Wl,--unresolved-symbols=ignore-all` to
the compiler to silence these unresolved symbols warnings in our
intermediate static archives - however, it seems that mingw-w64's g++
binary (`x86_64-w64-mingw32-g++-posix` is the one I've tested) doesn't
respect this flag.

Does anyone know why this might be, or where to begin investigating?

More detail is here:
https://github.com/karalabe/xgo/issues/26#issuecomment-214521117

Our build output  ends up with:
```
x86_64-w64-mingw32-g++-posix -I . -m64 -mthreads -fmessage-length=0
-Iinternal -Iinternal/include -Iinternal/db -Iinternal/util
-Iinternal/utilities/merge_operators/string_append
-I../../cockroachdb/c-snappy/internal -DNDEBUG -DSNAPPY -DOS_WIN -I
$WORK/github.com/cockroachdb/c-rocksdb/_obj/ -D_WIN32_WINNT=0x0600
-std=c++11 -fno-omit-frame-pointer -momit-leaf-frame-pointer -o
$WORK/github.com/cockroachdb/c-rocksdb/_obj/port_platform.cc.o -c
./port_platform.cc
x86_64-w64-mingw32-g++-posix -I . -m64 -mthreads -fmessage-length=0 -o
$WORK/github.com/cockroachdb/c-rocksdb/_obj/_cgo_.o
$WORK/github.com/cockroachdb/c-rocksdb/_obj/_cgo_main.o  -g -O2 -Wl,--unresolved-symbols=ignore-all -lrpcrt4
# github.com/cockroachdb/c-rocksdb
/tmp/go-build123696693/github.com/cockroachdb/c-rocksdb/_obj/internal_table_block_based_table_builder.cc.o:internal_table_block_based_table_builder.cc:(.text$_ZN7rocksdb15Snappy_CompressERKNS_18CompressionOptionsEPKcyPSs[_ZN7rocksdb15Snappy_CompressERKNS_18CompressionOptionsEPKcyPSs]+0x20):
undefined reference to `snappy::MaxCompressedLength(unsigned long
long)'
/tmp/go-build123696693/github.com/cockroachdb/c-rocksdb/_obj/internal_table_block_based_table_builder.cc.o:internal_table_block_based_table_builder.cc:(.text$_ZN7rocksdb15Snappy_CompressERKNS_18CompressionOptionsEPKcyPSs[_ZN7rocksdb15Snappy_CompressERKNS_18CompressionOptionsEPKcyPSs]+0x5a):
undefined reference to `snappy::RawCompress(char const*, unsigned long
long, char*, unsigned long long*)'
/tmp/go-build123696693/github.com/cockroachdb/c-rocksdb/_obj/internal_table_format.cc.o:internal_table_format.cc:(.text$_ZN7rocksdb28Snappy_GetUncompressedLengthEPKcyPy[_ZN7rocksdb28Snappy_GetUncompressedLengthEPKcyPy]+0x27):
undefined reference to `snappy::GetUncompressedLength(char const*,
unsigned long long, unsigned long long*)'
/tmp/go-build123696693/github.com/cockroachdb/c-rocksdb/_obj/internal_table_format.cc.o:internal_table_format.cc:(.text$_ZN7rocksdb17Snappy_UncompressEPKcyPc[_ZN7rocksdb17Snappy_UncompressEPKcyPc]+0x27):
undefined reference to `snappy::RawUncompress(char const*, unsigned
long long, char*)'
collect2: error: ld returned 1 exit status
2016/04/25 17:01:39 Failed to cross compile package: exit status 2.
```

Thanks in advance for your help!

--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Need a prebuild MinGW-w64 with configuration of "--enable-nls"

[lh mouse]

You are sending to the wrong address. :>

Long long ago, the MinGW team did have a toolchain with NLS enabled.
I didn't spend much time with it, but it indicated that gettext did work on 
Windows.

Maybe you can try this one: 
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gettext
Please let me know whether you succeed or not.
If you have a specific problem about that repository you can open an issue or 
send a mail to the MSYS2 mailing list.


--   
Best regards,
lh_mouse
2016-05-10

-
发件人：hua andy <hua.a...@gmail.com>
发送日期：2016-05-10 18:27
收件人：mingw-w64-public
抄送：
主题：Re: [Mingw-w64-public] Need a prebuild MinGW-w64 with configuration
 of "--enable-nls"

gnu gettext在windows平台上存在问题, 开启nls选项没什么用.需要对libgettext做relocate修复.
我编译过enable-nls的版本,gcc有很多输出没法显示.后来发现是对vfprintf函数的支持问题,但我没法修复这个问题.

2016-05-10 15:50 GMT+08:00 lh mouse <lh_mo...@126.com>:

> You might want to build one yourself. You can find something useful here:
> https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gcc-git
>
> Generally I wouldn't recommend use of NLS, because it turns out to be hard
> to get anything useful by feeding a search engine with any non-English
> error messages (and by feeding Baidu with any error messages. You don't use
> Baidu, do you? XD), especially when they contain terms. (Well, how would
> you distinguish 'specifier', 'modifier' and 'qualifier' from each other?)
> Moreover, if you are lucky enough to find a GCC bug and you want to either
> share it with other people or file it to gcc bugzilla, it is the localized
> error messages that will be the barrier between you and the community.
>
> --
> Best regards,
> lh_mouse
> 2016-05-10
>
> -
> 发件人："LI An-Bang" <anban...@qq.com>
> 发送日期：2016-05-10 14:34
> 收件人：mingw-w64-public
> 抄送：
> 主题：[Mingw-w64-public] Need a prebuild MinGW-w64 with configuration of
> "--enable-nls"
>
> Hi, all,
>
>
> I am a Chinese user of MinGW on Windows. I want GCC to write out compiling
> messages in Chinese. After some search and analysis on Internet, I realized
> that I should enable MinGW's national language support(NLS). I typed
> command "gcc -v", and noticed that gcc 5.3.0 in MinGW-w64 was configured
> with "--disable-nls".
>
>
> I want to get a prebuild toolchain having this feature enabled, i.e. with
> configuration of "--enable-nls". Could any one tell me where to get such a
> version?
>
>
>
> Thanks in advance.
>
>
> --
> LI AnBang
>  Physics Department, Central China Normal University, China
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
>
> --
> Mobile security can be enabling, not merely restricting. Employees who
> bring their own devices (BYOD) to work are irked by the imposition of MDM
> restrictions. Mobile Device Manager Plus allows you to control only the
> apps on BYO-devices by containerizing them, leaving personal data
> untouched!
> https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Mobile security can be enabling, not merel

Re: [Mingw-w64-public] Need a prebuild MinGW-w64 with configuration of "--enable-nls"

[lh mouse]

You might want to build one yourself. You can find something useful here: 
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gcc-git

Generally I wouldn't recommend use of NLS, because it turns out to be hard to 
get anything useful by feeding a search engine with any non-English error 
messages (and by feeding Baidu with any error messages. You don't use Baidu, do 
you? XD), especially when they contain terms. (Well, how would you distinguish 
'specifier', 'modifier' and 'qualifier' from each other?)
Moreover, if you are lucky enough to find a GCC bug and you want to either 
share it with other people or file it to gcc bugzilla, it is the localized 
error messages that will be the barrier between you and the community.

--   
Best regards,
lh_mouse
2016-05-10

-
发件人："LI An-Bang" 
发送日期：2016-05-10 14:34
收件人：mingw-w64-public
抄送：
主题：[Mingw-w64-public] Need a prebuild MinGW-w64 with configuration of
"--enable-nls"

Hi, all,


I am a Chinese user of MinGW on Windows. I want GCC to write out compiling 
messages in Chinese. After some search and analysis on Internet, I realized 
that I should enable MinGW's national language support(NLS). I typed command 
"gcc -v", and noticed that gcc 5.3.0 in MinGW-w64 was configured with 
"--disable-nls".


I want to get a prebuild toolchain having this feature enabled, i.e. with 
configuration of "--enable-nls". Could any one tell me where to get such a 
version?



Thanks in advance.


--
LI AnBang
 Physics Department, Central China Normal University, China
--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public