A user of the R programming language has reported that std::regex
causes a hang for certain regular expressions when running in Japanese
locale. I was able to reproduce this both with our production
toolchain (mingw-w64 v5 + gcc 8) as well as the latest msys2
toolchains.
Is this a bug in mingw-w64
On Mon, Jun 29, 2020 at 8:12 PM Martin Storsjö wrote:
>
> On Mon, 29 Jun 2020, Jeroen Ooms wrote:
>
> > Hi Alexandre,
> >
> > Where can I learn more about what native windows TLS means? We have
> > been been building the msys2 version of libcurl using native win
Hi Alexandre,
Where can I learn more about what native windows TLS means? We have
been been building the msys2 version of libcurl using native windows
schannel TLS backend for years, how is this different from windows
native TLS?
On Tue, Jun 23, 2020 at 8:36 PM Alexandre Pereira Nunes
wrote:
>
I'm worried about this warning that we see when linking intel-tbb:
task.o: duplicate section `.rdata$_ZTIN3tbb4taskE[__ZTIN3tbb4taskE]'
has different size
arena.o: duplicate section
`.rdata$_ZTIN3tbb4taskE[__ZTIN3tbb4taskE]' has different size
scheduler.o: duplicate section
`.rdata$_ZTIN3tbb
Here it is:
https://github.com/r-windows/mingw-packages/blob/master/mingw-w64-crt-git/mkgmtime.diff
On Sun, Jul 8, 2018 at 2:56 AM, JonY via Mingw-w64-public
wrote:
> On 07/07/2018 09:31 AM, Jeroen Ooms wrote:
>> This patch is for v5 to fix: https://sourceforge.net/p/mingw-w64
This patch is for v5 to fix: https://sourceforge.net/p/mingw-w64/bugs/473/
It has been fixed in master already, but I would really like to make
this work in v5.
Thank you!
--
Check out the vibrant tech community on one of
On Fri, Jun 22, 2018 at 4:14 PM, Jeroen Ooms wrote:
> On Fri, Jun 22, 2018 at 1:49 AM, JonY via Mingw-w64-public
> wrote:
>> On 06/21/2018 11:55 AM, Jeroen Ooms wrote:
>>> Thanks for the reply. Is there any chance you could backport those
>>> into v5? I built my
On Fri, Jun 22, 2018 at 1:49 AM, JonY via Mingw-w64-public
wrote:
> On 06/21/2018 11:55 AM, Jeroen Ooms wrote:
>> Thanks for the reply. Is there any chance you could backport those
>> into v5? I built my entire build infrastructure on v5.0.4 now...
>>
>> Sorry
On Fri, Jun 22, 2018 at 1:49 AM, JonY via Mingw-w64-public
wrote:
> On 06/21/2018 11:55 AM, Jeroen Ooms wrote:
>> Thanks for the reply. Is there any chance you could backport those
>> into v5? I built my entire build infrastructure on v5.0.4 now...
>>
>> Sorry
After upgrading from gcc 4.9.3 (mingw-w64 v3) to gcc 8.1.0 (mingw-w64
v5.0.4) I am getting a linking error on i686 when building libuv. The
x86_64 architecture is still fine.
C:/rtools40/mingw32/bin/g++ -shared -s -static-libgcc -o httpuv.dll
tmp.def RcppExports-legacy.o RcppExports.o callback.o
On Sun, Jun 3, 2018 at 10:47 AM, Liu Hao wrote:
> 在 2018/6/2 20:45, Jeroen Ooms 写道:
>> Hi!
>>
>> First of all: thanks for all the fantastic work on mingw-w64.
>>
>> Are there any plans to tag a mingw-w64 release for use with gcc-8?
>> Both the v5 and v6
Hi!
First of all: thanks for all the fantastic work on mingw-w64.
Are there any plans to tag a mingw-w64 release for use with gcc-8?
Both the v5 and v6 branch seem to work with gcc-8.1.0 but
unfortunately the latest stable 5.0.3 does not. The toolchain I am
building should be reproducible, so I w
Trying to build opendap [1] but the configure script can't find uuid.h:
checking uuid/uuid.h usability... no
checking uuid/uuid.h presence... no
checking for uuid/uuid.h... no
checking uuid.h usability... no
checking uuid.h presence... no
checking for uuid.h... no
configure: error: Could not find
Somebody has reported unexpected results of tanh() on the r-devel mailing list:
https://stat.ethz.ch/pipermail/r-devel/2017-March/073914.html
I was able to reproduce the problem on msys2 with gcc 6.3:
#include
#include
#include
int main(){
std::cout << std::fixed;
std::comp
On Tue, Sep 6, 2016 at 8:50 PM, Stefan Weil wrote:
> I suggest using the ANSI format specifiers ("%lld" is correct in
> your example) and telling the compiler that you do so. Add
> -D__USE_MINGW_ANSI_STDIO=1 to the compiler options
> (or define that macro before including any header files).
>
> If
How to print a 'long long int' so that it compiles
without -pedantic warnings? I tried:
long long int number
char i[32];
sprintf(i, "%lld", number);
But this gives: warning: unknown conversion type character 'l' in format. I
also tried:
sprintf(i, "%I64d", number);
But this gives: warn
I ran into exactly this issue when building protobuf 3.0.0. One of the
checks freezes. Ended up not running checks and the lib works fine.
On Mon, Aug 15, 2016 at 12:29 PM, Mario Emmenlauer
wrote:
>
> Dear All,
>
> I don't know how/where to report this or how to debug the issue,
> please let m
I need to build win32 librasqal (e.g. mingw-w64-rasqal) on mingw-w64
with gcc 4.9.3. The library is building fine with gcc 4.6.3 and gcc 5,
but on the gcc 4.9.3 toolchain I get a linking error (only on win32):
undefined reference to `_mkgmtime'
It looks like even though _mkgmtime is declared
I'm trying to build a 32 bit native compiler using the cross compiler
that ships with Debian Jessie. Ideally we would like:
- gcc 4.9.2
- multilib
- sjsl exceptions
The dockerfile is here [1] and to see the latest build attempts on my
dockerhub [2]. The current script fails make gcc-all with:
Hello! I am new to mingw-w64 and having some difficulty getting up to speed.
I would like to build a native mingw-w64 for win32 (i686-w64-mingw32)
with support for multilib and at least fortran, c and c++. If possible
I would like to build it as much as possible using sources and the
standard ming
20 matches
Mail list logo
