Hi again,
> > Yes, but that is an ABI change, on what is supposed to be a
> > standardized interface. They can't just break all existing callers
> > who expect the calling convention to be stdcall.
> >
> > I think the only way is to have separate def files for x86 and
> > everything else. Does
Hi again,
> -Original Message-
> From: Kacvinsky, Tom
> Sent: Thursday, May 4, 2023 12:45 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: RE: [Mingw-w64-public] Exported symbols of import .lib are
> influenced by the .def file
>
> Hi Luca,
>
Hi Luca,
> -Original Message-
> From: Luca Bacci
> Sent: Thursday, May 4, 2023 11:38 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Exported symbols of import .lib are
> influenced by the .def file
>
> Thanks for the response, Tom!
>
> Yes, that would
> -Original Message-
> From: Luca Bacci
> Sent: Thursday, May 4, 2023 10:50 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] Exported symbols of import .lib are influenced
> by the .def file
>
> Hello! we're observing a problem when compiling x86 DLLs
eption handling.
Thanks,
TOm
From: Kacvinsky, Tom
Sent: Thursday, November 4, 2021 10:46 PM
To: 'mingw-w64-public@lists.sourceforge.net'
Subject: RE: Patches for GCC
I think this is it
https://github.com/msys2/MINGW-packages
Tom
P.S. - I would bottom post but Outlook is being a pain with
q
Weird, running make without the -j option magically "fixed" the error. Not
sure why.
From: Kacvinsky, Tom
Sent: Tuesday, November 9, 2021 6:32 PM
To: mingw-w64-public@lists.sourceforge.net
Subject: Internal compiler error building mingw-w64-crt (default msvcrt is ucrt)
I am buil
I am building (once again) a GCC with UCRT support, this time using the UCRT64
tool chain
that I was able to install today. I am using master of the mingw-w64 git repo,
freshly updated
today, but have a problem building the CRT libraries:
e and
> update everything.
>
I did that several times. What finally worked was this:
I had to update /etc/pacman.conf to include the repo
/etc/pacman.d/mirrorlist.ucrt64
Which, as answered above, I already have.
Tom
> --David Grayson
>
> On Tue, Nov 9, 2021 at 11:3
I ran the command in the subject line, but got this:
$ pacman -S mingw-w64-ucrt-x86_64-toolchain
error: target not found: mingw-w64-ucrt-x86_64-toolchain
Is there some repo I need to add? It's not clear from this page
https://packages.msys2.org/group/mingw-w64-ucrt-x86_64-toolchain
Thanks,
I think this is it
https://github.com/msys2/MINGW-packages
Tom
P.S. - I would bottom post but Outlook is being a pain with
quoting emails.
From: Kacvinsky, Tom
Sent: Thursday, November 4, 2021 9:12 PM
To: 'mingw-w64-public@lists.sourceforge.net'
Subject: Patches for GCC
Hi all,
I am back
Hi all,
I am back to futzing around with building GCC with UCRT support.
I have run into several weird issues that I think might be fixed in
patches made by the MinGW-w64 team. I know I've been able to
find those patches in the past, but my Google-fu is weak and I do
not see them anywhere.
Any
IN my endeavors to get UCRT versions of the GCC tool chain building,
I ran into a problem building binutils 2.37. The particular problem was
that rust-demangle.c used uint, and that type is not defined. So what
I did to work around the problem is changes uint to unsigned int. I've
bounded this
10:17 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] How was binutils 2.37 configured for latest
> mingw-w64?
>
> Hmm seems zip is blocked ill try just attaching the scripts directly.
>
> Den 18-09-2021 kl. 15:06 skrev Kacvinsky, Tom:
> > HI,
&g
0:04 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] How was binutils 2.37 configured for latest
> mingw-w64?
>
> same way as the standard msys2 mingw-w64-binutils :) only the exception
> model changed.
>
> Den 18-09-2021 kl. 15:06 skrev K
HI,
I am working with Ralph's sjlj GCC tool chain, but am running into problems
using that to boot strap the tool chain with UCRT support. What I have found
is that crt2.o cannot be found
../../xg++ -B../../ -B../../../x86_64-w64-mingw32/libstdc++-v3/src/.libs
Ralph,
Do you have Ada support in your kit? Because I am going to need
an Ada compiler to built the new compiler with UCRT support.
Thanks,
Tom
> -Original Message-
> From: Kacvinsky, Tom
> Sent: Thursday, September 16, 2021 6:23 AM
> To: 'Ralph Engels' ; ming
> -Original Message-
> From: Ralph Engels
> Sent: Thursday, September 16, 2021 2:31 AM
> To: mingw-w64-public@lists.sourceforge.net; Kacvinsky, Tom
>
> Subject: Re: [Mingw-w64-public] SJLJ GCC
>
> I do have a private fork of the msys2 mingw reposito
Hi all,
I find I am in need of building a GCC with Ada and UCRT support, but this time
with SJLJ
exception handling instead of SEH. Does there exist a gcc package for MSYS2
that has
SJLJ support?
The reason I ask is the way I am building GCC with SJLJ support - in several
steps so that
the
is invoked properly, but with the Windows style paths (with / instead of
\) makes it so that gcc (as invoked from the Makefile) is not found, even
though it is in the PATH as set on the DOSC command prompt. The only way I
could get around it is to use Cygwin style PATHS.
Thanks and regards,
T
Hi,
I have found an issue - perhaps a user mistake - which I need to pass Cygwin
style paths to make.
So instead of c:/path/to/whatever, I need to use /cygdrive/c/path/to/whatever.
Is there a way
of forcing GNU make on MSYS2 + MinGW-w64 to honor paths of the form the
c:/path/to/whatever.
I happened to notice that including windows.h bring along the intrinics
for SSE and the like. I have checked the Windows SDK to see if it does
the same thing (and read the docs for the math intrinsics
#include
on MSDN, and it does not. I am wondering what the rationale for this is
in
Hi,
> -Original Message-
> From: Kacvinsky, Tom
> Sent: Monday, January 25, 2021 9:40 AM
> To: 'mingw-w64-public@lists.sourceforge.net' pub...@lists.sourceforge.net>
> Subject: RE: [Mingw-w64-public] More link errors
>
> At the bottom you'll find the
> -Original Message-
> From: Liu Hao
> Sent: Monday, January 25, 2021 9:49 PM
> To: mingw-w64-public@lists.sourceforge.net; Kacvinsky, Tom
>
> Subject: Re: [Mingw-w64-public] More link errors
>
> * PGP Signed by an unknown key
>
> 在 2021/1
> -Original Message-
> From: Ką Mykolas
> Sent: Monday, January 25, 2021 9:32 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] More link errors
>
> No file attached ;)
>
> On Mon, Jan 25, 2021 at 4:27 PM Kacvinsk
At the bottom you'll find the link errors I am getting
> -Original Message-
> From: Kacvinsky, Tom
> Sent: Monday, January 25, 2021 9:37 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: RE: [Mingw-w64-public] More link errors
>
>
>
> > -Orig
Hi,
Attached is a file of the link errors I am getting. There are bunch of them.
I am using the
built-in specs, so the run time library I am working with is libmsvcrt.a
Tom
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
This code
#include
int main(int argc, char* argv[])
{
__iswcsymf(0);
return 0;
}
compiled with this command
g++ -o test test.cpp
Fails with
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe:
D:\TEMP\ccmM3An6.o:test.cpp:(.text+0x1c):
What library is strlwr_l supposed to come from? I have a lew of link errors
due to missing wide
char functions, but I have not been able to figure out which library to use. I
am using the most
up to date MSYS2 + the package for the GCC toolchain (GCC 10.2), with no
modifications, but have had
From: Kacvinsky, Tom
Sent: Friday, October 16, 2020 10:17 AM
To: 'mingw-us...@lists.sourceforge.net'
Subject: RE: gprbuild for i686 tool chain bombs out
HI again (so soon),
From: Kacvinsky, Tom
Sent: Friday, October 16, 2020 10:13 AM
To: 'mingw-us...@lists.sourceforge.net'
mailto:mingw-us
Not sure if this is aMinGW-w64 topic or not.
I am using a Cygwin shell (can't avoid it, this is part of our Windows build
process), and from that,
I am invoking make as follows
/make SHELL=cmd MAKEFLAGS=".SHELLFLAGS=/c"
What I find is that $(MAKE) (which is used in a recursive makefile) is not
Hi all,
> -Original Message-
> From: Martin Storsjö
> Sent: Monday, December 16, 2019 3:36 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] gettext 0.19.8.1 build error with GCC 9.2.0
>
> On Sat, 14 Dec 2019, Martin Storsjö wrote:
>
> > On Sat, 14 Dec
> -Original Message-
> From: Martin Storsjö
> Sent: Saturday, December 14, 2019 3:55 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] gettext 0.19.8.1 build error with GCC 9.2.0
>
> On Sat, 14 Dec 2019, Liu Hao wrote:
>
> > 在 2019/12/14 4:17, Martin
Hi Martin,
> -Original Message-
> From: Martin Storsjö
> Sent: Friday, December 13, 2019 3:18 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] gettext 0.19.8.1 build error with GCC 9.2.0
>
> On Fri, 13 Dec 2019, Kacvinsky, Tom wrot
I am trying to compiler gettext 0.19.8.1 on MinGW-w64 (custom build of GCC
9.2.0 is being used),
and get this error:
gettext-runtime/gnulib-lib/mbsinit.c:32:28: error: invalid operands to binary
== (have 'mbstate_t' {aka 'const struct _Mbstatet'} and 'int')
Presumably this has been fixed in
Hi,
> -Original Message-
> From: JonY via Mingw-w64-public pub...@lists.sourceforge.net>
> Sent: Monday, December 2, 2019 10:37 AM
> To: mingw-w64-public@lists.sourceforge.net
> Cc: JonY
> Subject: Re: [Mingw-w64-public] gnatdll not building
>
> On 12/2/19 2:
HI yet again
> -Original Message-
> From: Kacvinsky, Tom
> Sent: Wednesday, November 27, 2019 8:59 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] gnatdll not building
>
> Hi again,
>
> > -Original Message-
>
Hi again,
> -Original Message-
> From: Kacvinsky, Tom
> Sent: Wednesday, November 27, 2019 8:56 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] gnatdll not building
>
> I am trying to build the custom tool chain tha
I am trying to build the custom tool chain that I built in the past such that
the
Ada tool chain uses UCRT. I was able to accomplish this with x86_64, but now
I am trying my hand at i686.
The build script I am using builds the GCC dependencies (gmp, mpfr, mpc) first,
builds binutils, builds
> -Original Message-
> From: LRN
> Sent: Friday, November 22, 2019 11:35 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Building binutils with gcc 9.2.0
>
> On 22.11.2019 19:22, Kacvinsky, Tom wrote:
> > I am seeing th
I am seeing this while building bintutils 2.33.1 with gcc 9.2.0 that comes with
the wingw-w64-i686-toolchain
supplied compilers:
../../../libiberty/pex-unix.c:395:20: error: 'FD_CLOEXEC' undeclared (first use
in this function)
395 | if ((flags & FD_CLOEXEC) == 0 && fcntl (old_fd,
tab.h:2:2: error: #error This table is for GMP_LIMB_BITS = 64
2 | #error This table is for GMP_LIMB_BITS = 64
| ^
> Op wo 20 nov. 2019 18:35 schreef Kacvinsky, Tom
> :
>
> > I am using the latest MinGW-w64 i686 tool chain (which is based on GCC
> > 9.2.0) to buil
I am using the latest MinGW-w64 i686 tool chain (which is based on GCC 9.2.0)
to build
a custom tool chain with UCRT support. But the compiler is throwing an error
when
building GMP:
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I.. -D__GMP_WITHIN_GMP -I..
-DOPERATION_pre_divrem_1 -m32 -O2
age-
> From: Kacvinsky, Tom
> Sent: Tuesday, November 12, 2019 8:02 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Weird issue with UCRT and custom tool
> chain
>
> Which version of binutils? I am using 2.32
>
> > -Original Me
I using mingw-w64 commit is 2ce6f4b1548453818fa71c89c88fed5f7f4d508b
>
> Kacvinsky, Tom 于2019年11月12日周二 上
> 午2:12写道：
>
> > Hi,
> >
> > > -Original Message-
> > > From: Peiyuan Song
> > > Sent: Monday, November 11, 2019 10:16 AM
> >
64 + UCRT, it works fine.
>
That, unfortunately, is not helpful. :-(
> Kacvinsky, Tom 于 2019年11月11日周一
> 22:31写道：
>
> > AS you know, I had to build a custom GCC toolchain with UCRT support
> > in the MinGW-w64.
> >
> > What I did next (aside from building our
AS you know, I had to build a custom GCC toolchain with UCRT support in the
MinGW-w64.
What I did next (aside from building our product) is build Microsoft's Z3
theorem prover
software.
Here is the weird thing:
On my machine, both Z3 built with the custom MinGW-w64 toolchain and Visual
I am unfortunately in the position where the Visual Studio compiled code I am
using does not
allow me to set a breakpoint where I need to. I have been told it is because I
am using the /MD
flag and that is causing problems with the generated oject code with respect to
the information
stored in
Hi all,
I have had great success with the UCRT support I need for the project I am
working on.
But today I found out I also need winpthread support, which is currently not in
the kit
(gcc-8.3.0 based) I built.
I still have the script I used to bootstrap gcc-8.3.0 and associated runtimes
that
> -Original Message-
> From: Maarten Verhage
> Sent: Saturday, June 22, 2019 9:38 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Forcing MinGW-w64's linker to find
> Windows specific libraries
>
> Hi Tom,
>
> I'm not an expert on this topic but
> -Original Message-
> From: Kacvinsky, Tom
> Sent: Friday, June 21, 2019 5:04 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] Forcing MinGW-w64's linker to find Windows
> specific libraries
>
> I am getting these errors:
>
I am getting these errors:
C:\code\mingw-native\bin/ld.exe: cannot find -ladvapi32.lib
C:\code\mingw-native\bin/ld.exe: cannot find -lcomctl32.lib
C:\code\mingw-native\bin/ld.exe: cannot find -lcomdlg32.lib
C:\code\mingw-native\bin/ld.exe: cannot find -lcrypt32.lib
Hi
> -Original Message-
> From: Martin Storsjö
> Sent: Wednesday, April 24, 2019 3:54 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having
> GCC compile errors
>
> On Wed, 24 Apr 20
Hi Martin,
> -Original Message-
> From: Martin Storsjö
> Sent: Wednesday, April 24, 2019 7:55 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having
> GCC compile errors
>
> On Wed, 24 Apr 2019, Martin Storsjö wrote:
HI
> -Original Message-
> From: Liu Hao
> Sent: Monday, April 22, 2019 10:18 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having
> GCC compile errors
>
> 在 2019/4/23 上午5:12, Martin Storsjö 写道:
> > I haven't looked
> -Original Message-
> From: David Grayson
> Sent: Thursday, April 18, 2019 12:19 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having
> GCC compile errors
>
> It's not really a chicken and egg situation. You
Hi,
> -Original Message-
> From: Liu Hao
> Sent: Wednesday, April 17, 2019 11:10 AM
> To: mingw-w64-public@lists.sourceforge.net; Kacvinsky, Tom
>
> Subject: Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having
> GCC compile errors
>
> 在 2019/4
12:53 PM
> To: mingw-w64-public@lists.sourceforge.net; Kacvinsky, Tom
>
> Subject: Re: [Mingw-w64-public] PKGBUILD script for toolchain, still having
> GCC compile errors
>
> Oh yeah, another thing I was going to say is that `--prefix=/usr/local` looks
> very suspect to me
I am looking at this script
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/PKGBUILD
It doesn't say which version of gcc this is for as far as I can tell, so
perhaps it is generic.
What I have found is that some of the patches don't seem to apply to GCC 8.3.0,
at
least
Is the minge-64-headers component of the CRT repo supposed to install pthread.h?
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
I am using
https://sourceforge.net/p/mingw-w64/wiki2/Cross%20Win32%20and%20Win64%20compiler/
In there, it says to use --disable-multilib if I do not want 32 and 64-bit
support, only the native
mingw-w64 architecture. Despite adding that to the configure options, lib32 is
still built. I'd
> -Original Message-
> From: Kacvinsky, Tom
> Sent: Monday, April 1, 2019 10:54 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] Building GCC linked against libucrt fails
>
> > In my own setup for bootstrapping a mingw cross com
Hi,
> I think the important distinction here is to make between building the
> compiler itself (which is a binary which you build using your existing
> toolchain,
> using the CRT that is default/usable there), and building the runtimes
> (libgcc,
> libstdc++, libada) which the compiler will be
>
> It's not missing because it's deprecated or something of that effect. It's
> missing because ucrtbase.dll doesn't export any symbol named _environ.
>
> If you build code that reference the _environ variable with headers set to
> __MSVCRT_VERSION__ >= 0x1400, "_environ" will expand to (*
>
I understand the data symbol _environ should not be used as outlined in
MSDN documentation. That said, libgnat.a from MinGW-w64 6.0.0 (as
installed via pacman in MSYS2) still uses it
I suitably modified ucrtbase.def to add
_environ DATA
rebuilt the import libraries and all is well. So I am
> -Original Message-
> From: Martin Storsjö
> Sent: Monday, March 25, 2019 4:35 PM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: Re: [Mingw-w64-public] Adding Visual Studio 2017 support to
> MinGW-w64
>
> On Mon, 25 Mar 2019, Kacvinsky, Tom
-Original Message-
From: Kacvinsky, Tom
Sent: Monday, March 25, 2019 7:59 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Adding Visual Studio 2017 support to MinGW-w64
>
> The best way to use it is to rebuild mingw-w64 from scratch wit
>
> The best way to use it is to rebuild mingw-w64 from scratch with both
> headers and crt built with --with-default-msvcrt=ucrt (or ucrtbase).
> Then your "libmsvcrt.a" actually will be the libucrt.a (or
> libucrtbase.a) and will link against api-ms-win-crt-*.dll or
> ucrtbase.dll. (VS
-Original Message-
From: Kacvinsky, Tom
Sent: Sunday, March 24, 2019 11:34 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Adding Visual Studio 2017 support to MinGW-w64
HI,
Realized I just be bottom posting. Sorry about that.
-Original Message
, Kacvinsky, Tom wrote:
> Hi Martin,
>
> I have a mixed C, C++, and Ada source tree. I used Visual Studio to
> compile C and C++ code, and a MinGW-w64 based Ada compiler. What I
> would like to do is get MinGW-w64 version 5.0.4 (which is what the Ada
> compiler is based o
: [Mingw-w64-public] Adding Visual Studio 2017 support to MinGW-w64
On Sat, 23 Mar 2019, Kacvinsky, Tom wrote:
> Well, MS does not ship a mavcr140.dll (according to what I see in the
> redistributables), so I think the DLL I want to focus on is
> vcruntime140.dll
There's no msvcr140.dll -
Well, MS does not ship a mavcr140.dll (according to what I see in the
redistributables),
so I think the DLL I want to focus on is vcruntime140.dll
-Original Message-
From: Kacvinsky, Tom
Sent: Saturday, March 23, 2019 11:47 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: Re
OK, the gendef steps makes sense.
But...
An issue is that C++ files, when compiled with Visual Studio 2017, show
both vcruntime140.dll and msvcp140.dll as dependencies (along with a
bunch of api-ms*.dll files).
On the other hand, C only executables show just vcruntime140.dll and the
api-ms*.dll
I see there are a few libraries meant for use with interacting with
Visual Studio - libmsvcr90.a (Visual Studio 2008) for instance.
I'd like to add something similar for Visual Studio 2017, but I have
not been able to find a good online guide for doing so.
Does anyone have any ideas on this?
73 matches
Mail list logo
