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 <
zstd and iconv.
Den 16-09-2021 kl. 13:33 skrev Kacvinsky, Tom:
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
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
Here you go
https://sourceforge.net/projects/cbadvanced/files/bootstrap/sjlj%20bootstrap/
just install the same as you do with any other msys2 package :).
Den 16-09-2021 kl. 13:33 skrev Kacvinsky, Tom:
Ralph,
Do you have Ada support in your kit? Because I am going to need
an Ada compiler to
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
unset VERSION_CONTROL and hit enter before using makepkg-mingw. This
should get you over that particular problem.
Den 24-11-2018 kl. 09:56 skrev Liu Hao:
在 2018/11/24 下午3:43, ralph 写道:
sounds like VERSION_CONTROL is interfering to me. Isnt that a subversion
macro ?, might explain why pacman
sounds like VERSION_CONTROL is interfering to me. Isnt that a subversion
macro ?, might explain why pacman goes nuts.
Den 24-11-2018 kl. 06:30 skrev Edward Diener:
On 11/23/2018 10:04 PM, Liu Hao wrote:
在 2018/11/24 上午9:31, Edward Diener 写道:
On 11/23/2018 5:06 PM, Greg Jung wrote:
You should
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
, the list of things to change is long...
>
> http://cgit.notk.org/adrien/yypkg/slackware64-current.git/tree/n/openssl/openssl.SlackBuild#n46
Sorry, I do not understand what you meant by "the list of things to change is
long...". Were you referring to the security fixes for O
de
DES_INT used
RC4_CHUNK is unsigned long long
sh: 1: make: not found
Thanks in advance for your help.
Ralph
--
Want excitement?
Manually upgrade your productio
ake was to only select those
components of the package mingw-w64 that target the w64 architecture.
Now that I've installed the full package "mingw-w64", I could see that
x86_64-w64-mingw32-gcc has indeed been in
ot; that
target the W64 architecture only.
Regards.
Ralph
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.
Hi Adrien
I haven't done anything yet.
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.
So I have installed mingw-w64 components targetting only w64 architecture on
Debian 7.
After installation, I couldn't locate x86_64-w64-mingw32-gcc. Or could it be
called by another name?
Thanks in advance for your help.
-mingw-w64-base
mingw-w64-x86-64-dev
g++-mingw-w64-x86-64
gcc-mingw-w64-x86-64
binutils-mingw-w64-x86-64
mingw-w64-tools
Have I left out any packages?
Regards.
Ralph
--
Want excitement?
Manually upgrade your production
MinGW-w64 that I need?
Is it possible to cross-compile for Microsoft Windows without ever using
MinGW-w64 on Debian?
Regards.
Ralph
--
Want excitement?
Manually upgrade your production database.
When you want reliability
mingw-w64-1.0-bin_x86_64-linux_20120227.tar.bz2?
Second question: what does the prefix mingw-w64-1.0 stand for? There are only
two builds with such a prefix. All the rest that follow come without.
Regards.
Ralph
--
Hi
I wish to build a 64-bit Windows binary on a Debian 64-bit OS.
What are the Debian packages of MinGW-w64 that I need?
Is it possible to cross-compile for Microsoft Windows without ever using MinGW-w64 on Debian?
Regards.
Ralph
thout.
Regards.
Ralph
--
Want excitement?
Manually upgrade your production database.
When you want reliability, choose Perforce
Perforce version control. Predictably reliable.
http://pubads.g.doubleclick.net/gampad/clk?id=1575
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
47 matches
Mail list logo
