在 2023/2/28 22:17, Luca Bacci 写道:
Hello, I was wondering whether all the parts of -ffast-math are supported
on mingw-w64. For example, does -fno-math-errno need appropriate support
from the libc, beyond the compiler? My understanding is that mingw-gcc uses
the math functions from the MSVCRT /
Hello, I was wondering whether all the parts of -ffast-math are supported
on mingw-w64. For example, does -fno-math-errno need appropriate support
from the libc, beyond the compiler? My understanding is that mingw-gcc uses
the math functions from the MSVCRT / UCRT library, but those won't support
在 2021-05-02 13:06, Biswapriyo Nath 写道:
Some projects like ruby, perl, gnulib etc. uses the iobuf and ioinfo
structures heavily. Is it possible to add those structure definition
for UCRT here? Just asking :)
The structure is only meaningful for inline functions or macros such as
Some projects like ruby, perl, gnulib etc. uses the iobuf and ioinfo
structures heavily. Is it possible to add those structure definition
for UCRT here? Just asking :)
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
在 2021-05-01 13:41, Biswapriyo Nath 写道:
The `void *_Placeholder` was added in struct _iobuf in stdio.h only.
But struct _iobuf is declared in other three headers also. Thoughts
attached.
How about removing the struct definition? It looks unused, except by the
typedef. So this
```
The `void *_Placeholder` was added in struct _iobuf in stdio.h only.
But struct _iobuf is declared in other three headers also. Thoughts
attached.
From 12a57820b60b5e47ff347b9498a43b74d00d0c95 Mon Sep 17 00:00:00 2001
From: Biswapriyo Nath
Date: Sat, 1 May 2021 11:07:37 +0530
Subject: [PATCH]
在 2020/7/30 下午4:34, Luca Bacci 写道:
> Hi, I'm contributing some Windows-specific code to a cross-platform OSS
> project. This project is licensed under the LGPL. Because the code I'm
> contributing uses some newer windows API only introduced since Windows 8,
> and because the project must continue
To make it simple: what is the license of the winuser.h header from
mingw-w64? Is it Public Domain or Zope Public License?
Thanks!
Luca
Il gio 30 lug 2020, 10:34 Luca Bacci ha scritto:
> Hi, I'm contributing some Windows-specific code to a cross-platform OSS
> project. This project is licensed
Hi, I'm contributing some Windows-specific code to a cross-platform OSS
project. This project is licensed under the LGPL. Because the code I'm
contributing uses some newer windows API only introduced since Windows 8,
and because the project must continue to compile with older compiler
toolchains
Il 23/03/2018 21:16, niXman ha scritto:
>
> Tomorrow I will upload the version 7.3.0.
>
>
>
Got it! Thank you very much
Max
--
PGP key: wwwkeys.pgp.net: 0EBF4A07
--
Check out the vibrant tech community on
Dear All,
This is my first message in the list and I'm writing to get some
information. At the moment I'm using the MinGW-64 GCC 6.1.0 toolchain
using Win64 and I'd like to upgrade my programming environment.
Usually I avoid the x.0.0 version so I'm thinking to move to the GCC
7.x.x version of
Hi,
I just wanted to say that I "solved" the problem for now by adding
--disable-libcc1
to the configure flags as suggested on the GCC's IRC channel.
For the other problem I opened a ticket:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78756
and moved the file manually in the
Hello,
I created packages for MinGW-w64 for MacPorts, but there's one more
issue that I need to solve before I could publish the packages.
Both i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc (created with
"make && make install" from GCC) contain the same three files:
Hello Luis!
On Mon, Aug 6, 2012 at 3:08 PM, Luis Lavena luislav...@gmail.com wrote:
Hello,
A few months ago there was a conversation on this list about an
improved threading model that will avoid the dependency on
pthread-like wrappers.
Would this be the discussion started by Jonathan
Hello,
A few months ago there was a conversation on this list about an
improved threading model that will avoid the dependency on
pthread-like wrappers.
Sometimes it was referenced as win64, which a few developers
considered it wrong and that win32 threading should be enhanced
instead.
Either
I.e. these warnings is reported when building gcc.
example:
x86_64-w64-mingw32-gcc -c -O2 -pipe -fomit-frame-pointer
-momit-leaf-frame-pointer -I/./mingw-libs-x64/include
-D__USE_MINGW_ACCESS -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual
-Wstrict-prototypes -Wmissing-prototypes
It seems that some code may be built using -pedantic ... which can
imply `__STRICT_ANSI__'.
On Thu, Apr 12, 2012 at 7:04 PM, niXman i.nix...@gmail.com wrote:
I.e. these warnings is reported when building gcc.
example:
x86_64-w64-mingw32-gcc -c -O2 -pipe -fomit-frame-pointer
Hi,
When buildling MinGW, are shown more than a thousand of such warnings.
Tell me please, does it happen just to me? Or it happens to the others
who build MinGW, too?
How to fix or suppress that specific warning?
Thanks!
--
Regards,
niXman
On Wed, Sep 14, 2011 at 11:17 PM, Me Myself and I
stargate7thsym...@live.co.uk wrote:
First, I wish to download and install
mingw64 for windows, and install it all successfully so that I can use gcj.
I don't believe gcj supports win64 targets yet.
2011/9/17 NightStrike nightstr...@gmail.com:
On Wed, Sep 14, 2011 at 11:17 PM, Me Myself and I
stargate7thsym...@live.co.uk wrote:
First, I wish to download and install
mingw64 for windows, and install it all successfully so that I can use gcj.
I don't believe gcj supports win64 targets
First, I wish to download and install
mingw64 for windows, and install it all successfully so that I can use gcj.
-Does the gcj that compiles in this environment produce 64 bit executables by
default,
just by virtue of the 64 bit environment itself?
?
eg.
gcj Test.java --main=Test -o
On 5/19/11, Kai Tietz ktiet...@googlemail.com wrote:
2011/5/19 Dongsheng Song dongsheng.s...@gmail.com:
I think this is a debug line, should be removed, right ?
Index: libmangle/src/m_ms.c
===
--- libmangle/src/m_ms.c
I think this is a debug line, should be removed, right ?
Index: libmangle/src/m_ms.c
===
--- libmangle/src/m_ms.c(revision 4169)
+++ libmangle/src/m_ms.c(working copy)
@@ -110,8 +110,6 @@
ctx.pZNameList =
Hello everyone,
I was wondering if there is a way to find out what _all_ is defined in the
mingw64 environment? Is there a way to get gcc to output this information? Is
there already a list somewhere? Is there another program that can somehow
gather this info? I'm wanting to know
On 2/1/2011 5:09 PM, David Cleaver wrote:
Hello everyone,
I was wondering if there is a way to find out what _all_ is defined in the
mingw64 environment? Is there a way to get gcc to output this information?
Is
there already a list somewhere? Is there another program that can somehow
On Sun, Mar 21, 2010 at 8:31 PM, NightStrike nightstr...@gmail.com wrote:
On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler dougsem...@gmail.com wrote:
On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler dougsem...@gmail.com wrote:
Yeah, I kinda decided to
On Mon, Mar 22, 2010 at 3:22 PM, Doug Semler dougsem...@gmail.com wrote:
On Sun, Mar 21, 2010 at 8:31 PM, NightStrike nightstr...@gmail.com wrote:
On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler dougsem...@gmail.com wrote:
On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
On Sun, Mar 21, 2010 at
On Mon, Mar 22, 2010 at 3:39 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/3/22 Doug Semler dougsem...@gmail.com:
On Sun, Mar 21, 2010 at 8:31 PM, NightStrike nightstr...@gmail.com wrote:
On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler dougsem...@gmail.com wrote:
Well, in fact is this
Quick question:
Are you sure you want to disable the leading underscore on the 32bit side with
the --disable-leading-underscore and multilib? Looking at it (without testing
it, that is), it doesn't seem to me that it is appropriate...
On Sun, Mar 21, 2010 at 7:21 PM, NightStrike nightstr...@gmail.com wrote:
Well, this is a problem, yes. It only affects the multilib builds,
though, which don't really work anyway without a lot of effort. And
this will all be fixed for 4.6, o we won't need to worry about it.
If users really
2010/3/21 Ozkan Sezer seze...@gmail.com:
On Sun, Mar 21, 2010 at 7:21 PM, NightStrike nightstr...@gmail.com wrote:
Well, this is a problem, yes. It only affects the multilib builds,
though, which don't really work anyway without a lot of effort. And
this will all be fixed for 4.6, o we won't
On Sun, Mar 21, 2010 at 7:55 PM, Kai Tietz ktiet...@googlemail.com wrote:
2010/3/21 Ozkan Sezer seze...@gmail.com:
On Sun, Mar 21, 2010 at 7:21 PM, NightStrike nightstr...@gmail.com wrote:
Well, this is a problem, yes. It only affects the multilib builds,
though, which don't really work
2010/3/21 Doug Semler dougsem...@gmail.com:
On Sun, 21 Mar 2010 13:55:36 Kai Tietz wrote:
2010/3/21 Ozkan Sezer seze...@gmail.com:
On Sun, Mar 21, 2010 at 7:21 PM, NightStrike nightstr...@gmail.com
wrote:
Well, this is a problem, yes. It only affects the multilib builds,
though, which
On 3/22/2010 07:24, Doug Semler wrote:
On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
On Sun, Mar 21, 2010 at 2:10 PM, Doug Semlerdougsem...@gmail.com wrote:
Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The
target DLLs for things like libstdc++, etc are installed
On Fri, Jan 29, 2010 at 11:11 PM, David Cleaver wrai...@morpheus.net wrote:
Hello again,
I know it wasn't long ago that I was asking about using %llu in fscanf or
sscanf. However, I am wondering if anything has changed in this regard? Does
MingW64 support %llu in the scanf functions?
Hello again,
I know it wasn't long ago that I was asking about using %llu in fscanf or
sscanf. However, I am wondering if anything has changed in this regard? Does
MingW64 support %llu in the scanf functions?
Also, in the future, is there an easy way for me to find out this information
on
On 1/30/2010 12:11, David Cleaver wrote:
Hello again,
I know it wasn't long ago that I was asking about using %llu in fscanf or
sscanf. However, I am wondering if anything has changed in this regard? Does
MingW64 support %llu in the scanf functions?
Also, in the future, is there an easy
37 matches
Mail list logo
