I'm not sure who's fault it is, but I'm not longer able to cross compile
SDL2:
/bin/bash ../build-scripts/updaterev.sh
CC build/SDL_windows_gaming_input.lo
../src/joystick/windows/SDL_windows_gaming_input.c: In function
‘WGI_JoystickOpen’:
../src/joystick/windows/SDL_windows_gaming_input.
On 04.04.2022 15:37, Martin Storsjö wrote:
On Mon, 4 Apr 2022, Christer Solskogen wrote:
I'm cross compiling mingw-w64-crt on Linux and sometimes compiling
mingw-w64 (v10) fails when using a high(ish) number to make -j. -j8
sometimes fails, -j4 seems to work.
builder@champ:/tmp/build/
I'm cross compiling mingw-w64-crt on Linux and sometimes compiling
mingw-w64 (v10) fails when using a high(ish) number to make -j. -j8
sometimes fails, -j4 seems to work.
builder@champ:/tmp/build/mingw-w64-crt$ x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
C
On 06.05.2021 06:14, sotrdg sotrdg wrote:
BTW. Why do you still use GCC 11.1.0? It is too old. Now it is GCC 12.0.0.
We have used GCC 11 for a year. It is too old.
11.1 was released 27th of April 2021.
--
chs
___
Mingw-w64-public mailing list
M
On 11.12.2020 13:08, Liu Hao wrote:
在 2020/12/11 18:26, Christer Solskogen 写道:
While compiling the mingw-w64 cross compiler I got this with gcc-10.2.0:
(... snip ...)
Is this a gcc problem or mingw-w64 problem? Or perhaps "my" problem if I've
configured something
wrongly.
mi
While compiling the mingw-w64 cross compiler I got this with gcc-10.2.0:
/home/builder/gcc/libgomp/target.c: In function ‘gomp_map_vars_internal’:
/home/builder/gcc/libgomp/target.c:1228:21: error: unknown conversion
type character ‘l’ in format [-Werror=format=]
1228 | gomp_fatal ("pr
On 04.04.2019 19:18, Kacvinsky, Tom wrote:
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 config
On 27.01.2019 20:18, Mateusz wrote:
W dniu 27.01.2019 o 18:40, Christer Solskogen pisze:
On 26.01.2019 01:01, Mateusz wrote:
For me it looks OK.
Which version of binutils? It's fixed in master branch.
$ gcc -v && ld -v
Using built-in specs.
COLLECT_GCC=f:\msys\m64-8
On 26.01.2019 01:01, Mateusz wrote:
For me it looks OK.
Which version of binutils? It's fixed in master branch.
And was the native compiler cross compiled from Linux?
Try with a simple hello world in C (or C++) (without the #define)
___
Mingw-
On 25.01.2019 10:43, Mateusz wrote:
W dniu 21.01.2019 o 21:20, Christer Solskogen pisze:
I've successfully built a multilib compiler on linux targeting both x86_64-w64-mingw32
and i686-w64-mingw32. Using that compiler to compile a native Windows compiler (what do
you really call that? Cr
On 23.01.2019 03:26, Liu Hao wrote:
I have CC'd binutils ML. Hope someone there would know something about GAS.
It's now fixed in binutils. The question is why does
--enable-experimental produce a assembler like that?
___
Mingw-w64-public maili
On 23.01.2019 05:35, Alan Modra wrote:
On Wed, Jan 23, 2019 at 10:26:06AM +0800, Liu Hao wrote:
在 2019/1/22 上午4:20, Christer Solskogen 写道:
I've successfully built a multilib compiler on linux targeting both
x86_64-w64-mingw32 and i686-w64-mingw32. Using that compiler to compile
a n
I've successfully built a multilib compiler on linux targeting both
x86_64-w64-mingw32 and i686-w64-mingw32. Using that compiler to compile
a native Windows compiler (what do you really call that? Crossed
compiler? Hosted?) with mingw-w64-crt configured with
"--enable-experimental" I get this (
On 12.01.2019 11:52, Christer Solskogen wrote:
Hi!
I'm having problems building multilib capable gcc/mingw.
It bails out with this:
/opt/cross/x86_64-w64-mingw32/bin/ld: skipping incompatible
/opt/cross/x86_64-w64-mingw32/lib/libkernel32.a when searching for
-lkernel32
/opt/cross/x86_6
Hi!
I'm having problems building multilib capable gcc/mingw.
It bails out with this:
/opt/cross/x86_64-w64-mingw32/bin/ld: skipping incompatible
/opt/cross/x86_64-w64-mingw32/lib/libkernel32.a when searching for
-lkernel32
/opt/cross/x86_64-w64-mingw32/bin/ld: skipping incompatible
/opt/cross
On 06.05.2018 04:17, JonY via Mingw-w64-public wrote:
Checked, I thought I saw it, must have been on the wrong branch.
Just pushed to the v5.x branch.
And now it works. Thanks!
--
chs
--
Check out the vibrant tech c
It fails with this:
make[1]: Entering directory
'/tmp/obj/_build/mingw-w64.crt.cross.x86_64-w64-mingw32'
x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I.
-I/home/solskogen/mingw-w64-builder/trunk/lib/mingw-w64/mingw-w64-crt
-m64
-I/home/solskogen/mingw-w64-builder/trunk/lib/mingw-w64/mingw-w64-crt/
On 06.03.2018 14:13, JonY via Mingw-w64-public wrote:
Or try recompiling with -D_POSIX=1 -D_FILE_OFFSET_BITS=64.
Thanks, that worked!
--
chs
--
Check out the vibrant tech community on one of the world's most
engagin
Hi!
I've compiled a Atari ST emulator that can record video. The one I've
compiled the emulator crashes when the recorded video reaches a certain
size and from what I can gather it's because off_t is 32bit, even if the
the compiler is x86_64.
Using built-in specs.
COLLECT_GCC=/opt/cross-ming
On 27.11.2017 16:33, Liu Hao wrote:
On 2017/11/27 21:55, Jeremy Nicoll wrote:
On Mon, 27 Nov 2017, at 13:03, Ruben Van Boxem wrote:
It would really helpful there were a backtrace of the crash, so we could
pinpoint where the problem might lie.
How does one capture one on Windows?
Compile all
Hi!
I cross compile a Atari ST(e) emulator called hatari using a Linux
machine. The binary works on Windows 8[.1] and 10, but for some reason
it does not work on Windows 7. Not all binaries produced crashes. A
simple hello world program works on Windows 7 as well.
Both 32bit and 64bit versio
On 08-May-17 12:32, Kai Tietz wrote:
ok, please apply.
Was this ever applied? It seem still to happen with latest 5.x branch.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, S
On 03.05.2017 10.23, Liu Hao wrote:
> On 2017/5/3 15:35, Christer Solskogen wrote:
>> I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
>> with gcc 7.1.
> Please try the attached patch.
>
W
I'm having a hard time (cross) compiling winpthreads (from 5.x branch)
with gcc 7.1.
make[2]: Entering directory
'/tmp/obj/_build/winpthreads.cross.i686-w64-mingw32'
/bin/bash ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -Wall
-DWIN32_LEAN_AND_MEAN -O2 -pipe -no-undefined -version-inf
On 27.04.2015 20:16, LRN wrote:
> At a glance it looks like SDL_render_d3d11.c declares and defines
> IID_IDXGIFactory2, and mingw's dxgi1_2.h declares IID_IDXGIFactory2 as well
> (and defines it in some library, likely libuuid.a).
>
> Apparently, SDL2 was written against a SDK (likely mingw.org)
Hi!
I've got trouble cross compiling SDL2 with the latest and greatest gcc,
binutils and mingw-w64.
gcc version 5.1.0 (GCC)
GNU ld (GNU Binutils) 2.25
and mingw-w64 v4.x (from git)
I don't what is to blame. But I'm pretty sure the cross compiler it self
is in good shape, since I can cross comp
On 6/19/13 11:37 AM, Dongsheng Song wrote:
> I can build i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc under
> Linux, but when I use this compiler to compile native Windows
> compiler, gcc 4.7 success, gcc 4.8 failed with same build script like
> this:
>
I've probably figured it out. You need to
On 01.07.2013 16:02, LRN wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> mingw-w64 should supply GL headers from [1].
> Specifically - GL/glext.h
>
Pardon my french, but why should mingw-w64 supply them?
--
chs
-
Dongsheng Song writes:
Looks fine to me. But I wonder why you build gmp, mpc and mpfr seperatly. You
can just run the gcc/contrib/download_prerequisites script.
Can you post config.log for the native compiler? I have my own set of scripts
which does almost the same as you and I have no problem
On 20.06.2013 05:20, Dongsheng Song wrote:
> On Thu, Jun 20, 2013 at 12:35 AM, Christer Solskogen
> wrote:
>> On 19.06.2013 11:37, Dongsheng Song wrote:
>>> I can build i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc under
>>> Linux, but when I use this comp
On 19.06.2013 11:37, Dongsheng Song wrote:
> I can build i686-w64-mingw32-gcc and x86_64-w64-mingw32-gcc under
> Linux, but when I use this compiler to compile native Windows
> compiler, gcc 4.7 success, gcc 4.8 failed with same build script like
> this:
>
> make[2]: Entering directory `/home/cauch
On 23/3/13 8:47 AM, Ruben Van Boxem wrote:
> What gives?
Don't know. I reported the same error on gcc-help the 10th of January
this year.
--
chs
--
Own the Future-Intel(R) Level Up Game Demo Contest 2013
Rise to g
Have anybody done that?
I get this:
make[1]: Leaving directory `/data/home/solskogen/temp/ncurses-5.9/ncurses'
cd progs && make DESTDIR="" all
make[1]: Entering directory `/data/home/solskogen/temp/ncurses-5.9/progs'
x86_64-w64-mingw32-gcc ../objects/tic.o ../objects/dump_entry.o
../objects/trans
On 07.10.2012 01:31, Christer Solskogen wrote:
> On 07.10.2012 00:10, niXman wrote:
>> 2012/10/7 Christer Solskogen:
>>
>
>>> Does libgomp compile with posix?
>> yes.
>>
>
> Are you sure? I get this:
> configure: error: Pthreads are required to
On 07.10.2012 00:10, niXman wrote:
> 2012/10/7 Christer Solskogen:
>
>> Does libgomp compile with posix?
> yes.
>
Are you sure? I get this:
configure: error: Pthreads are required to build libgomp
--
chs
--
On 06.10.2012 17:37, niXman wrote:
> - 5) x64-4.7.2-release-posix-sjlj
> - 6) x64-4.7.2-release-win32-sjlj
Could you (or somebody else) explain the difference between win32
threading model and posix threading model?
Does libgomp compile with posix?
--
chs
---
On 10/2/12 4:14 PM, Christer Solskogen wrote:
> I get an undefined reference to `__register_frame' when crossbuilding
> llvm/clang(trunk). As far as I could find, that is something that should
> be in libgcc, but it depends that mingw-w64 supports it. Does it?
>
And I should
I get an undefined reference to `__register_frame' when crossbuilding
llvm/clang(trunk). As far as I could find, that is something that should
be in libgcc, but it depends that mingw-w64 supports it. Does it?
--
chs
-
include/ieeefp.h includes ansidecl.h. ansidecl.h is located in
lib/gcc/x86_64-w64-mingw32/4.8.0/plugin/include - but is not picked up
(I saw that when cross compiling Boost) - Is this intended?
(running latest mingw-w64 from trunk)
--
chs
-
Ruben Van Boxem writes:
>
> Hi everyone,I am in the process of uploading a GCC 4.8 experimental build fo
> 64-bit Windows.
I tried it after I used my own toolchain. The thing that I noticed is that both
your toolchain(cc1.exe) and mine crash when compiling Boost. That is something
that the G
Anyone? Ruben?
--
chs
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoi
On 08.09.2012 22:00, Luis Lavena wrote:
> Hello,
>
> I'm starting to use GCC 4.7.1 (win32 threading model) on both win32
> and win64 OS and noticed the executables are no longer prefixed.
>
> Previous builds had the executables prefixed, which I was instructured
> were result of cross-compiled c
On 21/6/2012 10:13 AM, Ruben Van Boxem wrote:
> How did you configure LLVM? Last time I checked, everything worked fine
> (but something might have changed).
>
It was due to a bug in LLVM.
The patch was/is (is fixed in trunk)
Index: Errno.cpp
On 21/6/2012 10:13 AM, Ruben Van Boxem wrote:
>
> Op 19 jun. 2012 20:04 schreef "Christer Solskogen"
> <mailto:christer.solsko...@gmail.com>> het
> volgende:
> >
> > I'm using a cross compiler (GCC-4.7.1 and the latest mingw-w64-trunk) on
>
I'm using a cross compiler (GCC-4.7.1 and the latest mingw-w64-trunk) on
my FreeBSD machines, and I'm trying to use that compiler to create a
native llvm/clang-compiler(trunk) for Windows. But I'm having trouble.
/usr/home/solskogen/mingw-w64-builder/llvm/lib/Support/Errno.cpp: In
function 'std
The wiki page tells us that in order to compile a multilib binutils one
have to add --enable-targets=... I'm not quite sure if that is
necessary. I've just compiled my own without that option, and I have no
problem compiling mingw-w64-crt with both architectures.
--
chs
On 12/4/2012 12:56 PM, JonY wrote:
> On 4/12/2012 18:14, Christer Solskogen wrote:
>> On 2/4/2012 3:21 PM, Earnie Boyd wrote:
>>> On Mon, Apr 2, 2012 at 6:28 AM, Christer Solskogen wrote:
>>>> diff -r 57225b741f27 mingw-w64/mingw-w64-headers/configure
>>
On 2/4/2012 3:21 PM, Earnie Boyd wrote:
> On Mon, Apr 2, 2012 at 6:28 AM, Christer Solskogen wrote:
>> diff -r 57225b741f27 mingw-w64/mingw-w64-headers/configure
>> --- a/mingw-w64/mingw-w64-headers/configure Mon Apr 02 08:55:41 2012
>> +0200
>> +++ b/mingw-w64/
Configuring mingw-w64-headers gives me a warning:
configure: WARNING: svn checkout incomplete, ddk headers missing.
But the headers are there! How do I know? If I run configure in the
mingw-w64-headers directory instead of doing it in a "build" directory I
do not get the same warning. The test
On 21/3-2012 10:00 PM, Vincent Torri wrote:
> Anyway, the fact that i686-w64-mingw32-ar is missing *is* a problem
>
That is true :-) Try downloading Rubens build again and unpack it with a
decent zipper (7z/pk7zip for example)
--
chs
-
On 21/3-2012 8:46 PM, Vincent Torri wrote:
>> as Kai and I pointed out, you misconfigured by not specifying the "--build"
>> option, implicitely telling autotools you were cross-compiling, resulting in
>> it wanting a "-ar". Nowhere in that little story did any reference
>> to any "-gcc-ar" ever p
On 21/3-2012 5:45 PM, Vincent Torri wrote:
> then that's problematic... There is a tool that I don't know what it
> does, and setting host will result in failing because of a missing
> ***-ar.exe
>
But that's most probably your fault. You have configured binutils wrong,
or you don't have binutil
On 16/3/2012 4:52 PM, Vincent Torri wrote:
> the problem i had is that if I pass --host=foobar, the autotools
> search for foobar-ar and not foobar-gcc-ar, hence an error
>
gcc-ar is not the same as ar from binutils. That is something that comes
with gcc 4.7. While I'm not quite sure what is doe
On 19/2-2012 11:59 AM, Ruben Van Boxem wrote:
> It really won't work. At all. MSYS is a minimalistic and old Cygwin,
> which is a POSIX software layer on top of Windows. The MSYS Bash is also
> at version 3.2 or something. Cygwin has 4.2 if I'm not mistaken. MinGW
> != MSYS/Cygwin, it's native Win
On 19/2-2012 1:49 AM, JonY wrote:
>
> Somebody had #define intmax_t long long, likewise for uintmax_t.
>
Umkai? I haven't done that ;-) Is it the default setting for mingw-w64
perhaps?
> Btw, why are you building bash for win64? How does that even work?
>
bash is available in MSYS - so I though
On 2/18/12 10:54 PM, Kai Tietz wrote:
> This issue is related to your project. It defines for what ever
> reason type 'uintmax_t' as something.
>
I'm sorry, but I have no clue of what you said right now. Could you
explain it simpler terms, please?
--
chs
Hi!
I'm trying to cross compile bash with my own built mingw-w64 toolchain,
and I get an error saying error: 'long long long' is too long for GCC.
I wonder if this is a problem with bash or my toolchain. Anyone else
seeing this?
Full log:
$ gmake
On 14.02.12 13:17, Ruben Van Boxem wrote:
> Just FYI, my buildall.sh first builds the linux to Windows
> cross-compilers, which are then used to build the native compilers. As
> an extra, I use the Fedora Mac and Cygwin cross-compilers to build cross
> toolchains from those platforms too.
>
> Your
JonY writes:
>
> On 2/16/2012 02:28, Christer Solskogen wrote:
> > I saw that your scripts have sysroot == prefix. As far as I know, that
> > it not a good thing when creating cross-compiler (but a good thing when
> > you create a native compiler), so I presumed your s
On 2/14/12 13:17 PM, Ruben Van Boxem wrote:
> Just FYI, my buildall.sh first builds the linux to Windows
> cross-compilers, which are then used to build the native compilers.
I saw that your scripts have sysroot == prefix. As far as I know, that
it not a good thing when creating cross-compiler (
Ruben Van Boxem writes:
> My build scripts are maintained on github:
>
> https://github.com/rubenvb/MinGW-w64-build-scripts
>
>
> Just start with a build*.sh and see where it takes you :)
>
Sweet, thanks! I'm probably trying to reinvent the wheel a
bit, but I have a other approach than you
On 11.02.12 18:00, xunxun wrote:
> Because when building gcc, he will search the headers and some libs
> from/mingw/
>
Okay, so it is because gcc is braindead :-) It's not needed elsewhere.
I saw that Ruben Van Boxem have some personal builds which do not
include it as well. I guess that Ruben h
Hi!
I've been playing a bit with creating a mingw-w64 cross compiler, and
used that to create a native mingw-w64 compiler. I haven't done
/exactly/ what the doc says, but the cross compiler works (since it
compiles the native compiler and the resulting binaries works) and the
native compiler i
63 matches
Mail list logo
