JonY jon_y@... 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 scripts wasn't doing
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
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 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 thought I
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 does,
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 binutils
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 triplet-ar. Nowhere in that little story did any reference
to any triple-gcc-ar ever
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 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/mingw-w64-headers/configure Mon Apr
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
--- a/mingw-w64/mingw-w64-headers/configure Mon Apr
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
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
On 21/6/2012 10:13 AM, Ruben Van Boxem wrote:
Op 19 jun. 2012 20:04 schreef Christer Solskogen
christer.solsko...@gmail.com
mailto:christer.solsko...@gmail.com het
volgende:
I'm using a cross compiler (GCC-4.7.1 and the latest mingw-w64-trunk) on
my FreeBSD machines, and I'm trying
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 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
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
Ruben Van Boxem vanboxem.ruben@... 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
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
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
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 read the archives better
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 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
--
Don't let slow
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 build libgomp
I'll you still need winpthread installed.
--
chs
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
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
On 20.06.2013 05:20, Dongsheng Song wrote:
On Thu, Jun 20, 2013 at 12:35 AM, Christer Solskogen
christer.solsko...@gmail.com 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 compiler to compile
Dongsheng Song 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
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
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
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
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) that
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.
>
Works!
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,
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
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
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
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
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
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_64-w64
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 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 native
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
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
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)
___
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-83\bin
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
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? Crossed
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.
mingw-w
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
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
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/mingw
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
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’:
53 matches
Mail list logo
