Mmm yeah i newer seen problems with missing msvcrt.dll either going back
as far as win9x there was some other missing runtimes but not that
particular one.
Den 20-11-2022 kl. 16:58 skrev Eli Zaretskii:
Date: Sun, 20 Nov 2022 16:44:08 +0100
From: Pali Rohár
Cc: g...@gcc.gnu.org, mingw-w64-publ
i think most of it stems from binutils tools being geared towards linux
driver development ? and since noone before has shown much interrest in
developing drivers for windows using the gnu tools. I also think that
there might be some pitfalls -> incompatible exception models for one
(most mingw
sounds like a good idea :)
Den 20-10-2022 kl. 16:04 skrev LIU Hao:
在 2022-10-20 14:12, ralph engels 写道:
I think he was refering to gcc's gthreads implementation ?. not sure
if it was ever used for much else than the objc compiler, it does not
support threading in C++ as far as i
I think he was refering to gcc's gthreads implementation ?. not sure if
it was ever used for much else than the objc compiler, it does not
support threading in C++ as far as i know.
Den 20-10-2022 kl. 05:57 skrev LIU Hao:
在 2022/10/19 23:00, Jacek Caban 写道:
Hi,
I heard that it was committed
P.s you build winpthreads as part of building the mingw-w64 api then gmp
follwed by mpfr followed by mpc and lastly you build isl. Then you build
binutils and gcc :)
Den 20-09-2021 kl. 12:12 skrev rubisetcie:
Hi.
I'm trying to build the MinGW-W64 + Graphite + OpenMP multilib toolchain
accordi
pthreads-win32 is not needed any longer if using mingw-w64 which has its
own library with that functionality (winpthreads).
cloog-ppl is also no longer needed just gmp mpfr mpc and isl for the
graphite build.
Den 20-09-2021 kl. 12:12 skrev rubisetcie:
Hi.
I'm trying to build the MinGW-W64 +
Message-
From: Ralph Engels
Sent: Saturday, September 18, 2021 10: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
Hmm seems zip is blocked ill try just attaching the scripts directly.
Den 18-09-2021 kl. 15:06 skrev Kacvinsky, Tom:
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 canno
same way as the standard msys2 mingw-w64-binutils :) only the exception
model changed.
Den 18-09-2021 kl. 15:06 skrev Kacvinsky, Tom:
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
sure :) that would make it a litle easier.
Ralph Engels
Den 17-09-2021 kl. 20:20 skrev NightStrike:
Do you want upload access? There's already a personal build section
On Fri, Sep 17, 2021, 02:01 Ralph Engels wrote:
P.s you are welcome to link to or upload the sjlj build with ada o
sotrdg sotrdg:
C++ exception handling is a mistake. No matter it is sjlj, dwarf or SEH
Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
Windows
*From: *NightStrike <mailto:nightstr...@gmail.com>
*Sent: *Thursday, September 16, 2021 22:24
*To: *Ralph Engels <
:23 AM
To: 'Ralph Engels' ; mingw-w64-
pub...@lists.sourceforge.net
Subject: RE: [Mingw-w64-public] SJLJ GCC
-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-pu
dunno ? he might need it for building some library for msvc in which
case sjlj is pretty much the only thing that works besides maybe seh.
sjlj is extensively tested on windows it was the first exception model
avaliable to us with mingw and many years it did its job just fine :),
it is a bit sl
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' ; mingw-w64-
pub...@lists.sourceforge.net
Subject: RE: [Mingw-w64-public] SJLJ GCC
-Original Message-----
From: Ra
I do have a private fork of the msys2 mingw repository using sjlj
exceptions, unfortunatly not with ucrt support but should be doable to
build one using mine. Ill upload the nessesary packages to sourceforge
so you can get them from there.
Ralph Engels
Den 15-09-2021 kl. 23:35 skrev
crypt.h should be provided by gnulib since it does not normally exist on
windows, sounds like something breaks the build chain. can you post the
configure output ? might provide some clue as to what is going on.
Den 12-12-2019 kl. 01:17 skrev David Mathog:
On 2019-12-11 15:43, ralph engels
that sounds like a bug you need to report to the msys2 mingw-packages
developers, libgcrypt should also provide libgcrypt-20.dll and
libgcrypt.dll.a not just the header.
Den 12-12-2019 kl. 00:39 skrev David Mathog:
On 2019-12-11 14:46, Ruben Van Boxem wrote:
Op wo 11 dec. 2019 23:31 schreef D
check for inclusion of fcntl.h in that file, gcc has become very verbose
in later versions so allmost no matter what you will get warnings. These
are mostly descriptive and can be ignored unless a real error occurs.
Den 08-12-2019 kl. 09:49 skrev Amit Choudhary:
> I have some doubts: I am using mi
Would probably need to do a cross build using the msys2 mingw64
compilers in /opt else you would have gained nothing since every
dependency compiled with msys2 gcc would rely on the msys2.dll.
Den 08-12-2019 kl. 07:53 skrev Liu Hao:
> 在 2019/12/7 21:44, Amit Choudhary 写道:
>> Hi,
>>
>> I have downl
not sure if any help but the msys2 project has gcc-9.2.0 and i just
rebuilt itself with it so it should work :/ scratches head... i did
notice you use a lot of external paths to dependencies, maybe something
acting up there ?.
if you want to use an older toolchain to try building it i would
recomm
i686-w64-mingw32-gcc -pipe -Wl,--dynamicbase,--nxcompat -s -o python.exe \
Modules/python.o \
-L. -lpython2.7 -lm
./python.exe -E -S -m sysconfig --generate-posix-vars ;\
if test $? -ne 0 ; then \
echo "generate-posix-vars failed" ; \
rm -f ./py
building with an obscure segmentation
fault error in the 32 bit build.
Den 17-09-2019 kl. 11:06 skrev Liu Hao:
在 2019/9/17 15:18, ralph engels 写道:
It is set in the makepkg scripts in /etc.
Does -fstack-protector-all or -fstack-protector-strong work ?.
`-fstack-protector-strong` didn't wo
u Hao:
在 2019/9/17 15:18, ralph engels 写道:
It is set in the makepkg scripts in /etc.
Does -fstack-protector-all or -fstack-protector-strong work ?.
`-fstack-protector-strong` didn't work. I didn't try `-all`.
linking directly to libssp should not be nessesary if the build chain
works
I know makepkg is a script :), VERSION_CONTROL is also not a subversion
macro but a git or mercurial used one.
As for why it interferes with building this package for you i honestly
cannot say, but since others can build it,
the easiest path for you without breaking stuff would be to just do
configure:3401: checking whether the C compiler works
configure:3423: x86_64-w64-mingw32-gcc -march=x86-64 -mtune=generic -O2
-pipe -DHAVE_BZIP2 -D_FORTIFY_SOURCE=2 -D__USE_MINGW_ANSI_STDIO=1 -pipe
conftest.c -lbz2 >&5
configure:3427: $? = 0
configure:3475: result: yes
configure:3478: checking for
Oouf, so that was the problem, thought i was going nuts, the last pull
from msys2 broke the compiler completely with those exact errors. Mind
giving me a hint when it's fixed ?.
Den 28-11-2017 kl. 00:07 skrev Sven Kretzschmar:
> It seems that this patch somehow broke cross-compiling the gnu toolc
: mingw-w64-public@lists.sourceforge.net
Cc: JonY
Emne: Re: [Mingw-w64-public] problem with multiple defined symbolsinuuidanda
patch
On 10/10/2017 04:01 PM, ralph engels wrote:
> Just a note, the patch in question is by Tim S from the codeblocks forum, not
> by me 😊
> He had a hard time fi
via Mingw-w64-public
Sendt: 8. oktober 2017 05:29
Til: mingw-w64-public@lists.sourceforge.net
Cc: JonY
Emne: Re: [Mingw-w64-public] problem with multiple defined symbolsinuuidand a
patch
On 10/08/2017 03:02 AM, ralph engels wrote:
> Patch with git-format here.
>
> Sendt fra Mail til W
Ok here we go
Sendt fra Mail til Windows 10
Fra: JonY via Mingw-w64-public
Sendt: 8. oktober 2017 05:29
Til: mingw-w64-public@lists.sourceforge.net
Cc: JonY
Emne: Re: [Mingw-w64-public] problem with multiple defined symbolsinuuidand a
patch
On 10/08/2017 03:02 AM, ralph engels wrote:
> Pa
Patch with git-format here.
Sendt fra Mail til Windows 10
Fra: JonY via Mingw-w64-public
Sendt: 8. oktober 2017 01:48
Til: mingw-w64-public@lists.sourceforge.net
Cc: JonY
Emne: Re: [Mingw-w64-public] problem with multiple defined symbols inuuidand a
patch
On 10/07/2017 10:25 AM, ralph engels
] problem with multiple defined symbols inuuidand a
patch
On 10/07/2017 10:25 AM, ralph engels wrote:
> Glad it was of help.
>
> Inquisitive minds want to ask when it will be avaiiable ?.
>
> Rev.
>
> Sendt fra Mail til Windows 10
>
Can you please rebase on the maste
symbols in uuidand a
patch
On 10/06/2017 10:07 AM, ralph engels wrote:
>
> Causes problems with wxwidgets so here is a proposed patch.
>
> Subject: [PATCH] uuid.c: Removed DEFINE_GUID also in extras-uuid.c.
Patch OK after putting the list of duplicates removed in the commit mess
Causes problems with wxwidgets so here is a proposed patch.
Subject: [PATCH] uuid.c: Removed DEFINE_GUID also in extras-uuid.c.
---
mingw-w64-crt/libsrc/uuid.c | 12
1 file changed, 12 deletions(-)
diff --git a/mingw-w64-crt/libsrc/uuid.c b/mingw-w64-crt/libsrc/uuid.c
index 481e67
its ready.
Den 09-03-2016 kl. 14:23 skrev NightStrike:
On Mar 7, 2016 2:51 AM, "ralph engels" <mailto:ralpheng...@gmail.com>> wrote:
>
> Allthough not needed for building i uploaded the patched winpthreads
> library used in building gcc-5.3.0.
Please remember t
Hello.
Im the maintainer of C::B advanced and also an old member of inside3d
where i stumbled upon sezero which i remembered maintained some ports of
MinGW64. We had a little chat and he said you might be interrested in some
of my work on the mingw64 compiler. My build is strictly 32 or 64 bit
35 matches
Mail list logo
