| Message ID | a34dced6ae17acc54d13.1351017202@blackmint |
|---|---|
| State | Changes Requested |
| Headers | show |
Yann, All,
Thanks for posting this again.
Overall, the patch looks OK. It built fine on my machine. Yeah! :-)
However, I have a few comments:
1- I'd like to see how hard it would be to commonalise the mingw{32,64}
variants together, eg. take advantage on CT_ARCH_64 to decide what
mingw variant to build.
This would avoid duplicating code path for mingw.
2- In your patch, the DirectX and DDK options are in the mingw64 C library
menu, but are used in the mingw64 kernel build script. That's wrong.
If the option is used in the kernel script, it shall be in the kernel
menu, not the C library menu.
3- Also, this is incoherent with the 32-bit variant, for which the DirectX
option *is* in the C library menu. I'd like that the two variants have
a similar layout in the menu, so that it does not erquire a completely
schyzophrenic user to discover where the options are. ;-)
I see that for the 64-bit variant, the DirectX is provided by the kernel
headers, whereas it is provided by a separate package and build in the
libc_finish step for the 32-bit variant. If we have to change the 32-bit
variant so it more closely ressemble the 64-bit one, so be it.
That will help us commonalise the build scripts and the config files.
4- Other comments in-lined in the patch, below.
On Tuesday 23 October 2012 Yann Diorcet wrote:
> # HG changeset patch
> # User Yann Diorcet <diorcet.yann@gmail.com>
> # Date 1351016048 -7200
> # Node ID a34dced6ae17acc54d132e91805208971e6ac7f4
> # Parent 946d6d133a90935465e3582b54b60c0d7e4e6397
> kernel/mingw64: add mingw64 kernel type
> script: add script for kernel and libc for mingw64
> samples: add 64 bits Windows target sample
> Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com>
As this is primarily adding a new 'kernel', I'd suggest that the commit
log be something like:
kernel/mingw64: new kernel
Add mingw64 as a new kernel for x86_64.
As a dependency, add the mingw64 C library.
Add a sample to build a mingw64 toolchain.
sob: you
If we can commonalise the two mingw variants, then I'd like to see
a patch series, with pathes like:
[PATCH 1/2] kernel/mingw32: rename to mingw to preapare 64-bit variant
[PATCH 2/2] kernel/mingw: add 64-bit variant
Use your imagination to complete the commit log. ;-)
[--SNIP--]
> diff -r 946d6d133a90 -r a34dced6ae17 config/kernel/mingw64.in
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/config/kernel/mingw64.in Tue Oct 23 20:14:08 2012 +0200
> @@ -0,0 +1,33 @@
This file is *very* similar to the 32-bit variant, and would gain in being
folded together.
[--SNIP--]
> diff -r 946d6d133a90 -r a34dced6ae17 config/libc/mingw64.in
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/config/libc/mingw64.in Tue Oct 23 20:14:08 2012 +0200
> @@ -0,0 +1,33 @@
Ditto, very similar.
> diff -r 946d6d133a90 -r a34dced6ae17 config/libc/mingw64.in.2
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/config/libc/mingw64.in.2 Tue Oct 23 20:14:08 2012 +0200
> @@ -0,0 +1,10 @@
> +# Part-2 of mingw C library options: development libraries
> +
> +config MINGW_DIRECTX
> + bool
> + prompt "Include DirectX development files"
> +
> +config MINGW_DDK
> + bool
> + prompt "Include DDK development files"
> +
As said above, these options should go in mingw64.in.
[--SNIP--]
> diff -r 946d6d133a90 -r a34dced6ae17 samples/x86_64-w64-mingw32/crosstool.config
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/samples/x86_64-w64-mingw32/crosstool.config Tue Oct 23 20:14:08 2012 +0200
> @@ -0,0 +1,18 @@
Using a defconfig. Good! :-)
[--SNIP--]
> diff -r 946d6d133a90 -r a34dced6ae17 scripts/build/kernel/mingw64.sh
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/scripts/build/kernel/mingw64.sh Tue Oct 23 20:14:08 2012 +0200
> @@ -0,0 +1,83 @@
> +# This file declares functions to install the kernel headers for mingw64
> +# Copyright 2012 Yann Diorcet
> +# Licensed under the GPL v2. See COPYING in the root of this package
> +
> +CT_DoKernelTupleValues() {
> + CT_TARGET_KERNEL="mingw32"
mingw_32_, really?
[--SNIP--]
> +do_kernel_headers() {
You need to declare variables you use in this function as being local to
the function:
local sdk_opts
local -a mingw_opts
> + CT_DoStep INFO "Installing kernel headers"
> +
> + mkdir -p "${CT_HEADERS_DIR}"
> +# cp -r ${CT_SRC_DIR}/mingw-w64-v${CT_W64API_VERSION}/include/* \
> +# ${CT_HEADERS_DIR}
Code commented means it is not used. Remove it.
> + if [ -n "${CT_MINGW_DIRECTX}" ]; then
Do not expect that a non-empty string is equal to 'y'.
I prefer that we really check against 'y':
if [ "${foo}" = "y" ]; then
printf "foo is set to 'y'\n"
fi
or against 'n':
if [ -z "${foo}" ]; then
printf "foo is not set (aka 'n')\n"
fi
> + sdk_opt="directx"
> + if [ -n "${CT_MINGW_DDK}" ]; then
> + sdk_opt="all"
> + fi
> + else
> + if [ -n "${CT_MINGW_DDK}" ]; then
> + sdk_opt="ddk"
> + else
> + sdk_opt="none"
> + fi
> + fi
Although your construct is corect, we usually use another one when there
are two (or three) bollean variables:
case "${CT_MINGW_DIRECTX}:${CT_MINGW_DDK}" in
y:y) sdk_opt="all";;
y:) sdk_opt="directx";;
:y) sdk_opt="ddk";;
:) sdk_opt="none";;
esac
Much more compact, as easy to read. ;-)
> + CT_mkdir_pushd "${CT_BUILD_DIR}/build-header-build-${CT_BUILD}"
> + gmp_opts+=( "host=${CT_TARGET}" )
> + gmp_opts+=( "prefix=${CT_SYSROOT_DIR}" )
> + gmp_opts+=( "sdk=${sdk_opt}" )
You're in the mingw kernel, not in gmp:
s/gmp_opts/mingw_opts/
> + do_mingw64_headers_backend "${gmp_opts[@]}"
> +
> + CT_Popd
> +
> + CT_DoExecLog ALL cp -r ${CT_SYSROOT_DIR}/${CT_TARGET}/include/* \
> + ${CT_HEADERS_DIR}
Always quotes variables, especially those that are paths.
> + CT_EndStep
> +}
> +
> +# Build MINGW64 headers
> +# Parameter : description : type : default
> +# host : machine to run on : tuple : (none)
> +# prefix : prefix to install into : dir : (none)
> +# cflags : host cflags to use : string : (empty)
Last line shoule be something like:
sdk : sdk parts to build : string : (empty)
> +do_mingw64_headers_backend() {
Why do you need to use a backend here? In crosstool-NG, we use a backend
when the component needs to be built multiple times, not to abstract so
semantic.
There's no such need here.
> + local host
> + local prefix
> + local cflags
> + local arg
> + local sdk
> +
> + for arg in "$@"; do
> + eval "${arg// /\\ }"
> + done
> +
> + CT_DoLog EXTRA "Configuring Headers"
> +
> + CT_DoExecLog CFG \
> + "${CT_SRC_DIR}/mingw-w64-v${CT_W64API_VERSION}/mingw-w64-headers/configure" \
> + --build=${CT_BUILD} \
> + --host=${host} \
> + --prefix="${prefix}" \
> + --enable-sdk="${sdk}"
> +
> + CT_DoLog EXTRA "Compile Headers"
> + CT_DoExecLog ALL make
> +
> + CT_DoLog EXTRA "Installing Headers"
> + CT_DoExecLog ALL make install
> +}
> diff -r 946d6d133a90 -r a34dced6ae17 scripts/build/libc/mingw64.sh
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/scripts/build/libc/mingw64.sh Tue Oct 23 20:14:08 2012 +0200
> @@ -0,0 +1,52 @@
> +do_libc_get() {
Nit-picking: trailing white space.
> + CT_GetFile "mingw-w64-v${CT_W64API_VERSION}" \
> + http://downloads.sourceforge.net/sourceforge/mingw-w64
Ah, I see that the mingw64 kernel and C library are from the same source
archive. Yes, you have to CT_GetFile nad CT_Extract it in both places.
Good.
> +}
> +
> +do_libc_extract() {
> + CT_Extract "mingw-w64-v${CT_W64API_VERSION}"
> +}
> +
> +do_libc_check_config() {
> + :
> +}
> +
> +do_libc_start_files() {
> + CT_DoStep INFO "Installing C library headers"
> +
> + # It seems mingw is strangely set up to look into /mingw instead of
> + # /usr (notably when looking for the headers). This symlink is
> + # here to workaround this, and seems to be here to last... :-/
> + CT_DoExecLog ALL ln -sv "${CT_TARGET}" "${CT_SYSROOT_DIR}/mingw"
I do not like the way the sysroot is organised... :-/
I do not have enough bacgground in this 'kernel' to understand how
everything should fit together. :-(
Let's keep it that way for now...
> + CT_EndStep
> +}
> +
> +do_libc() {
> + CT_DoStep INFO "Building MinGW64 files"
> +
> + CT_DoLog EXTRA "Configuring W64-CRT"
> +
> + mkdir -p "${CT_BUILD_DIR}/build-w64crt"
> + cd "${CT_BUILD_DIR}/build-w64crt"
> +
> + CT_DoExecLog CFG \
> + "${CT_SRC_DIR}/mingw-w64-v${CT_W64API_VERSION}/mingw-w64-crt/configure" \
> + --prefix=${CT_SYSROOT_DIR} \
> + --host=${CT_TARGET}
> +
> + CT_DoLog EXTRA "Building W64-CRT"
> + CT_DoExecLog ALL make ${JOBSFLAGS}
> +
> + CT_DoLog EXTRA "Installing W64-CRT"
> + CT_DoExecLog ALL make install
> +
> + CT_EndStep
> +}
> +
> +do_libc_finish() {
> + CT_DoStep INFO "Installing MinGW64 Development libraries"
> +
> + CT_EndStep
> +}
If this function deos nothing, no need to print anything at all (like in
the do_libc_check_config step).
Regards,
Yann E. MORIN.
Le 23/10/2012 23:54, Yann E. MORIN a écrit : > Yann, All, > > Thanks for posting this again. > > Overall, the patch looks OK. It built fine on my machine. Yeah! :-) > > However, I have a few comments: I have difficulty to understand all the stuff in crosstool-ng ... i have only done a working patch (not a beautiful one). > 1- I'd like to see how hard it would be to commonalise the mingw{32,64} > variants together, eg. take advantage on CT_ARCH_64 to decide what > mingw variant to build. > This would avoid duplicating code path for mingw. Yes i tried, but the configuration stuff is still a mystery for me. I don't see how to do it without lost 10h. > 2- In your patch, the DirectX and DDK options are in the mingw64 C library > menu, but are used in the mingw64 kernel build script. That's wrong. > If the option is used in the kernel script, it shall be in the kernel > menu, not the C library menu. Indeed > 3- Also, this is incoherent with the 32-bit variant, for which the DirectX > option *is* in the C library menu. I'd like that the two variants have > a similar layout in the menu, so that it does not erquire a completely > schyzophrenic user to discover where the options are. ;-) > I see that for the 64-bit variant, the DirectX is provided by the kernel > headers, whereas it is provided by a separate package and build in the > libc_finish step for the 32-bit variant. If we have to change the 32-bit > variant so it more closely ressemble the 64-bit one, so be it. > That will help us commonalise the build scripts and the config files. > 4- Other comments in-lined in the patch, below. > > On Tuesday 23 October 2012 Yann Diorcet wrote: >> # HG changeset patch >> # User Yann Diorcet<diorcet.yann@gmail.com> >> # Date 1351016048 -7200 >> # Node ID a34dced6ae17acc54d132e91805208971e6ac7f4 >> # Parent 946d6d133a90935465e3582b54b60c0d7e4e6397 >> kernel/mingw64: add mingw64 kernel type >> script: add script for kernel and libc for mingw64 >> samples: add 64 bits Windows target sample >> Signed-off-by: Yann Diorcet<diorcet.yann@gmail.com> > As this is primarily adding a new 'kernel', I'd suggest that the commit > log be something like: > > kernel/mingw64: new kernel > > Add mingw64 as a new kernel for x86_64. > As a dependency, add the mingw64 C library. > > Add a sample to build a mingw64 toolchain. > > sob: you > > If we can commonalise the two mingw variants, then I'd like to see > a patch series, with pathes like: > [PATCH 1/2] kernel/mingw32: rename to mingw to preapare 64-bit variant > [PATCH 2/2] kernel/mingw: add 64-bit variant > > Use your imagination to complete the commit log. ;-) > > [--SNIP--] >> diff -r 946d6d133a90 -r a34dced6ae17 config/kernel/mingw64.in >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/config/kernel/mingw64.in Tue Oct 23 20:14:08 2012 +0200 >> @@ -0,0 +1,33 @@ > This file is *very* similar to the 32-bit variant, and would gain in being > folded together. i don't know how to use a same kernel.in with different kernel type using different scripts... > [--SNIP--] >> diff -r 946d6d133a90 -r a34dced6ae17 config/libc/mingw64.in >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/config/libc/mingw64.in Tue Oct 23 20:14:08 2012 +0200 >> @@ -0,0 +1,33 @@ > Ditto, very similar. > >> diff -r 946d6d133a90 -r a34dced6ae17 config/libc/mingw64.in.2 >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/config/libc/mingw64.in.2 Tue Oct 23 20:14:08 2012 +0200 >> @@ -0,0 +1,10 @@ >> +# Part-2 of mingw C library options: development libraries >> + >> +config MINGW_DIRECTX >> + bool >> + prompt "Include DirectX development files" >> + >> +config MINGW_DDK >> + bool >> + prompt "Include DDK development files" >> + > As said above, these options should go in mingw64.in. > > [--SNIP--] >> diff -r 946d6d133a90 -r a34dced6ae17 samples/x86_64-w64-mingw32/crosstool.config >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/samples/x86_64-w64-mingw32/crosstool.config Tue Oct 23 20:14:08 2012 +0200 >> @@ -0,0 +1,18 @@ > Using a defconfig. Good! :-) > > [--SNIP--] >> diff -r 946d6d133a90 -r a34dced6ae17 scripts/build/kernel/mingw64.sh >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/scripts/build/kernel/mingw64.sh Tue Oct 23 20:14:08 2012 +0200 >> @@ -0,0 +1,83 @@ >> +# This file declares functions to install the kernel headers for mingw64 >> +# Copyright 2012 Yann Diorcet >> +# Licensed under the GPL v2. See COPYING in the root of this package >> + >> +CT_DoKernelTupleValues() { >> + CT_TARGET_KERNEL="mingw32" > mingw_32_, really? Yes really .. i was surprise too..; see http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler all the configure use a target like this x86_64-w64-mingw32 > [--SNIP--] >> +do_kernel_headers() { > You need to declare variables you use in this function as being local to > the function: > local sdk_opts > local -a mingw_opts > >> + CT_DoStep INFO "Installing kernel headers" >> + >> + mkdir -p "${CT_HEADERS_DIR}" >> +# cp -r ${CT_SRC_DIR}/mingw-w64-v${CT_W64API_VERSION}/include/* \ >> +# ${CT_HEADERS_DIR} > Code commented means it is not used. Remove it. > >> + if [ -n "${CT_MINGW_DIRECTX}" ]; then > Do not expect that a non-empty string is equal to 'y'. > I prefer that we really check against 'y': > if [ "${foo}" = "y" ]; then > printf "foo is set to 'y'\n" > fi > > or against 'n': > if [ -z "${foo}" ]; then > printf "foo is not set (aka 'n')\n" > fi > >> + sdk_opt="directx" >> + if [ -n "${CT_MINGW_DDK}" ]; then >> + sdk_opt="all" >> + fi >> + else >> + if [ -n "${CT_MINGW_DDK}" ]; then >> + sdk_opt="ddk" >> + else >> + sdk_opt="none" >> + fi >> + fi > Although your construct is corect, we usually use another one when there > are two (or three) bollean variables: > > case "${CT_MINGW_DIRECTX}:${CT_MINGW_DDK}" in > y:y) sdk_opt="all";; > y:) sdk_opt="directx";; > :y) sdk_opt="ddk";; > :) sdk_opt="none";; > esac > > Much more compact, as easy to read. ;-) > >> + CT_mkdir_pushd "${CT_BUILD_DIR}/build-header-build-${CT_BUILD}" >> + gmp_opts+=( "host=${CT_TARGET}" ) >> + gmp_opts+=( "prefix=${CT_SYSROOT_DIR}" ) >> + gmp_opts+=( "sdk=${sdk_opt}" ) > You're in the mingw kernel, not in gmp: > s/gmp_opts/mingw_opts/ > >> + do_mingw64_headers_backend "${gmp_opts[@]}" >> + >> + CT_Popd >> + >> + CT_DoExecLog ALL cp -r ${CT_SYSROOT_DIR}/${CT_TARGET}/include/* \ >> + ${CT_HEADERS_DIR} > Always quotes variables, especially those that are paths. > >> + CT_EndStep >> +} >> + >> +# Build MINGW64 headers >> +# Parameter : description : type : default >> +# host : machine to run on : tuple : (none) >> +# prefix : prefix to install into : dir : (none) >> +# cflags : host cflags to use : string : (empty) > Last line shoule be something like: > sdk : sdk parts to build : string : (empty) > >> +do_mingw64_headers_backend() { > Why do you need to use a backend here? In crosstool-NG, we use a backend > when the component needs to be built multiple times, not to abstract so > semantic. > > There's no such need here. > >> + local host >> + local prefix >> + local cflags >> + local arg >> + local sdk >> + >> + for arg in "$@"; do >> + eval "${arg// /\\ }" >> + done >> + >> + CT_DoLog EXTRA "Configuring Headers" >> + >> + CT_DoExecLog CFG \ >> + "${CT_SRC_DIR}/mingw-w64-v${CT_W64API_VERSION}/mingw-w64-headers/configure" \ >> + --build=${CT_BUILD} \ >> + --host=${host} \ >> + --prefix="${prefix}" \ >> + --enable-sdk="${sdk}" >> + >> + CT_DoLog EXTRA "Compile Headers" >> + CT_DoExecLog ALL make >> + >> + CT_DoLog EXTRA "Installing Headers" >> + CT_DoExecLog ALL make install >> +} >> diff -r 946d6d133a90 -r a34dced6ae17 scripts/build/libc/mingw64.sh >> --- /dev/null Thu Jan 01 00:00:00 1970 +0000 >> +++ b/scripts/build/libc/mingw64.sh Tue Oct 23 20:14:08 2012 +0200 >> @@ -0,0 +1,52 @@ >> +do_libc_get() { > Nit-picking: trailing white space. > >> + CT_GetFile "mingw-w64-v${CT_W64API_VERSION}" \ >> +http://downloads.sourceforge.net/sourceforge/mingw-w64 > Ah, I see that the mingw64 kernel and C library are from the same source > archive. Yes, you have to CT_GetFile nad CT_Extract it in both places. > Good. > >> +} >> + >> +do_libc_extract() { >> + CT_Extract "mingw-w64-v${CT_W64API_VERSION}" >> +} >> + >> +do_libc_check_config() { >> + : >> +} >> + >> +do_libc_start_files() { >> + CT_DoStep INFO "Installing C library headers" >> + >> + # It seems mingw is strangely set up to look into /mingw instead of >> + # /usr (notably when looking for the headers). This symlink is >> + # here to workaround this, and seems to be here to last... :-/ >> + CT_DoExecLog ALL ln -sv "${CT_TARGET}" "${CT_SYSROOT_DIR}/mingw" > I do not like the way the sysroot is organised... :-/ > I do not have enough bacgground in this 'kernel' to understand how > everything should fit together. :-( look http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler it's quite simple... it correspond to the command "ln -s /mypath/x86_64-w64-mingw32 /mypath/mingw" > Let's keep it that way for now... > >> + CT_EndStep >> +} >> + >> +do_libc() { >> + CT_DoStep INFO "Building MinGW64 files" >> + >> + CT_DoLog EXTRA "Configuring W64-CRT" >> + >> + mkdir -p "${CT_BUILD_DIR}/build-w64crt" >> + cd "${CT_BUILD_DIR}/build-w64crt" >> + >> + CT_DoExecLog CFG \ >> + "${CT_SRC_DIR}/mingw-w64-v${CT_W64API_VERSION}/mingw-w64-crt/configure" \ >> + --prefix=${CT_SYSROOT_DIR} \ >> + --host=${CT_TARGET} >> + >> + CT_DoLog EXTRA "Building W64-CRT" >> + CT_DoExecLog ALL make ${JOBSFLAGS} >> + >> + CT_DoLog EXTRA "Installing W64-CRT" >> + CT_DoExecLog ALL make install >> + >> + CT_EndStep >> +} >> + >> +do_libc_finish() { >> + CT_DoStep INFO "Installing MinGW64 Development libraries" >> + >> + CT_EndStep >> +} > If this function deos nothing, no need to print anything at all (like in > the do_libc_check_config step). Sure ... :D > Regards, > Yann E. MORIN. > PS: is there a way to restart the build from a step (and how know steps)? Regards, Yann Diorcet -- For unsubscribe information see http://sourceware.org/lists.html#faq
Yann, All, On Wednesday 24 October 2012 Diorcet Yann wrote: > Le 23/10/2012 23:54, Yann E. MORIN a écrit : > > However, I have a few comments: > I have difficulty to understand all the stuff in crosstool-ng ... i have > only done a working patch (not a beautiful one). No problem, let's work together to get this in! :-) > > 1- I'd like to see how hard it would be to commonalise the mingw{32,64} > > variants together, eg. take advantage on CT_ARCH_64 to decide what > > mingw variant to build. > > This would avoid duplicating code path for mingw. > Yes i tried, but the configuration stuff is still a mystery for me. I > don't see how to do it without lost 10h. A very simple way: First, in config/kernel/mingw.in, we could have something like: ---8<--- # mingw32 config options ## depends on EXPERIMENTAL && ARCH_x86 ## ## select MINGW # Need to rename MINGW32 in kernel.in ## ## help Build a toolchain targeting systems running Windows as host choice bool prompt "API version" # Don't remove next line # CT_INSERT_VERSION_BELOW config WAPI_V_3_14 bool depends on ARCH_32 prompt "3.14" config WAPI_V_2_0_7 bool depends on ARCH_64 prompt "2.0.7" config WAPI_V_select bool prompt "Other version" endchoice config WAPI_VERSION string prompt "API version" if WAPI_V_select # Don't remove next line # CT_INSERT_VERSION_STRING_BELOW default "3.14" if WAPI_V_3_14 default "2.0.7" if WAPI_V_2_0_7 help Enter the version number of the windows api files to use ---8<--- Then, in scripts/build/kernel/mingw.sh: ---8<--- CT_DoKernelTupleValues() { CT_TARGET_KERNEL="mingw32" CT_TARGET_SYS= } do_kernel_ressources() { # tarball, uri and src are variables declared by our caller case "${CT_ARCH_BITNESS}" in 32) tarball="w32api-${CT_W32API_VERSION}-mingw32-src" url="http://downloads.sourceforge.net/sourceforge/mingw" src="${CT_SRC_DIR}/w32api-${CT_W32API_VERSION}-mingw32-src" ;; 64) tarball= "mingw-w64-v${CT_W64API_VERSION}" url="http://downloads.sourceforge.net/sourceforge/mingw-w64" src=""${CT_SRC_DIR}/mingw-w64-v${CT_W64API_VERSION}/mingw-w64-headers" ;; esac } do_kernel_get() { local tarball url src do_kernel_ressources CT_GetFile "${tarball}" "${url}" } do_kernel_extract() { local tarball url src do_kernel_ressources CT_Extract "${tarball}" } # The two kernel are too different to share a single code path, # so we have a backend for each bitness variant. # Not-so-clean, but not-so-dirty either... :-/ do_kernel() { do_kernel_${CT_ARCH_BITNESS}_backend } do_kernel_32_backend() { local tarball url src do_kernel_ressources "${src}/configure" --blabla... # You get the idea... ;-) } do_kernel_64_backend() { local tarball url src do_kernel_ressources "${src}/configure" --blabla... # You get the idea... ;-) } ---8<--- And a similar thing for the C library part. If at all possible, avoid using the _backend mechanism, if it is possible to have the same code-path, with only some locally-constrained conditionals on the bitness. [--SNIP--] > >> +CT_DoKernelTupleValues() { > >> + CT_TARGET_KERNEL="mingw32" > > mingw_32_, really? > Yes really .. i was surprise too..; > see > http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler > all the configure use a target like this x86_64-w64-mingw32 Nice pointer. You should add it to the help text in kernel/mingw.in to serve as a reference. [--SNIP--] > >> +do_libc_start_files() { > >> + CT_DoStep INFO "Installing C library headers" > >> + > >> + # It seems mingw is strangely set up to look into /mingw instead of > >> + # /usr (notably when looking for the headers). This symlink is > >> + # here to workaround this, and seems to be here to last... :-/ > >> + CT_DoExecLog ALL ln -sv "${CT_TARGET}" "${CT_SYSROOT_DIR}/mingw" > > I do not like the way the sysroot is organised... :-/ > > I do not have enough bacgground in this 'kernel' to understand how > > everything should fit together. :-( > look > http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler > > it's quite simple... it correspond to the command "ln -s > /mypath/x86_64-w64-mingw32 /mypath/mingw" Yep, let's keep it that way. > PS: is there a way to restart the build from a step (and how know steps)? Yes: $ ct-ng menuconfig Paths and misc options ---> [*] Debug crosstool-NG [*] Save intermediate steps [*] gzip saved states (save and exit) $ ct-ng build (wait for it to finish or break) $ ct-ng step_name (restart only that step) $ ct-ng +step_name (restart from zero, stop before this step) $ ct-ng sten_name+ (restart from that step, to the end) $ ct-ng list-steps (see list of steps) $ ct-ng help (see help ;-) ) Regards, Yann E. MORIN.
Le 24/10/12 00:59, Yann E. MORIN a écrit : > Yann, All, > > On Wednesday 24 October 2012 Diorcet Yann wrote: >> Le 23/10/2012 23:54, Yann E. MORIN a écrit : >>> However, I have a few comments: >> I have difficulty to understand all the stuff in crosstool-ng ... i have >> only done a working patch (not a beautiful one). > No problem, let's work together to get this in! :-) > >>> 1- I'd like to see how hard it would be to commonalise the mingw{32,64} >>> variants together, eg. take advantage on CT_ARCH_64 to decide what >>> mingw variant to build. >>> This would avoid duplicating code path for mingw. >> Yes i tried, but the configuration stuff is still a mystery for me. I >> don't see how to do it without lost 10h. > A very simple way: > > First, in config/kernel/mingw.in, we could have something like: > > ---8<--- > # mingw32 config options > > ## depends on EXPERIMENTAL && ARCH_x86 > ## > ## select MINGW # Need to rename MINGW32 in kernel.in > ## > ## help Build a toolchain targeting systems running Windows as host > > choice > bool > prompt "API version" > > # Don't remove next line > # CT_INSERT_VERSION_BELOW > config WAPI_V_3_14 > bool > depends on ARCH_32 > prompt "3.14" > > config WAPI_V_2_0_7 > bool > depends on ARCH_64 > prompt "2.0.7" > > config WAPI_V_select > bool > prompt "Other version" > > endchoice > > config WAPI_VERSION > string > prompt "API version" if WAPI_V_select > # Don't remove next line > # CT_INSERT_VERSION_STRING_BELOW > default "3.14" if WAPI_V_3_14 > default "2.0.7" if WAPI_V_2_0_7 > help > Enter the version number of the windows api files to use > ---8<--- it seems nice indeed > > Then, in scripts/build/kernel/mingw.sh: > > ---8<--- > CT_DoKernelTupleValues() { > CT_TARGET_KERNEL="mingw32" > CT_TARGET_SYS= > } > > do_kernel_ressources() { > # tarball, uri and src are variables declared by our caller > case "${CT_ARCH_BITNESS}" in > 32) tarball="w32api-${CT_W32API_VERSION}-mingw32-src" > url="http://downloads.sourceforge.net/sourceforge/mingw" > src="${CT_SRC_DIR}/w32api-${CT_W32API_VERSION}-mingw32-src" > ;; > 64) tarball= "mingw-w64-v${CT_W64API_VERSION}" > url="http://downloads.sourceforge.net/sourceforge/mingw-w64" > src=""${CT_SRC_DIR}/mingw-w64-v${CT_W64API_VERSION}/mingw-w64-headers" > ;; > esac > } > > do_kernel_get() { > local tarball url src > do_kernel_ressources > CT_GetFile "${tarball}" "${url}" > } > > do_kernel_extract() { > local tarball url src > do_kernel_ressources > CT_Extract "${tarball}" > } > > # The two kernel are too different to share a single code path, > # so we have a backend for each bitness variant. > # Not-so-clean, but not-so-dirty either... :-/ > do_kernel() { > do_kernel_${CT_ARCH_BITNESS}_backend > } > > do_kernel_32_backend() { > local tarball url src > do_kernel_ressources > "${src}/configure" --blabla... > # You get the idea... ;-) > } > > do_kernel_64_backend() { > local tarball url src > do_kernel_ressources > "${src}/configure" --blabla... > # You get the idea... ;-) > } > ---8<--- Hum the 2 bitness process are very different. There is no way to make merge configuration stuff and keep split scripts? It avoid to have a big file with two things very different. > And a similar thing for the C library part. > > If at all possible, avoid using the _backend mechanism, if it is possible to > have the same code-path, with only some locally-constrained conditionals on > the bitness. > > [--SNIP--] >>>> +CT_DoKernelTupleValues() { >>>> + CT_TARGET_KERNEL="mingw32" >>> mingw_32_, really? >> Yes really .. i was surprise too..; >> see >> http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler >> all the configure use a target like this x86_64-w64-mingw32 > Nice pointer. You should add it to the help text in kernel/mingw.in > to serve as a reference. Ok > > [--SNIP--] >>>> +do_libc_start_files() { >>>> + CT_DoStep INFO "Installing C library headers" >>>> + >>>> + # It seems mingw is strangely set up to look into /mingw instead of >>>> + # /usr (notably when looking for the headers). This symlink is >>>> + # here to workaround this, and seems to be here to last... :-/ >>>> + CT_DoExecLog ALL ln -sv "${CT_TARGET}" "${CT_SYSROOT_DIR}/mingw" >>> I do not like the way the sysroot is organised... :-/ >>> I do not have enough bacgground in this 'kernel' to understand how >>> everything should fit together. :-( >> look >> http://sourceforge.net/apps/trac/mingw-w64/wiki/Cross%20Win32%20and%20Win64%20compiler >> >> it's quite simple... it correspond to the command "ln -s >> /mypath/x86_64-w64-mingw32 /mypath/mingw" > Yep, let's keep it that way. > >> PS: is there a way to restart the build from a step (and how know steps)? > Yes: > $ ct-ng menuconfig > Paths and misc options ---> > [*] Debug crosstool-NG > [*] Save intermediate steps > [*] gzip saved states > (save and exit) > $ ct-ng build (wait for it to finish or break) > $ ct-ng step_name (restart only that step) > $ ct-ng +step_name (restart from zero, stop before this step) > $ ct-ng sten_name+ (restart from that step, to the end) > $ ct-ng list-steps (see list of steps) > $ ct-ng help (see help ;-) ) Thanks > Regards, > Yann E. MORIN. > -- For unsubscribe information see http://sourceware.org/lists.html#faq
Yann, All, On Wednesday 24 October 2012 Diorcet Yann wrote: > Le 24/10/12 00:59, Yann E. MORIN a écrit : > > Then, in scripts/build/kernel/mingw.sh: [--SNIP--] > Hum the 2 bitness process are very different. There is no way to make > merge configuration stuff and keep split scripts? There's no provision for that in crosstool-NG. However, it is possible with a bit of a hack. First, you'd need three files: scripts/build/kernel/mingw.sh scripts/build/kernel/mingw32.sh scripts/build/kernel/mingw64.sh Then, in mingw.sh, you'd simply have this one line: . "${CT_LIB_DIR}/scripts/build/kernel/mingw${CT_ARCH_BITNESS}.sh" And have the current code for each of mingw(32|64) in mingw\1.sh. > It avoid to have a big file with two things very different. That's not wrong, you get a point. However, I still would prefer that situation, where we have one big file with two almost completely different code-paths, rather than two different files. We've been down that road in the past with glibc and eglibc, with two completely different implementations, and it proved to be quite complex to merge back later on. I hope that it is inevitable that mingw32 and mingw64 end up being merged upstream, and I do not want we suffer again when that happens. And with the code-path I suggested for mingw.sh, we still get a clear separation between ming32 and mingw64, which is not too different from having two scripts. Anyway, if you decide not to do that yourself, that's fine. Provided the other points are addressed, I'll eventually merge your patchset as you'll provide it. Then, and although I can't promise anything, I'll eventually get to the point where I'll merge the two anyway. Do not get me wrong. I highly value your contribution (as I do for all others'). That's just that, as the maintainer, I want/need to lower the maintenance burden as much as I can, especially for features I do not use myself, to avoid the risk of eventually getting drowned (which is already starting to be somewhat an issue). Regards, Yann E. MORIN.
Le 24/10/2012 19:30, Yann E. MORIN a écrit : > Yann, All, > > On Wednesday 24 October 2012 Diorcet Yann wrote: >> Le 24/10/12 00:59, Yann E. MORIN a écrit : >>> Then, in scripts/build/kernel/mingw.sh: > [--SNIP--] >> Hum the 2 bitness process are very different. There is no way to make >> merge configuration stuff and keep split scripts? > There's no provision for that in crosstool-NG. However, it is possible > with a bit of a hack. First, you'd need three files: > scripts/build/kernel/mingw.sh > scripts/build/kernel/mingw32.sh > scripts/build/kernel/mingw64.sh > > Then, in mingw.sh, you'd simply have this one line: > . "${CT_LIB_DIR}/scripts/build/kernel/mingw${CT_ARCH_BITNESS}.sh" > > And have the current code for each of mingw(32|64) in mingw\1.sh. > >> It avoid to have a big file with two things very different. > That's not wrong, you get a point. > > However, I still would prefer that situation, where we have one big file > with two almost completely different code-paths, rather than two different > files. > > We've been down that road in the past with glibc and eglibc, with two > completely different implementations, and it proved to be quite complex > to merge back later on. > > I hope that it is inevitable that mingw32 and mingw64 end up being merged > upstream, and I do not want we suffer again when that happens. > > And with the code-path I suggested for mingw.sh, we still get a clear > separation between ming32 and mingw64, which is not too different from > having two scripts. > > Anyway, if you decide not to do that yourself, that's fine. Provided the > other points are addressed, I'll eventually merge your patchset as you'll > provide it. Then, and although I can't promise anything, I'll eventually > get to the point where I'll merge the two anyway. > > Do not get me wrong. I highly value your contribution (as I do for all > others'). That's just that, as the maintainer, I want/need to lower the > maintenance burden as much as I can, especially for features I do not use > myself, to avoid the risk of eventually getting drowned (which is already > starting to be somewhat an issue). And why not simply make mingw-w64 generates gcc for 32bits (i686-w64-mingw32 target) ? (remove old mingw32 stuff?) > Regards, > Yann E. MORIN. > -- For unsubscribe information see http://sourceware.org/lists.html#faq
Yann, All, On Wednesday 24 October 2012 Diorcet Yann wrote: > And why not simply make mingw-w64 generates gcc for 32bits > (i686-w64-mingw32 target) ? (remove old mingw32 stuff?) Ah! If that is possible, then definitely yes! :-) We'd have a single mingw that can target both mingw32 and mingw64. I like that! :-) Regards, Yann E. MORIN.
"Yann E. MORIN" <yann.morin.1998@free.fr> writes: > Yann, All, > > On Wednesday 24 October 2012 Diorcet Yann wrote: >> And why not simply make mingw-w64 generates gcc for 32bits >> (i686-w64-mingw32 target) ? (remove old mingw32 stuff?) > > Ah! If that is possible, then definitely yes! :-) > > We'd have a single mingw that can target both mingw32 and mingw64. > I like that! :-) +1, given enough testing of the mingw-w64 built mingw32 32-bit toolchains. Luckily Yann (Diorcet) is using OE-lite, so I feel confident that he will help give it some mileage in OE-lite also :-) /Esben -- For unsubscribe information see http://sourceware.org/lists.html#faq
diff -r 946d6d133a90 -r a34dced6ae17 config/kernel.in --- a/config/kernel.in Mon Oct 22 22:40:01 2012 +0200 +++ b/config/kernel.in Tue Oct 23 20:14:08 2012 +0200 @@ -10,6 +10,9 @@ config MINGW32 bool +config MINGW64 + bool + # Each target OS (aka kernel) that support shared libraries can select # this, so the user can decide whether or not to build a shared library # enabled toolchain diff -r 946d6d133a90 -r a34dced6ae17 config/kernel/mingw64.in --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/config/kernel/mingw64.in Tue Oct 23 20:14:08 2012 +0200 @@ -0,0 +1,33 @@ +# mingw64 config options + +## depends on EXPERIMENTAL && ( ARCH_x86 && ARCH_64 ) +## +## select MINGW64 +## +## help Build a toolchain targeting systems running Windows as host + +choice + bool + prompt "Windows api version" + +# Don't remove next line +# CT_INSERT_VERSION_BELOW +config W64API_V_2_0_7 + bool + prompt "2.0.7" + +config W64API_V_select + bool + prompt "Other version" + +endchoice + +config W64API_VERSION + string + prompt "W64 api version" if W64API_V_select +# Don't remove next line +# CT_INSERT_VERSION_STRING_BELOW + default "2.0.7" if W64API_V_2_0_7 + help + Enter the version number of the windows api files to use + diff -r 946d6d133a90 -r a34dced6ae17 config/libc/eglibc.in --- a/config/libc/eglibc.in Mon Oct 22 22:40:01 2012 +0200 +++ b/config/libc/eglibc.in Tue Oct 23 20:14:08 2012 +0200 @@ -1,6 +1,6 @@ # eglibc options -## depends on ! MINGW32 && ! BARE_METAL && ARCH_USE_MMU +## depends on ! MINGW32 && ! MINGW64 && ! BARE_METAL && ARCH_USE_MMU ## ## select LIBC_SUPPORT_NPTL ## select LIBC_SUPPORT_LINUXTHREADS diff -r 946d6d133a90 -r a34dced6ae17 config/libc/glibc.in --- a/config/libc/glibc.in Mon Oct 22 22:40:01 2012 +0200 +++ b/config/libc/glibc.in Tue Oct 23 20:14:08 2012 +0200 @@ -1,6 +1,6 @@ # glibc options -## depends on ! MINGW32 && ! BARE_METAL && ARCH_USE_MMU +## depends on ! MINGW32 && ! MINGW64 && ! BARE_METAL && ARCH_USE_MMU ## ## select LIBC_SUPPORT_NPTL ## diff -r 946d6d133a90 -r a34dced6ae17 config/libc/mingw64.in --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/config/libc/mingw64.in Tue Oct 23 20:14:08 2012 +0200 @@ -0,0 +1,33 @@ +# mingw64 options + +## depends on MINGW64 +## +## select LIBC_SUPPORT_WIN32THREADS +## +## help The de-facto standard for Mingw distributions. + +choice + bool + prompt "Mingw64 runtime version" + +# Don't remove next line +# CT_INSERT_VERSION_BELOW +config MINGW64RT_V_3_18 + bool + prompt "3.18" + +config MINGW64RT_V_select + bool + prompt "Other version" + +endchoice + +config MINGW64RT_VERSION + string + prompt "Mingw64 runtime version" if MINGW64RT_V_select +# Don't remove next line +# CT_INSERT_VERSION_STRING_BELOW + default "3.18" if MINGW64RT_V_3_18 + help + Enter the version number of the mingw64 runtime files to use + diff -r 946d6d133a90 -r a34dced6ae17 config/libc/mingw64.in.2 --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/config/libc/mingw64.in.2 Tue Oct 23 20:14:08 2012 +0200 @@ -0,0 +1,10 @@ +# Part-2 of mingw C library options: development libraries + +config MINGW_DIRECTX + bool + prompt "Include DirectX development files" + +config MINGW_DDK + bool + prompt "Include DDK development files" + diff -r 946d6d133a90 -r a34dced6ae17 config/libc/uClibc.in --- a/config/libc/uClibc.in Mon Oct 22 22:40:01 2012 +0200 +++ b/config/libc/uClibc.in Tue Oct 23 20:14:08 2012 +0200 @@ -1,6 +1,6 @@ # uClibc options -## depends on ! MINGW32 && ! BARE_METAL +## depends on ! MINGW32 && ! MINGW64 && ! BARE_METAL ## ## select LIBC_SUPPORT_LINUXTHREADS ## select LIBC_SUPPORT_THREADS_NONE diff -r 946d6d133a90 -r a34dced6ae17 samples/x86_64-w64-mingw32/crosstool.config --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/samples/x86_64-w64-mingw32/crosstool.config Tue Oct 23 20:14:08 2012 +0200 @@ -0,0 +1,18 @@ +CT_EXPERIMENTAL=y +CT_LOCAL_TARBALLS_DIR="${HOME}/src" +CT_SAVE_TARBALLS=y +CT_LOG_EXTRA=y +CT_ARCH_64=y +CT_ARCH_x86=y +CT_TARGET_VENDOR="w64" +CT_KERNEL_mingw64=y +CT_BINUTILS_V_2_21_1a=y +CT_BINUTILS_PLUGINS=y +CT_CC_V_4_5_1=y +CT_CC_LANG_CXX=y +CT_MINGW_DIRECTX=y +CT_MINGW_DDK=y +CT_GMP_V_4_3_2=y +CT_MPFR_V_2_4_2=y +CT_PPL_V_0_10_2=y +CT_CLOOG_V_0_15_10=y diff -r 946d6d133a90 -r a34dced6ae17 samples/x86_64-w64-mingw32/reported.by --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/samples/x86_64-w64-mingw32/reported.by Tue Oct 23 20:14:08 2012 +0200 @@ -0,0 +1,3 @@ +reporter_name="Yann Diorcet <diorcet.yann@gmail.com>" +reporter_url="" +reporter_comment="Config to build cross-compiler with mingw-w64 as kernel type" diff -r 946d6d133a90 -r a34dced6ae17 scripts/build/kernel/mingw64.sh --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/scripts/build/kernel/mingw64.sh Tue Oct 23 20:14:08 2012 +0200 @@ -0,0 +1,83 @@ +# This file declares functions to install the kernel headers for mingw64 +# Copyright 2012 Yann Diorcet +# Licensed under the GPL v2. See COPYING in the root of this package + +CT_DoKernelTupleValues() { + CT_TARGET_KERNEL="mingw32" + CT_TARGET_SYS= +} + +do_kernel_get() { + CT_GetFile "mingw-w64-v${CT_W64API_VERSION}" \ + http://downloads.sourceforge.net/sourceforge/mingw-w64 +} + +do_kernel_extract() { + CT_Extract "mingw-w64-v${CT_W64API_VERSION}" +} + +do_kernel_headers() { + CT_DoStep INFO "Installing kernel headers" + + mkdir -p "${CT_HEADERS_DIR}" +# cp -r ${CT_SRC_DIR}/mingw-w64-v${CT_W64API_VERSION}/include/* \ +# ${CT_HEADERS_DIR} + + if [ -n "${CT_MINGW_DIRECTX}" ]; then + sdk_opt="directx" + if [ -n "${CT_MINGW_DDK}" ]; then + sdk_opt="all" + fi + else + if [ -n "${CT_MINGW_DDK}" ]; then + sdk_opt="ddk" + else + sdk_opt="none" + fi + fi + + CT_mkdir_pushd "${CT_BUILD_DIR}/build-header-build-${CT_BUILD}" + gmp_opts+=( "host=${CT_TARGET}" ) + gmp_opts+=( "prefix=${CT_SYSROOT_DIR}" ) + gmp_opts+=( "sdk=${sdk_opt}" ) + do_mingw64_headers_backend "${gmp_opts[@]}" + + CT_Popd + + CT_DoExecLog ALL cp -r ${CT_SYSROOT_DIR}/${CT_TARGET}/include/* \ + ${CT_HEADERS_DIR} + + CT_EndStep +} + +# Build MINGW64 headers +# Parameter : description : type : default +# host : machine to run on : tuple : (none) +# prefix : prefix to install into : dir : (none) +# cflags : host cflags to use : string : (empty) +do_mingw64_headers_backend() { + local host + local prefix + local cflags + local arg + local sdk + + for arg in "$@"; do + eval "${arg// /\\ }" + done + + CT_DoLog EXTRA "Configuring Headers" + + CT_DoExecLog CFG \ + "${CT_SRC_DIR}/mingw-w64-v${CT_W64API_VERSION}/mingw-w64-headers/configure" \ + --build=${CT_BUILD} \ + --host=${host} \ + --prefix="${prefix}" \ + --enable-sdk="${sdk}" + + CT_DoLog EXTRA "Compile Headers" + CT_DoExecLog ALL make + + CT_DoLog EXTRA "Installing Headers" + CT_DoExecLog ALL make install +} diff -r 946d6d133a90 -r a34dced6ae17 scripts/build/libc/mingw64.sh --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/scripts/build/libc/mingw64.sh Tue Oct 23 20:14:08 2012 +0200 @@ -0,0 +1,52 @@ +do_libc_get() { + CT_GetFile "mingw-w64-v${CT_W64API_VERSION}" \ + http://downloads.sourceforge.net/sourceforge/mingw-w64 +} + +do_libc_extract() { + CT_Extract "mingw-w64-v${CT_W64API_VERSION}" +} + +do_libc_check_config() { + : +} + +do_libc_start_files() { + CT_DoStep INFO "Installing C library headers" + + # It seems mingw is strangely set up to look into /mingw instead of + # /usr (notably when looking for the headers). This symlink is + # here to workaround this, and seems to be here to last... :-/ + CT_DoExecLog ALL ln -sv "${CT_TARGET}" "${CT_SYSROOT_DIR}/mingw" + + CT_EndStep +} + +do_libc() { + CT_DoStep INFO "Building MinGW64 files" + + CT_DoLog EXTRA "Configuring W64-CRT" + + mkdir -p "${CT_BUILD_DIR}/build-w64crt" + cd "${CT_BUILD_DIR}/build-w64crt" + + CT_DoExecLog CFG \ + "${CT_SRC_DIR}/mingw-w64-v${CT_W64API_VERSION}/mingw-w64-crt/configure" \ + --prefix=${CT_SYSROOT_DIR} \ + --host=${CT_TARGET} + + CT_DoLog EXTRA "Building W64-CRT" + CT_DoExecLog ALL make ${JOBSFLAGS} + + CT_DoLog EXTRA "Installing W64-CRT" + CT_DoExecLog ALL make install + + CT_EndStep +} + +do_libc_finish() { + CT_DoStep INFO "Installing MinGW64 Development libraries" + + CT_EndStep +} +
# HG changeset patch # User Yann Diorcet <diorcet.yann@gmail.com> # Date 1351016048 -7200 # Node ID a34dced6ae17acc54d132e91805208971e6ac7f4 # Parent 946d6d133a90935465e3582b54b60c0d7e4e6397 kernel/mingw64: add mingw64 kernel type script: add script for kernel and libc for mingw64 samples: add 64 bits Windows target sample Signed-off-by: Yann Diorcet <diorcet.yann@gmail.com> -- For unsubscribe information see http://sourceware.org/lists.html#faq