[Mingw-w64-public] Unable to cross compile SDL2
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.c:657:13: error: unknown type name ‘__FIReference_1_int’; did you mean ‘__FIReference_1_INT32’? 657 | __FIReference_1_int *full_capacityP, *curr_capacityP; | ^~~ | __FIReference_1_INT32 In file included from /tmp/cross-mingw-w64/x86_64-w64-mingw32/include/windows.gaming.input.h:622, from ../src/joystick/windows/SDL_windows_gaming_input.c:33: ../src/joystick/windows/SDL_windows_gaming_input.c:659:114: warning: passing argument 2 of ‘report->lpVtbl->get_FullChargeCapacityInMilliwattHours’ from incompatible pointer type [-Wincompatible-pointer-types] 659 | hr = __x_ABI_CWindows_CDevices_CPower_CIBatteryReport_get_FullChargeCapacityInMilliwattHours(report, _capacityP); | ^~~ | | | int ** ../src/joystick/windows/SDL_windows_gaming_input.c:659:114: note: expected ‘__FIReference_1_INT32 **’ but argument is of type ‘int **’ ../src/joystick/windows/SDL_windows_gaming_input.c:661:17: warning: implicit declaration of function ‘__FIReference_1_int_get_Value’ [-Wimplicit-function-declaration] 661 | __FIReference_1_int_get_Value(full_capacityP, _capacity); | ^ ../src/joystick/windows/SDL_windows_gaming_input.c:662:17: warning: implicit declaration of function ‘__FIReference_1_int_Release’ [-Wimplicit-function-declaration] 662 | __FIReference_1_int_Release(full_capacityP); | ^~~ ../src/joystick/windows/SDL_windows_gaming_input.c:665:113: warning: passing argument 2 of ‘report->lpVtbl->get_RemainingCapacityInMilliwattHours’ from incompatible pointer type [-Wincompatible-pointer-types] 665 | hr = __x_ABI_CWindows_CDevices_CPower_CIBatteryReport_get_RemainingCapacityInMilliwattHours(report, _capacityP); | ^~~ | | | int ** ../src/joystick/windows/SDL_windows_gaming_input.c:665:113: note: expected ‘__FIReference_1_INT32 **’ but argument is of type ‘int **’ make: *** [Makefile:730: build/SDL_windows_gaming_input.lo] Error 1 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Parallel compiling (sometimes) fails
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-w64-crt$ x86_64-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/tmp/cross-mingw-w64/lib/gcc/x86_64-w64-mingw32/11.2.0/lto-wrapper Target: x86_64-w64-mingw32 Configured with: /home/builder/gcc/configure --prefix=/tmp/cross-mingw-w64 --libexecdir=/tmp/cross-mingw-w64/lib --target=x86_64-w64-mingw32 --enable-languages=c,c++ --disable-libstdcxx-pch --enable-libgomp --enable-threads=posix --with-sysroot=/tmp/cross-mingw-w64 --with-checking=release --with-system-zlib Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.2.0 (GCC) builder@champ:/tmp/build/mingw-w64-crt$ x86_64-w64-mingw32-ld -v GNU ld (GNU Binutils) 2.38 Known problem, or something to file a bug for? This sounds a lot like https://sourceware.org/bugzilla/show_bug.cgi?id=28885 - but that one wouldn't manifest if you're building the v10 release, only with older releases. (In latest mingw-w64, that bug would be masked by 0ad299826ca14987fd53664c1047f4dfe848c3f8.) To have any clue about what it is, if it isn't this, you'd need to provide the build log, along with the command that failed and its output (which usually would be buried somewhere in the build log, if building with lots of parallel jobs). x86_64-w64-mingw32-dlltool --as-flags=--32 -m i386 -k --as=x86_64-w64-mingw32-as --output-lib lib32/libd3dx9.a --temp-prefix $(basename lib32/libd3dx9.a .a) --input-def /home/builder/mingw-w64/mingw-w64-crt/lib32/d3dx9_43.def x86_64-w64-mingw32-dlltool: lib32/libd3dx9.a: error reading libd3dx9h.o: file truncated As I have a workaround I'll wait until a newer binutils is released, and check if it happens there as well. Thanks :) ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Parallel compiling (sometimes) fails
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 COLLECT_LTO_WRAPPER=/tmp/cross-mingw-w64/lib/gcc/x86_64-w64-mingw32/11.2.0/lto-wrapper Target: x86_64-w64-mingw32 Configured with: /home/builder/gcc/configure --prefix=/tmp/cross-mingw-w64 --libexecdir=/tmp/cross-mingw-w64/lib --target=x86_64-w64-mingw32 --enable-languages=c,c++ --disable-libstdcxx-pch --enable-libgomp --enable-threads=posix --with-sysroot=/tmp/cross-mingw-w64 --with-checking=release --with-system-zlib Thread model: posix Supported LTO compression algorithms: zlib gcc version 11.2.0 (GCC) builder@champ:/tmp/build/mingw-w64-crt$ x86_64-w64-mingw32-ld -v GNU ld (GNU Binutils) 2.38 Known problem, or something to file a bug for? ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] undefined reference to __udivmoddi4 with GCC 11.1.0
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 Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Build error libgomp
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-w64 is from the latest v8.x branch. This error is caused by the new behavior of stdio format specifiers. Now when compiling with at least C99 or C++11 standard, mingw-w64 stdio functions are enabled by default (unless suppressed by defining `__USE_MINGW_ANSI_STDIO` to zero) so `PRId64` now expands to `lld` instead of the old MS-specified `I64d`. libgomp has the `printf` format attribute so its diagnostic functions do not recognize standard specifiers and cause errors. A patch for GCC 10 is available here [1]. [1] https://github.com/msys2/MINGW-packages-dev/blob/68b5075842e2d13191f31a8619dfb262d73beb6a/mingw-w64-gcc-git/0020-libgomp-Don-t-hard-code-MS-printf-attributes.patch Thank you for the explanation! -- chs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Build error libgomp
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 ("present clause: !acc_is_present (%p, "
| ^~~
In file included from /home/builder/gcc/libgomp/target.c:36:
/tmp/cross-mingw-w64/x86_64-w64-mingw32/include/inttypes.h:36:18: note:
format string is defined here
36 | #define PRIu64 "llu"
| ^
/home/builder/gcc/libgomp/target.c:1228:21: error: unknown conversion
type character ‘l’ in format [-Werror=format=]
1228 | gomp_fatal ("present clause: !acc_is_present (%p, "
| ^~~
In file included from /home/builder/gcc/libgomp/target.c:36:
/tmp/cross-mingw-w64/x86_64-w64-mingw32/include/inttypes.h:37:18: note:
format string is defined here
37 | #define PRIx64 "llx"
| ^
/home/builder/gcc/libgomp/target.c:1228:21: error: too many arguments
for format [-Werror=format-extra-args]
1228 | gomp_fatal ("present clause: !acc_is_present (%p, "
| ^~~
cc1: all warnings being treated as errors
gmake[4]: *** [Makefile:827: target.lo] Error 1
gmake[4]: Leaving directory
'/tmp/build/gcc.x86_64-w64-mingw32/x86_64-w64-mingw32/libgomp'
gmake[3]: *** [Makefile:1057: all-recursive] Error 1
gmake[3]: Leaving directory
'/tmp/build/gcc.x86_64-w64-mingw32/x86_64-w64-mingw32/libgomp'
gmake[2]: *** [Makefile:648: all] Error 2
gmake[2]: Leaving directory
'/tmp/build/gcc.x86_64-w64-mingw32/x86_64-w64-mingw32/libgomp'
gmake[1]: *** [Makefile:15784: all-target-libgomp] Error 2
gmake[1]: Leaving directory '/tmp/build/gcc.x86_64-w64-mingw32'
gmake: *** [Makefile:966: all] Error 2
Is this a gcc problem or mingw-w64 problem? Or perhaps "my" problem if
I've configured something wrongly.
mingw-w64 is from the latest v8.x branch.
--
chs
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Issue with documentation for building CRT and GCC
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 configure options, lib32 is still built. I'd have to say there is an error in the documentation, or the configure script is not working as expected. --disable-multilib is for GCC's configure script. --disable-multilib doesn't really disable the multilib capability of the compiler, it just disables the build of the 32bit versions of the gcc libraries (for instance libstdc++) - So if you only want 64bit mingw-w64, you must add --disable-lib32 to mingw-w64-crt's configure script. -- chs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] --enable-experimental breaks as
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\gcc.exe COLLECT_LTO_WRAPPER=f:/msys/m64-83/bin/../libexec/gcc/x86_64-w64-mingw32/8.2.1/lto-wrapper.exe Target: x86_64-w64-mingw32 Configured with: /home/ma/m/source/gcc-8/configure --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++,objc,obj-c++ --with-gmp=/home/ma/m/build/for_target --with-mpfr=/home/ma/m/build/for_target --with-mpc=/home/ma/m/build/for_target --with-isl=/home/ma/m/build/for_target --enable-twoprocess --disable-libstdcxx-pch --disable-win32-registry --disable-shared --enable-fully-dynamic-string --prefix=/home/ma/m/target --with-sysroot=/home/ma/m/target Thread model: win32 gcc version 8.2.1 20190125 (GCC) GNU ld (GNU Binutils) 2.32.51.20190125 It is fixed for binary zero in *.s file, but there is no binary zero in my *.s file. And was the native compiler cross compiled from Linux? Yes, Ubuntu 16.04, build script close to https://sourceforge.net/projects/mingw-w64-dgn/ Cross compiler was build without '--enable-experimental --enable-wildcard'. I've added '--enable-experimental --enable-wildcard' options only to rebuild_target.sh it is close to https://sourceforge.net/p/mingw-w64-dgn/code/HEAD/tree/trunk/rebuild_target.sh And that is perhaps the culpit. My cross compiler was built with '--enable-experimental' (I did not recompile mingw-crt for the crossed compiler, I just copied the libs and headers. No reason to compile them again) -- chs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] --enable-experimental breaks as
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-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] --enable-experimental breaks as
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 compiler? Hosted?) with mingw-w64-crt configured with "--enable-experimental" I get this (on Windows). Could you post your mingw-w64-crt configure options to reproduce the problem (did you use --enable-experimental all or --enable-experimental printf128)? "--enable-experimental --enable-wildcard" Which enables all of the experimental options, I guess. -- chs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] --enable-experimental breaks as
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 mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] --enable-experimental breaks as
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 Windows compiler (what do you really call that? Crossed compiler? Hosted?) with mingw-w64-crt configured with "--enable-experimental" I get this (on Windows). Internal error in stringer at /home/builder/binutils-2.31.1/gas/read.c:5366. Please report this bug. gas shouldn't be reporting an internal error here. Very likely you have a wrongly quoted string in the input to gas. Please open a bug at https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils with the input to gas (.s file) attached. Done. https://sourceware.org/bugzilla/show_bug.cgi?id=24125 There is a difference between them. The working .S file has: .ascii "Hello world!\0" The not working .S file has: .ascii "Hello world!\ " (notepad++ says: !\NUL" instead of the whitespace. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] --enable-experimental breaks as
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 Windows). Internal error in stringer at /home/builder/binutils-2.31.1/gas/read.c:5366. Please report this bug. I get the same error with a simple Hello World in either C and C++ (alas both gcc.exe and g++.exe produce the error) If I compile mingw-w64-crt without "--enable-experimental" I do not see that error. Not sure if it means anything, but the crossed compiler is multilib. cross-binutils is configured like this: /home/builder/binutils-2.31.1/configure --prefix=/opt/cross --target=x86_64-w64-mingw32 cross-gcc: /home/builder/gcc-8/configure --prefix=/opt/cross --libexecdir=/opt/cross/lib --target=x86_64-w64-mingw32 --enable-languages=c,c++ --disable-libstdcxx-pch --enable-libgomp --enable-threads=posix --with-sysroot=/opt/cross crossed-binutils: /home/builder/binutils-2.31.1/configure --prefix=/mingw64 --host=x86_64-w64-mingw32 crossed-gcc: /home/builder/gcc-8/configure --prefix=/mingw64 --libexecdir=/mingw64/lib --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --enable-languages=c,c++ --disable-libstdcxx-pch --enable-libgomp --enable-threads=posix -- chs ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Multilib build
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-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/mingw/lib/libkernel32.a when searching for -lkernel32 /opt/cross/x86_64-w64-mingw32/bin/ld: skipping incompatible /opt/cross/mingw/lib/libkernel32.a when searching for -lkernel32 /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/x86_64-w64-mingw32/lib/libkernel32.a when searching for -lkernel32 /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/x86_64-w64-mingw32/lib/libkernel32.a when searching for -lkernel32 /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/mingw/lib/libkernel32.a when searching for -lkernel32 /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/x86_64-w64-mingw32/lib/libkernel32.a when searching for -lkernel32 builder@friend:/opt/cross/x86_64-w64-mingw32$ ls -l total 92 drwxrwxr-x 2 builder builder 4096 Jan 12 11:34 bin drwxrwxr-x 10 builder builder 36864 Jan 12 11:34 include drwxrwxr-x 2 builder builder 32768 Jan 12 11:34 lib drwxrwxr-x 2 builder builder 20480 Jan 12 11:34 lib32 lrwxrwxrwx 1 builder builder 3 Jan 12 11:36 lib64 -> lib binutils is configured like this: --prefix=/opt/cross --target=x86_64-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 gcc like this: --prefix=/opt/cross --libexecdir=/opt/cross/lib --target=x86_64-w64-mingw32 --enable-languages=c,c++ --disable-libstdcxx-pch --enable-checking=release --enable-libgomp --enable-threads=posix --enable-multilib --enable-version-specific-runtime-libs --with-system-zlib I'm not sure I really need --enable-multilib on gcc, as it seems like it is default. mingw-w64-crt and winpthread was built successfully. I'm I doing something wrong? binutils-2.31.1 and gcc-8.2.0 was used. The solution was that in order to get gcc to recognize the 32bit libraries, gcc must be compiled with --with-sysroot. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Multilib build
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/x86_64-w64-mingw32/lib/libkernel32.a when searching for -lkernel32 /opt/cross/x86_64-w64-mingw32/bin/ld: skipping incompatible /opt/cross/mingw/lib/libkernel32.a when searching for -lkernel32 /opt/cross/x86_64-w64-mingw32/bin/ld: skipping incompatible /opt/cross/mingw/lib/libkernel32.a when searching for -lkernel32 /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/x86_64-w64-mingw32/lib/libkernel32.a when searching for -lkernel32 /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/x86_64-w64-mingw32/lib/libkernel32.a when searching for -lkernel32 /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/mingw/lib/libkernel32.a when searching for -lkernel32 /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/x86_64-w64-mingw32/lib/libkernel32.a when searching for -lkernel32 builder@friend:/opt/cross/x86_64-w64-mingw32$ ls -l total 92 drwxrwxr-x 2 builder builder 4096 Jan 12 11:34 bin drwxrwxr-x 10 builder builder 36864 Jan 12 11:34 include drwxrwxr-x 2 builder builder 32768 Jan 12 11:34 lib drwxrwxr-x 2 builder builder 20480 Jan 12 11:34 lib32 lrwxrwxrwx 1 builder builder 3 Jan 12 11:36 lib64 -> lib binutils is configured like this: --prefix=/opt/cross --target=x86_64-w64-mingw32 --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 gcc like this: --prefix=/opt/cross --libexecdir=/opt/cross/lib --target=x86_64-w64-mingw32 --enable-languages=c,c++ --disable-libstdcxx-pch --enable-checking=release --enable-libgomp --enable-threads=posix --enable-multilib --enable-version-specific-runtime-libs --with-system-zlib I'm not sure I really need --enable-multilib on gcc, as it seems like it is default. mingw-w64-crt and winpthread was built successfully. I'm I doing something wrong? binutils-2.31.1 and gcc-8.2.0 was used. ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 v5 and gcc 8 fails
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 community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] mingw-w64 v5 and gcc 8 fails
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/include -D_CRTBLD -I/home/solskogen/obj/cross-mingw-w64/x86_64-w64-mingw32/include -pipe -std=gnu99 -D_WIN32_WINNT=0x0f00 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -g -O2 -MT intrincs/lib64_libkernel32_a-rdtsc.o -MD -MP -MF intrincs/.deps/lib64_libkernel32_a-rdtsc.Tpo -c -o intrincs/lib64_libkernel32_a-rdtsc.o `test -f 'intrincs/rdtsc.c' || echo '/home/solskogen/mingw-w64-builder/trunk/lib/mingw-w64/mingw-w64-crt/'`intrincs/rdtsc.c In file included from /tmp/obj/cross-mingw-w64/lib/gcc/x86_64-w64-mingw32/8.1.1/include/x86intrin.h:74, from /tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/intrin.h:73, from /home/solskogen/mingw-w64-builder/trunk/lib/mingw-w64/mingw-w64-crt/intrincs/rdtsc.c:10: /tmp/obj/cross-mingw-w64/lib/gcc/x86_64-w64-mingw32/8.1.1/include/xsaveintrin.h:60:1: error: conflicting types for '_xgetbv' _xgetbv (unsigned int __A) ^~~ In file included from /tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/intrin.h:41, from /home/solskogen/mingw-w64-builder/trunk/lib/mingw-w64/mingw-w64-crt/intrincs/rdtsc.c:10: /tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/psdk_inc/intrin-impl.h:1412:18: note: previous definition of '_xgetbv' was here unsigned __int64 _xgetbv(unsigned int index) ^~~ Makefile:28152: recipe for target 'intrincs/lib64_libkernel32_a-rdtsc.o' failed make[1]: *** [intrincs/lib64_libkernel32_a-rdtsc.o] Error 1 make[1]: Leaving directory '/tmp/obj/_build/mingw-w64.crt.cross.x86_64-w64-mingw32' Makefile:7778: recipe for target 'all' failed make: *** [all] Error 2 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Large file support?
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 engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Crash with Windows 7
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 your source with `-ggdb` or `-g3`, then run it from GDB. As soon as the crash happens, type `backtrace` or `bt` then press Enter in GDB to get the backtrace. Thanks! That helped. The problem seems to be in SDL2. SDL-2.0.5 does not crash, but 2.0.6 and 2.0.7 do. -- chs -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Crash with Windows 7
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 versions of the emulator crash. I've used Windows 7 in both 32bit and 64bit versions. I know that this is not enough information to help me, but my question is... How do I investigate this further? The cross compiler used is something I've compiled myself. Using built-in specs. COLLECT_GCC=/opt/cross-mingw-w64/bin/x86_64-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/opt/cross-mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.1/lto-wrapper Target: x86_64-w64-mingw32 Configured with: /home/solskogen/mingw-w64-builder/trunk/bin/gcc/configure --prefix=/home/solskogen/obj/cross-mingw-w64 --libexecdir=/home/solskogen/obj/cross-mingw-w64/lib --target=x86_64-w64-mingw32 --disable-nls --enable-languages=c,c++ --enable-libgomp --disable-libstdcxx-pch --enable-checking=release --enable-threads=win32 --disable-multilib --with-sysroot=/home/solskogen/obj/cross-mingw-w64 Thread model: win32 gcc version 7.2.1 20171115 (GCC) mingw version is 5.x (from git) -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] winpthreads/src/dll_math.c: Implement `__divmoddi4()' for GCC 7.
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, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] winpthreads and gcc 7.1
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! Thanks! \o/ -- chs -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Trouble cross-compiling SDL2
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 has no
IID_IDXGIFactory2.
The fix is to remove
static const GUID IID_IDXGIFactory2 = { 0x50c83a1c, 0xe072, 0x4c48, { 0x87,
0xb0, 0x36, 0x30, 0xfa, 0x36, 0xa6, 0xd0 } };
from SDL2 (or at least ifdef it out based on some macro from dxgi1_2.h).
At a glance, anyway.
Okay? Compiling SDL2 using v3.x (git) works just fine.
--
chs
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Trouble cross-compiling SDL2
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 compile SDL1 without any issues.
This is what SDL2 gives me:
CC build/SDL_render_d3d11.lo
/home/solskogen/mingw-w64-builder/trunk/lib/sdl2/src/render/direct3d11/SDL_render_d3d11.c:140:19:
error: static declaration of 'IID_IDXGIFactory2' follows non-static
declaration
static const GUID IID_IDXGIFactory2 = { 0x50c83a1c, 0xe072, 0x4c48, {
0x87, 0xb0, 0x36, 0x30, 0xfa, 0x36, 0xa6, 0xd0 } };
^
In file included from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/combaseapi.h:156:0,
from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/objbase.h:14,
from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/ole2.h:17,
from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/d3d11_1.h:12,
from
/home/solskogen/mingw-w64-builder/trunk/lib/sdl2/src/render/direct3d11/SDL_render_d3d11.c:34:
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/dxgi1_2.h:759:1:
note: previous declaration of 'IID_IDXGIFactory2' was here
DEFINE_GUID(IID_IDXGIFactory2, 0x50c83a1c, 0xe072, 0x4c48, 0x87,0xb0,
0x36,0x30,0xfa,0x36,0xa6,0xd0);
^
/home/solskogen/mingw-w64-builder/trunk/lib/sdl2/src/render/direct3d11/SDL_render_d3d11.c:141:19:
error: static declaration of 'IID_IDXGIDevice1' follows non-static
declaration
static const GUID IID_IDXGIDevice1 = { 0x77db970f, 0x6276, 0x48ba, {
0xba, 0x28, 0x07, 0x01, 0x43, 0xb4, 0x39, 0x2c } };
^
In file included from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/combaseapi.h:156:0,
from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/objbase.h:14,
from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/ole2.h:17,
from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/d3d11_1.h:12,
from
/home/solskogen/mingw-w64-builder/trunk/lib/sdl2/src/render/direct3d11/SDL_render_d3d11.c:34:
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/dxgi.h:2501:1: note:
previous declaration of 'IID_IDXGIDevice1' was here
DEFINE_GUID(IID_IDXGIDevice1, 0x77db970f, 0x6276, 0x48ba, 0xba,0x28,
0x07,0x01,0x43,0xb4,0x39,0x2c);
^
/home/solskogen/mingw-w64-builder/trunk/lib/sdl2/src/render/direct3d11/SDL_render_d3d11.c:143:19:
error: static declaration of 'IID_ID3D11Texture2D' follows non-static
declaration
static const GUID IID_ID3D11Texture2D = { 0x6f15aaf2, 0xd208, 0x4e89,
{ 0x9a, 0xb4, 0x48, 0x95, 0x35, 0xd3, 0x4f, 0x9c } };
^
In file included from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/combaseapi.h:156:0,
from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/objbase.h:14,
from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/ole2.h:17,
from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/d3d11_1.h:12,
from
/home/solskogen/mingw-w64-builder/trunk/lib/sdl2/src/render/direct3d11/SDL_render_d3d11.c:34:
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/d3d11.h:4533:1:
note: previous declaration of 'IID_ID3D11Texture2D' was here
DEFINE_GUID(IID_ID3D11Texture2D, 0x6f15aaf2, 0xd208, 0x4e89,
0x9a,0xb4, 0x48,0x95,0x35,0xd3,0x4f,0x9c);
^
/home/solskogen/mingw-w64-builder/trunk/lib/sdl2/src/render/direct3d11/SDL_render_d3d11.c:144:19:
error: static declaration of 'IID_ID3D11Device1' follows non-static
declaration
static const GUID IID_ID3D11Device1 = { 0xa04bfb29, 0x08ef, 0x43d6, {
0xa4, 0x9c, 0xa9, 0xbd, 0xbd, 0xcb, 0xe6, 0x86 } };
^
In file included from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/combaseapi.h:156:0,
from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/objbase.h:14,
from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/ole2.h:17,
from
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/d3d11_1.h:12,
from
/home/solskogen/mingw-w64-builder/trunk/lib/sdl2/src/render/direct3d11/SDL_render_d3d11.c:34:
/tmp/obj/cross-mingw-w64/x86_64-w64-mingw32/include/d3d11_1.h:2351:1:
note: previous declaration of 'IID_ID3D11Device1' was here
DEFINE_GUID(IID_ID3D11Device1, 0xa04bfb29, 0x08ef, 0x43d6, 0xa4,0x9c,
0xa9,0xbd,0xbd,0xcb,0xe6,0x86);
.
I've tried both the latest SDL2 release (2.0.3) and the latest from
mercurial.
Any hints?
--
chs
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility
Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?
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 specify --target as well. Without it, gcc will try to build target libraries with the system compiler. -- chs -- Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more! Discover the easy way to master current and previous Microsoft technologies and advance your career. Get an incredible 1,500+ hours of step-by-step tutorial videos with LearnDevNow. Subscribe today and save! http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] OpenGL headers
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 -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?
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 and I have no problem building 4.8. -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?
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/cauchy/obj/native/gcc-4.8-win32/gcc/gcc' g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti ^^ Should not be there. What you should see is x86_64-w64-mingw32-g++. And tells me that you probably have the wrong --host setting for configure. Gcc needs something like --target=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --build=x86_64-unknown-linux-gnu -- chs -- This SF.net email is sponsored by Windows: Build for Windows Store. http://p.sf.net/sfu/windows-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Does anyone use Linux cross-build gcc 4.8 compiler to build native compiler success ?
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 native Windows
compiler, gcc 4.7 success, gcc 4.8 failed with same build script like
this:
make[2]: Entering directory `/home/cauchy/obj/native/gcc-4.8-win32/gcc/gcc'
g++ -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti
^^
Should not be there. What you should see is x86_64-w64-mingw32-g++. And
tells me that you probably have the wrong --host setting for configure.
Gcc needs something like --target=x86_64-w64-mingw32
--host=x86_64-w64-mingw32 --build=x86_64-unknown-linux-gnu
--
chs
This is gcc 4.8 wrong, since I have passed the correct settings:
$ echo ${GCC_SRC_ROOT}/configure \
--prefix=${SYS_ROOT} \
--with-sysroot=${SYS_ROOT} \
--build=${BUILD_TRIPLET} --host=${TARGET_TRIPLET}
--target=${TARGET_TRIPLET} \
--disable-multilib --disable-nls --disable-win32-registry \
--enable-checking=release --enable-languages=c,c++,fortran \
--with-fpmath=sse \
--with-gmp=${SYS_3RD_ROOT} --with-mpfr=${SYS_3RD_ROOT}
--with-mpc=${SYS_3RD_ROOT}
/home/cauchy/vcs/svn/gcc/branches/gcc-4_8-branch/configure
--prefix=/home/cauchy/native/gcc-4.8-win32
--with-sysroot=/home/cauchy/native/gcc-4.8-win32
--build=x86_64-unknown-linux-gnu --host=i686-w64-mingw32
--target=i686-w64-mingw32 --disable-multilib --disable-nls
--disable-win32-registry --enable-checking=release
--enable-languages=c,c++,fortran --with-fpmath=sse
--with-gmp=/home/cauchy/native/gcc-4.8-win32-3rd
--with-mpfr=/home/cauchy/native/gcc-4.8-win32-3rd
--with-mpc=/home/cauchy/native/gcc-4.8-win32-3rd
Could you post $CC, $CFLAGS and/or $CXXFLAGS? Also the output of gcc -v
and i686-w64-mingw32-gcc -v?
--
chs
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] build ncurses
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/transform.o -I../progs -I. -DHAVE_CONFIG_H -D_XOPEN_SOURCE=500 -D_POSIX_C_SOURCE=199506L -D_FILE_OFFSET_BITS=64 -DNDEBUG -I. -I../include -I/usr/local/include/ncurses -O2 --param max-inline-insns-single=1200 -static -L../lib -lncurses -L../lib -lncurses -dynamic -o tic.exe x86_64-w64-mingw32-gcc ../objects/infocmp.o ../objects/dump_entry.o -I../progs -I. -DHAVE_CONFIG_H -D_XOPEN_SOURCE=500 -D_POSIX_C_SOURCE=199506L -D_FILE_OFFSET_BITS=64 -DNDEBUG -I. -I../include -I/usr/local/include/ncurses -O2 --param max-inline-insns-single=1200 -static -L../lib -lncurses -L../lib -lncurses -dynamic -o infocmp.exe x86_64-w64-mingw32-gcc ../objects/clear.o -I../progs -I. -DHAVE_CONFIG_H -D_XOPEN_SOURCE=500 -D_POSIX_C_SOURCE=199506L -D_FILE_OFFSET_BITS=64 -DNDEBUG -I. -I../include -I/usr/local/include/ncurses -O2 --param max-inline-insns-single=1200 -static -L../lib -lncurses -dynamic -o clear.exe ../lib/libncurses.a(lib_ttyflags.o):lib_ttyflags.c:(.text+0x69): undefined reference to `_nc_mingw_ioctl' ../lib/libncurses.a(lib_ttyflags.o):lib_ttyflags.c:(.text+0x169): undefined reference to `_nc_mingw_ioctl' /opt/cross-mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.3/../../../../x86_64-w64-mingw32/bin/ld: ../lib/libncurses.a(lib_ttyflags.o): bad reloc address 0x0 in section `.pdata' /opt/cross-mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.3/../../../../x86_64-w64-mingw32/bin/ld: final link failed: Invalid operation collect2: error: ld returned 1 exit status make[1]: *** [clear.exe] Error 1 make[1]: Leaving directory `/data/home/solskogen/temp/ncurses-5.9/progs' gcc-4.7 mingw-w64-2.x -- chs -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project news | Project changes]
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 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project news | Project changes]
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 site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Project news | Project changes]
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 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] undefined reference to `__register_frame' on building llvm/clang
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 -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] undefined reference to `__register_frame' on building llvm/clang
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. I just saw Ruben's post. -- chs -- Don't let slow site performance ruin your business. Deploy New Relic APM Deploy New Relic app performance management and know exactly what is happening inside your Ruby, Python, PHP, Java, and .NET app Try New Relic at no cost today and get our sweet Data Nerd shirt too! http://p.sf.net/sfu/newrelic-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] ansidecl.h in cross compiler
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 -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] rubenvb GCC 4.8 x64 SEH build
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 something that the GCC 4.7.x did not. Also, a tip: With 4.8 you can compile all the dependencies for GCC (gmp,mpfr,mpc,cloog and ppl) statically. Also, if all the prereqs are installed in the same directory you only need to tell GCC's configure where gmp is and where isl is. It will figure out the rest by it self. This is my configure line (for creating a native windows compiler) prefix=/home/solskogen/obj/mingw64 --build=x86_64-unknown-freebsd9.1 --target=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --disable-nls --with-gmp=/home/solskogen/obj/prereq.x86_64-w64-mingw32 --with-isl=/home/solskogen/obj/prereq.x86_64-w64-mingw32 --enable-languages=c,c++ --with-sysroot=/home/solskogen/obj/mingw64 --enable-checking=release --enable-gomp --with-threads=win32 --disable-win32-registry --enable-shared --enable-static -- 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 endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Any luck creating a native multilib capable gcc?
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 endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Ruben's builds: native or cross-compiled?
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 compilers and not native ones. Yes, and no. A cross compiler will be prefixed, but a compiler created by a cross compiler would /probably/ be not prefixed. To create a cross compiler with GCC you must compile it with something like this: --build=x86_64-unknown-linux-gnu --target=powerpc-unknown-linux-gnu --host=x86_64-unknown-linux-gnu. That cross compiler will be named powerpc-unknown-linux-gnu-gcc. The configure line means that the compiler will be built on a x86_64-unknown-linux-gnu, will run on a x86_64-unknown-linux-gnu, but will produce binaries that run on powerpc-unknown-linux-gnu. Now, if you want to create a native powerpc compiler with the cross compiler you must use something like this: --build=x86_64-unknown-linux-gnu --target=powerpc-unknown-linux-gnu --host=powerpc-unknown-linux-gnu. And do it at little bit more interestning: --build=x86_64-unknown-linux-gnu --target=sparc-unknown-linux-gnu --host=powerpc-unknown-linux-gnu. That will compile a compiler that is built on x86_64, will run on a powerpc and produce binaries that will run on a sparc. A normal installation of GCC will create both gcc and x86_64-unknown-linux-gcc (dependent on your triplet) -- 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 endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Trouble cross-compiling llvm
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 === --- Errno.cpp (revision 157900) +++ Errno.cpp (working copy) @@ -52,7 +52,7 @@ # endif #elif HAVE_DECL_STRERROR_S // Windows Secure API if (errnum) - strerror_s(buffer, errnum); + strerror_s(buffer, MaxErrStrLen-1, errnum); #elif defined(HAVE_STRERROR) // Copy the thread un-safe result of strerror into // the buffer as fast as possible to minimize impact -- 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 endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Trouble cross-compiling llvm
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 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::string llvm::sys::StrError(int)': /usr/home/solskogen/mingw-w64-builder/llvm/lib/Support/Errno.cpp:55:32: error: too few arguments to function 'errno_t strerror_s(char*, size_t, int)' In file included from /usr/home/solskogen/cross-mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/include/string.h:176:0, from /usr/home/solskogen/mingw-w64-builder/llvm/lib/Support/Errno.cpp:18: /usr/home/solskogen/cross-mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/include/sec_api/string_s.h:19:27: note: declared here rm: /usr/home/solskogen/obj/llvm.native.x86_64-w64-mingw32/lib/Support/Release/Errno.d.tmp: No such file or directory gmake[1]: *** [/usr/home/solskogen/obj/llvm.native.x86_64-w64-mingw32/lib/Support/Release/Errno.o] Error 1 gmake[1]: *** Waiting for unfinished jobs gmake[1]: Leaving directory `/usr/home/solskogen/obj/llvm.native.x86_64-w64-mingw32/lib/Support' gmake: *** [all] Error 1 Creating a native llvm+clang-compiler works fine (that is, using FreeBSDs base compiler to create it) anyone else seeing this? Ruben, maybe? How did you configure LLVM? Last time I checked, everything worked fine (but something might have changed). I'm pretty sure I got it to work as well. I even tried using an older gcc (4.6.3) and a older LLVM/clang, but to no avail. I'm also pretty sure that there is nothing wrong with my configured cross-compiler as I have no trouble creating a native mingw-w64 compiler with it. llvm/configure --prefix=/mingw --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --build=x86_64-unknown-freebsd9.0 I've also tried running this on a Debian machine (same error). I also tried without --target=. I've tried llvm/clang trunk, 3.1 and 3.0. -- 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 endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Trouble cross-compiling llvm
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::string llvm::sys::StrError(int)': /usr/home/solskogen/mingw-w64-builder/llvm/lib/Support/Errno.cpp:55:32: error: too few arguments to function 'errno_t strerror_s(char*, size_t, int)' In file included from /usr/home/solskogen/cross-mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/include/string.h:176:0, from /usr/home/solskogen/mingw-w64-builder/llvm/lib/Support/Errno.cpp:18: /usr/home/solskogen/cross-mingw-w64/bin/../lib/gcc/x86_64-w64-mingw32/4.7.2/../../../../x86_64-w64-mingw32/include/sec_api/string_s.h:19:27: note: declared here rm: /usr/home/solskogen/obj/llvm.native.x86_64-w64-mingw32/lib/Support/Release/Errno.d.tmp: No such file or directory gmake[1]: *** [/usr/home/solskogen/obj/llvm.native.x86_64-w64-mingw32/lib/Support/Release/Errno.o] Error 1 gmake[1]: *** Waiting for unfinished jobs gmake[1]: Leaving directory `/usr/home/solskogen/obj/llvm.native.x86_64-w64-mingw32/lib/Support' gmake: *** [all] Error 1 Creating a native llvm+clang-compiler works fine (that is, using FreeBSDs base compiler to create it) anyone else seeing this? Ruben, maybe? -- 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 endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] cross multilib binutils
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 -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] ddk headers missing
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 02 12:28:19 2012
+0200
Your change should be to configure.ac. The configure script itself is
generated by autoconf.
Ups, missed this one. Since I also regenrated configure the patch got a
bit bigger. Probably because I've got newer GNU tools installed.
Index: mingw-w64-headers/configure
===
--- mingw-w64-headers/configure (revision 4950)
+++ mingw-w64-headers/configure (working copy)
@@ -2236,17 +2236,17 @@
# We need awk for the check target. The system awk is bad on
# some platforms.
-# Always define AMTAR for backward compatibility.
+# Always define AMTAR for backward compatibility. Yes, it's still used
+# in the wild :-( We should find a proper way to deprecate it ...
+AMTAR='$${TAR-tar}'
-AMTAR=${AMTAR-${am_missing_run}tar}
+am__tar='$${TAR-tar} chof - $$tardir' am__untar='$${TAR-tar} xf -'
-am__tar='${AMTAR} chof - $$tardir'; am__untar='${AMTAR} xf -'
-
{ $as_echo $as_me:${as_lineno-$LINENO}: checking whether to enable
maintainer-specific portions of Makefiles 5
$as_echo_n checking whether to enable maintainer-specific portions of
Makefiles... 6; }
# Check whether --enable-maintainer-mode was given.
@@ -2561,7 +2561,7 @@
enable_directx=no
enable_ddk=no
-if test -d ddk/include/ddk
+if test -d ${srcdir}/ddk/include/ddk
then
# DDK headers have been fetched from ReactOS
ddk_present=yes
Index: mingw-w64-headers/Makefile.in
===
--- mingw-w64-headers/Makefile.in (revision 4950)
+++ mingw-w64-headers/Makefile.in (working copy)
@@ -1,9 +1,9 @@
-# Makefile.in generated by automake 1.11.1 from Makefile.am.
+# Makefile.in generated by automake 1.11.4 from Makefile.am.
# @configure_input@
# Copyright (C) 1994, 1995, 1996, 1997, 1998, 1999, 2000, 2001, 2002,
-# 2003, 2004, 2005, 2006, 2007, 2008, 2009 Free Software Foundation,
-# Inc.
+# 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 Free Software
+# Foundation, Inc.
# This Makefile.in is free software; the Free Software Foundation
# gives unlimited permission to copy and/or distribute it,
# with or without modifications, as long as this notice is preserved.
@@ -16,6 +16,23 @@
@SET_MAKE@
VPATH = @srcdir@
+am__make_dryrun = \
+ { \
+am__dry=no; \
+case $$MAKEFLAGS in \
+ *\\[\ \ ]*) \
+echo 'am--echo: ; @echo AM OK' | $(MAKE) -f - 2/dev/null \
+ | grep '^AM OK$$' /dev/null || am__dry=yes;; \
+ *) \
+for am__flg in $$MAKEFLAGS; do \
+ case $$am__flg in \
+*=*|--*) ;; \
+*n*) am__dry=yes; break;; \
+ esac; \
+done;; \
+esac; \
+test $$am__dry = yes; \
+ }
pkgdatadir = $(datadir)/@PACKAGE@
pkgincludedir = $(includedir)/@PACKAGE@
pkglibdir = $(libdir)/@PACKAGE@
@@ -57,6 +74,11 @@
CONFIG_CLEAN_VPATH_FILES =
SOURCES =
DIST_SOURCES =
+am__can_run_installinfo = \
+ case $$AM_UPDATE_INFO_DIR in \
+n|no|NO) false;; \
+*) (install-info --version) /dev/null 21;; \
+ esac
am__vpath_adj_setup = srcdirstrip=`echo $(srcdir) | sed 's|.|.|g'`;
am__vpath_adj = case $$p in \
$(srcdir)/*) f=`echo $$p | sed s|^$$srcdirstrip/||`;; \
@@ -78,6 +100,12 @@
am__base_list = \
sed '$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;$$!N;s/\n/ /g' | \
sed '$$!N;$$!N;$$!N;$$!N;s/\n/ /g'
+am__uninstall_files_from_dir = { \
+ test -z $$files \
+|| { test ! -d $$dir test ! -f $$dir test ! -r $$dir; } \
+|| { echo ( cd '$$dir' rm -f $$files ); \
+ $(am__cd) $$dir rm -f $$files; }; \
+ }
am__installdirs = $(DESTDIR)$(baseheaddir) $(DESTDIR)$(ddkheaddir) \
$(DESTDIR)$(dxheaddir) $(DESTDIR)$(gdiplusheaddir) \
$(DESTDIR)$(glheaddir) $(DESTDIR)$(idlheaddir) \
@@ -94,12 +122,16 @@
distdir = $(PACKAGE)-$(VERSION)
top_distdir = $(distdir)
am__remove_distdir = \
- { test ! -d $(distdir) \
-|| { find $(distdir) -type d ! -perm -200 -exec chmod u+w {} ';' \
- rm -fr $(distdir); }; }
+ if test -d $(distdir); then \
+find $(distdir) -type d ! -perm -200 -exec chmod u+w {} ';' \
+ rm -rf $(distdir) \
+ || { sleep 5 rm -rf $(distdir); }; \
+ else :; fi
DIST_ARCHIVES = $(distdir).tar.gz
GZIP_ENV = --best
distuninstallcheck_listfiles = find . -type f -print
+am__distuninstallcheck_listfiles = $(distuninstallcheck_listfiles) \
+ | sed 's|^\./|$(prefix)/|' | grep -v '$(infodir)/dir$$'
distcleancheck_listfiles = find . -type f -print
ACLOCAL = @ACLOCAL@
AMTAR = @AMTAR@
@@ -285,7 +317,7 @@
.SUFFIXES:
.SUFFIXES: .h .idl
-am--refresh:
+am--refresh: Makefile
@:
$(srcdir)/Makefile.in
Re: [Mingw-w64-public] ddk headers missing
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 02 08:55:41 2012
+0200
+++ b/mingw-w64/mingw-w64-headers/configure Mon Apr 02 12:28:19 2012
+0200
Your change should be to configure.ac. The configure script itself is
generated by autoconf.
Ups, missed this one. Since I also regenrated configure the patch got a
bit bigger. Probably because I've got newer GNU tools installed.
Please resend in only configure.ac and Makefile.am changes, we'll take
care of the rest.
'ere you go!
--- mingw-w64-headers/configure.ac (revision 4950)
+++ mingw-w64-headers/configure.ac (working copy)
@@ -75,7 +75,7 @@
enable_directx=no
enable_ddk=no
-if test -d ddk/include/ddk
+if test -d ${srcdir}/ddk/include/ddk
then
# DDK headers have been fetched from ReactOS
ddk_present=yes
--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
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 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
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, I'm guessing that is not something you should use directly. -- chs -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
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 at all. If configured and installed correctly you will have ar(or ar.exe) or x86_64-w64-mingw32-ar(if you have installed a cross-binutils). -- chs -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] wrong ar.exe name in ruben's build ?
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 pop up. Autotools doesn't even check for such an executable. of course it does ! No, it does not. i took one of my libs that i cross often compile. I configured it in MSYS by setting --host=i686-w64-mingw32 result: checking for i686-w64-mingw32-ar... no checking for ar... ar So it does check for i686-w64-mingw32-ar... And Ruben just told you that it does not check for i686-w64-mingw32-gcc-ar. Forget about *-gcc-ar already! And no, ar and gcc-ar is not the same thing even if you want it to. -- chs -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] error: 'long long long' is too long for GCC
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 could compile it as well :-) -- chs -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] error: 'long long long' is too long for GCC
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 *** * * * GNU bash, version 4.2.20(1)-release (x86_64-w64-mingw32) * * *** making lib/intl/libintl.a in ./lib/intl gmake[1]: Entering directory `/usr/home/solskogen/temp/bash/lib/intl' x86_64-w64-mingw32-gcc -c -DLOCALEDIR=\/tmp/christer/share/locale\ -DLOCALE_ALIAS_PATH=\/tmp/christer/share/locale\ -DLIBDIR=\/tmp/christer/libdata\ -DIN_LIBINTL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\/tmp/christer/lib\ -DNO_XMALLOC -Dset_relocation_prefix=libintl_set_relocation_prefix -Drelocate=libintl_relocate -DDEPENDS_ON_LIBICONV=1 -DHAVE_CONFIG_H -DSHELL -I. -I. -I/home/solskogen/temp/bash -I../.. -g -O2 loadmsgcat.c In file included from /usr/home/solskogen/cross-tools/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/include/stdint.h:3:0, from /usr/home/solskogen/cross-tools/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/inttypes.h:12, from loadmsgcat.c:86: /usr/home/solskogen/cross-tools/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/stdint.h:68:38: error: 'long long long' is too long for GCC /usr/home/solskogen/cross-tools/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/stdint.h:68:38: error: 'long long long' is too long for GCC /usr/home/solskogen/cross-tools/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/stdint.h:69:48: error: duplicate 'unsigned' /usr/home/solskogen/cross-tools/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/stdint.h:69:48: error: 'long long long' is too long for GCC /usr/home/solskogen/cross-tools/bin/../lib/gcc/x86_64-w64-mingw32/4.6.3/../../../../x86_64-w64-mingw32/include/stdint.h:69:48: error: 'long long long' is too long for GCC gmake[1]: *** [loadmsgcat.o] Error 1 gmake[1]: Leaving directory `/usr/home/solskogen/temp/bash/lib/intl' gmake: *** [lib/intl/libintl.a] Error 1 -- chs -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] unneeded directory?
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 steps would be similar to ./buildlinux64mingw32.sh set PATH=$PWD/linux64mingw32/mingw32/bin:$PATH ./buildmingw32mingw32.sh I managed to get something cool out of your work and mine. As we speak, my toolchain with both gcc and llvm/clang is now buildable on Mac OS X (at least Lion) and FreeBSD 9.0. I would guess (but I haven't tested it yet) it also works fine on Linux. I have tested that both the cross compiler works, and that the resulting native gcc and clang produces .exe-files :-) -- chs -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] unneeded directory?
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 that. Please elaborate. I asked the same thing :-) I got this: http://gcc.gnu.org/ml/gcc-help/2011-12/msg00038.html -- chs -- Virtualization Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
