On Thu, 12 Dec 2024, Martin Storsjö wrote:
On Thu, 12 Dec 2024, Johannes Khoshnazar-Thoma wrote:
Hi Martin, Hi List,
/home/johannes/mingw-build-binutils/sysroot/bin/x86_64-w64-mingw32-objdump:
ntoskrnl.exe: file format not recognized
[...]
while most sections work:
ntoskrnl.exe: file
On Thu, 12 Dec 2024, Johannes Khoshnazar-Thoma wrote:
Hi Martin, Hi List,
Am 27.11.24 um 12:40 schrieb Johannes Khoshnazar-Thoma:
Hi Martin Storsjö,
Am 22.11.24 um 13:13 schrieb Martin Storsjö:
>
> This patch was approved and merged now (after some discussion and some
tweaks to
> the im
Hi Martin, Hi List,
Am 27.11.24 um 12:40 schrieb Johannes Khoshnazar-Thoma:
Hi Martin Storsjö,
Am 22.11.24 um 13:13 schrieb Martin Storsjö:
>
> This patch was approved and merged now (after some discussion and some
tweaks to
> the implementation), see
>
https://sourceware.org/git/?p=binut
Hi Martin Storsjö,
Am 22.11.24 um 13:13 schrieb Martin Storsjö:
>
> This patch was approved and merged now (after some discussion and some tweaks
to
> the implementation), see
>
https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=3c557e1ae9c320efcfd4a7a91b752413a7bfd280.
>
> // Martin
On Wed, 6 Nov 2024, Johannes Khoshnazar-Thoma wrote:
Hi Martin Storsjö,
Am 06.11.24 um 10:32 schrieb Martin Storsjö:
On Fri, 25 Oct 2024, Martin Storsjö wrote:
I finally got around to this now - this patch is available at
https://sourceware.org/pipermail/binutils/2024-November/137536.html.
Hi Martin Storsjö,
Am 06.11.24 um 10:32 schrieb Martin Storsjö:
On Fri, 25 Oct 2024, Martin Storsjö wrote:
I finally got around to this now - this patch is available at
https://sourceware.org/pipermail/binutils/2024-November/137536.html.
Thank you very much for the patch, it looks correct t
On Fri, 25 Oct 2024, Martin Storsjö wrote:
On Fri, 25 Oct 2024, Johannes Khoshnazar-Thoma wrote:
Hi LIU Hao,
Thanks for you fast answer comments below.
Am 25.10.24 um 06:00 schrieb LIU Hao:
在 2024-10-24 19:26, Johannes Khoshnazar-Thoma 写道:
Hi List,
I am writing a Windows kernel driver tha
On Fri, 25 Oct 2024, Johannes Khoshnazar-Thoma wrote:
Hi LIU Hao,
Thanks for you fast answer comments below.
Am 25.10.24 um 06:00 schrieb LIU Hao:
在 2024-10-24 19:26, Johannes Khoshnazar-Thoma 写道:
Hi List,
I am writing a Windows kernel driver that should use wdmsec (in particular
IoCreateDe
Hi LIU Hao,
Thanks for you fast answer comments below.
Am 25.10.24 um 06:00 schrieb LIU Hao:
在 2024-10-24 19:26, Johannes Khoshnazar-Thoma 写道:
Hi List,
I am writing a Windows kernel driver that should use wdmsec (in particular
IoCreateDeviceSecure(). I found the wdmsec.h header but I can't fi
在 2024-10-24 19:26, Johannes Khoshnazar-Thoma 写道:
Hi List,
I am writing a Windows kernel driver that should use wdmsec (in particular
IoCreateDeviceSecure(). I found the wdmsec.h header but I can't find some
libwdmsec.a to link against, so linking fails.
Is wdmsec supported by mingw64? How shou
Hi List,
I am writing a Windows kernel driver that should use wdmsec (in particular
IoCreateDeviceSecure(). I found the wdmsec.h header but I can't find some
libwdmsec.a to link against, so linking fails.
Is wdmsec supported by mingw64? How should I link it? If it is not supported,
can I make it
在 2024-08-13 04:33, Rafael Kitover 写道:
Apologies in advance if this is the wrong place to ask about this.
I recently ran into a problem in a project I'm working on, which is a
binary using the Cygwin runtime, where linking failed to find a CRT
function, stricmp() in this case.
For the time bein
Apologies in advance if this is the wrong place to ask about this.
I recently ran into a problem in a project I'm working on, which is a
binary using the Cygwin runtime, where linking failed to find a CRT
function, stricmp() in this case.
For the time being, I used a trivial reimplementation of t
在 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 / UCR
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
n
在 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 `_fgetc_nolo
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
https://list
在 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
```
typede
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] head
That's great. Thank you very much!
Luca
Il gio 30 lug 2020, 14:07 Liu Hao ha scritto:
> 在 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
在 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 t
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 (M
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 one
maxgacode 2018-03-23 21:57:
Dear All,
Hi,
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 t
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 th
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 "post-instal
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:
/opt/local/lib/x86_64/l
Hello Luis!
On Mon, Aug 6, 2012 at 3:08 PM, Luis Lavena 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 Wakely:
http://gc
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
On Thu, Apr 12, 2012 at 11:10 AM, niXman wrote:
> 2012/4/12 Earnie Boyd :
>> On Thu, Apr 12, 2012 at 7:04 AM, niXman wrote:
>>> I.e. these warnings is reported when building gcc.
>>>
>>> ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:173:5: warning: ISO C
>>> does not support the 'I64' ms_printf
2012/4/12 Earnie Boyd :
> On Thu, Apr 12, 2012 at 7:04 AM, niXman wrote:
>> I.e. these warnings is reported when building gcc.
>>
>> ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:173:5: warning: ISO C
>> does not support the 'I64' ms_printf length modifier [-Wformat]
>
> Add -Wno-format after the
On Thu, Apr 12, 2012 at 7:04 AM, niXman wrote:
> I.e. these warnings is reported when building gcc.
>
> ../../../mingw-src/gcc-trunk/gcc/lto-streamer.c:173:5: warning: ISO C
> does not support the 'I64' ms_printf length modifier [-Wformat]
Add -Wno-format after the -pedantic.
--
Earnie
-- https:
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 wrote:
> 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.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 -Wmissing-forma
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
--
2011/9/17 NightStrike :
> On Wed, Sep 14, 2011 at 11:17 PM, Me Myself and I
> 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.
Well, for 4.7 (with some tweaks to
On Wed, Sep 14, 2011 at 11:17 PM, Me Myself and I
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.
-
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 Test.exe
On 6/9/2011 07:23, NightStrike wrote:
> On 5/19/11, Kai Tietz wrote:
>> 2011/5/19 Dongsheng Song :
>>> I think this is a debug line, should be removed, right ?
>>>
>>> Index: libmangle/src/m_ms.c
>>> ===
>>> --- libmangle/src/m_ms.c
On 5/19/11, Kai Tietz wrote:
> 2011/5/19 Dongsheng Song :
>> 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_m
2011/5/19 Dongsheng Song :
> 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
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 = &ZNameList
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 "define"d 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 some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/2/2011 09:09, David Cleaver wrote:
> Hello everyone,
>
> I was wondering if there is a way to find out what _all_ is "define"d in the
> mingw64 environment? Is there a way to get gcc to output this information?
> Is
> there already a list so
Hello everyone,
I was wondering if there is a way to find out what _all_ is "define"d 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 (includi
On 3/28/2010 09:49, David Cleaver wrote:
> Hello all,
>
> I've recently come across a program that includes sys/resource.h and uses that
> for measuring the runtime of some code. I know that Mingw64 does not have
> this
> file, but I was wondering why? Is it something that cannot be done on a
>
Hello all,
I've recently come across a program that includes sys/resource.h and uses that
for measuring the runtime of some code. I know that Mingw64 does not have this
file, but I was wondering why? Is it something that cannot be done on a
Windows
platform?
Also, I see that there is a stru
On Mon, Mar 22, 2010 at 3:39 PM, Kai Tietz wrote:
> 2010/3/22 Doug Semler :
>> On Sun, Mar 21, 2010 at 8:31 PM, NightStrike wrote:
>>> On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler wrote:
>
> Well, in fact is this entry-point a no issue. By a recent patch, ld is
> able to select the proper entry
2010/3/22 Doug Semler :
> On Sun, Mar 21, 2010 at 8:31 PM, NightStrike wrote:
>> On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler wrote:
>>> On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler wrote:
> Yeah, I kinda decided to give up on multilib wi
On Mon, Mar 22, 2010 at 3:22 PM, Doug Semler wrote:
> On Sun, Mar 21, 2010 at 8:31 PM, NightStrike wrote:
>> On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler wrote:
>>> On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler wrote:
> Yeah, I kinda deci
On Sun, Mar 21, 2010 at 8:31 PM, NightStrike wrote:
> On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler wrote:
>> On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
>>> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler wrote:
>>> > Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The
>>>
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 Semler 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 into the
completely wron
On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler wrote:
> On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
>> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler 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 Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
> On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler 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 into the
> > completely wrong spot due to a -bindir param
On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler 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 into the completely
> wrong spot due to a -bindir parameter in the libtool portion of the DLL
> makefiles. They
2010/3/21 Doug Semler :
> On Sun, 21 Mar 2010 13:55:36 Kai Tietz wrote:
>> 2010/3/21 Ozkan Sezer :
>> > On Sun, Mar 21, 2010 at 7:21 PM, NightStrike
> wrote:
>> >> Well, this is a problem, yes. It only affects the multilib builds,
>> >> though, which don't really work anyway without a lot of effo
On Sun, 21 Mar 2010 13:55:36 Kai Tietz wrote:
> 2010/3/21 Ozkan Sezer :
> > On Sun, Mar 21, 2010 at 7:21 PM, NightStrike
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
On Sun, 21 Mar 2010 13:21:12 NightStrike 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 want it, though, I c
On Sun, Mar 21, 2010 at 7:55 PM, Kai Tietz wrote:
> 2010/3/21 Ozkan Sezer :
>> On Sun, Mar 21, 2010 at 7:21 PM, NightStrike 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
2010/3/21 Ozkan Sezer :
> On Sun, Mar 21, 2010 at 7:21 PM, NightStrike 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.
>>
>> I
On Sun, Mar 21, 2010 at 7:21 PM, NightStrike 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 want it, though,
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 want it, though, I can rework things to exclude 32-bit
entirely. It's just a
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 Mon, Feb 1, 2010 at 4:59 AM, David Cleaver wrote:
>
> JonY wrote:
>> There is no such macro as __MINGW64__, use __MINGW64_VERSION_MAJOR
>> instead, its guaranteed to be defined if you include any mingw-w64
>> headers.
>>
To clarify things: __MINGW32__ and __MINGW64__ :
They are both compiler '
On Sun, Jan 31, 2010 at 9:59 PM, David Cleaver wrote:
> Hello, thank you all for your replies. I seem to be having some trouble
> getting
> __MINGW64_VERSION_MAJOR to work for me. Perhaps I have set up my environment
> wrong? I've downloaded mingw-w64-bin_x86_64-mingw_20100123_sezero.zip and
>
JonY wrote:
> There is no such macro as __MINGW64__, use __MINGW64_VERSION_MAJOR
> instead, its guaranteed to be defined if you include any mingw-w64
> headers.
>
> I think __USE_MINGW_ANSI_STDIO only applies to the printf family, the
> scanf family has not been ported yet, so you'll need to use
> 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?
Use SCNu64 from . That's what it's for.
--tml
--
On Fri, Jan 29, 2010 at 11:11 PM, 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 futur
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
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
m
71 matches
Mail list logo
