This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.
See crosstool-NG for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
Yann, All,it seems nice indeed
On Wednesday 24 October 2012 Diorcet Yann wrote:Le 23/10/2012 23:54, Yann E. MORIN a écrit :No problem, let's work together to get this in! :-)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).
A very simple way: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.
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<---
Hum the 2 bitness process are very different. There is no way to make merge configuration stuff and keep split scripts?
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.Ok
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--]mingw_32_, really?+CT_DoKernelTupleValues() { + CT_TARGET_KERNEL="mingw32"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-mingw32Nice pointer. You should add it to the help text in kernel/mingw.in to serve as a reference.
Thanks
[--SNIP--]Yep, let's keep it that way.+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"
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.
-- For unsubscribe information see http://sourceware.org/lists.html#faq
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |