While updating my cross toolchain for x86_64-w64-mingw32, I'm getting the following error # crossdev -oS /opt/cross/portage -t x86_64-w64-mingw32 -P --quiet-build=n * Restoring user setting 'USE' to '-hardened -multitarget -gd' -------------------------------------------------- * crossdev version: 20130628 * Host Portage ARCH: amd64 * Target Portage ARCH: amd64 * Target System: x86_64-w64-mingw32 * Stage: 4 (C/C++ compiler) * ABIs: amd64 * binutils: binutils-[latest] * gcc: gcc-[latest] * libc: mingw64-runtime-[latest] * CROSSDEV_OVERLAY: /opt/cross/portage * PORT_LOGDIR: /usr/x86_64-w64-mingw32/var/log/portage * PORTAGE_CONFIGROOT: * Portage flags: --quiet-build=n -N _ - ~ - _ - ~ - _ - ~ - _ - ~ - * leaving sys-devel/binutils in /opt/cross/portage * leaving sys-devel/gcc in /opt/cross/portage * leaving dev-util/mingw64-runtime in /opt/cross/portage * leaving sys-devel/gdb in /opt/cross/portage _ - ~ - _ - ~ - _ - ~ - _ - ~ - * Log: /usr/x86_64-w64-mingw32/var/log/portage/cross-x86_64-w64-mingw32-binutils.log * Emerging cross-binutils ... [ ok * Log: /usr/x86_64-w64-mingw32/var/log/portage/cross-x86_64-w64-mingw32-mingw64-runtime-headers.log * Emerging cross-mingw64-runtime-headers ... [ ok * Log: /usr/x86_64-w64-mingw32/var/log/portage/cross-x86_64-w64-mingw32-gcc-stage1.log * Emerging cross-gcc-stage1 ... [ ok * Log: /usr/x86_64-w64-mingw32/var/log/portage/cross-x86_64-w64-mingw32-mingw64-runtime.log * Emerging cross-mingw64-runtime ... * mingw64-runtime failed :( * If you file a bug, please attach the following logfiles: * /usr/x86_64-w64-mingw32/var/log/portage/cross-x86_64-w64-mingw32-info.log * /usr/x86_64-w64-mingw32/var/log/portage/cross-x86_64-w64-mingw32-mingw64-runtime.log.xz * /var/tmp/portage/cross-x86_64-w64-mingw32/mingw64-runtime*/temp/mingw64-runtime-config.logs.tar.xz Attached cross-x86_64-w64-mingw32-mingw64-runtime.log, config.log and gendef/config.log Reproducible: Always
Created attachment 360148 [details] cross-x86_64-w64-mingw32-mingw64-runtime.log
Created attachment 360150 [details] config.log
Created attachment 360152 [details] gendef/config.log
Notice that I get the same error using #1 Update crossdev -oS /opt/cross/portage -t x86_64-w64-mingw32 -P --quiet-build=n #2 Remove then install crossdev -C x86_64-w64-mingw32 crossdev -oS /opt/cross/portage -t x86_64-w64-mingw32 -P --quiet-build=n Same for i686-w64-mingw32
Created attachment 360154 [details] cross-x86_64-w64-mingw32-info.log
Yes, this is my bad. The tools USE flag was added by me, it cannot work when crt is first compiled, as there is no complete toolchain to compile it. The sequence should be: 1. binutils 2. headers 3. gcc-stage1 4. crt 5. gcc-stage2 6. crt tools vapier, is this sequence looks generic enough? maybe a phase can be added to crossdev, similar to crosscompile_opts_headers-only to have crosscompile_opts_crt-only and have another merge of crt after gcc-stage2? it can be detected if the crosscompile_opts_lib-only USE exists for package. Or, I can remove the tools USE for now in favour of mingw64-runtime-tools. Thanks!
crossdev has additional phases, but i'm not keen on adding things like this right now. maybe if there are more demands in the future. imo, the mingw package should handle the case itself. we can add a parallel to USE=crosscompile_opts_headers-only so C lib packages can detect the scenario. then the ebuild would ignore USE=tools in the first pass, and then once it has things compiled locally, run with USE=tools and use the local crt/libs. it should be doing this anyways ... if you upgrade from mingw64-runtime-2, it shouldn't be building the tools against the installed C lib rather than the local copy. after all, it'd mean you couldn't update the tools to use newer features available in the latest version ...
(In reply to SpanKY from comment #7) > imo, the mingw package should handle the case itself. we can add a parallel > to USE=crosscompile_opts_headers-only so C lib packages can detect the > scenario. then the ebuild would ignore USE=tools in the first pass, and > then once it has things compiled locally, run with USE=tools and use the > local crt/libs. I am not sure I follow... In the scenario of clean install, first time crossdev is used with the mingw target, it is now executes emerge mingw64-runtime two times, while we need to execute emerge mingw64-runtime 3 times to accomplish work, once more after gcc is fully functional (stage2). How can I resolve this without modifying crossdev or require user to run emerge post crossdev? I think the simplest solution is to have another ebuild for this, but user will have to manually create the symlinks within the portage overlay of crossdef.
Created attachment 360822 [details, diff] 0001-crossdev-support-libc-only-cross-compile-option.patch [PATCH] crossdev: support libc-only cross compile option There are cases in which libc supports extra tools and libraries that can be compiled only after full compiler is available, example is mingw64-runtime. This change adds libc-only cross compile option so that package can distinguish if it is at stage1 gcc or not. A simple emerge --update is executed after compiler is ready, if package supports the libc-only option it will be updated with its target settings. Signed-off-by: Alon Bar-Lev <alonbl@gentoo.org>
Created attachment 360824 [details, diff] mingw64-runtime-3.0.0.ebuild.diff mingw64-runtime support with attachment#360822 [details, diff]
Although attachment#360822 [details, diff], attachment#360824 [details, diff] are a solution, for now I disable the tools until someone actually request them and we figure out how to provide a solution, maybe there is no value to cross compile the tools anyway.
(In reply to Alon Bar-Lev from comment #8) forgot about the crossdev bootstrap case and focus on the other point i made. once that is fixed, the bootstrap case is automatically handled. for example: - i run `USE=-tools crossdev mingw64` - this will use mingw64-runtime-3.0.0 - everything works fine - i turn on USE=tools and re-emerge mingw64-runtime - mingw64-runtime-4.0.0 is released and i upgrade things, and USE=tools is still enabled in this scenario, what are the tools going to compile against ? the headers/libs/crt objects found in /usr/$CTARGET ? or the headers/libs/crt objects found in $WORKDIR ? based on the description here, they're going to use /usr/$CTARGET and that is wrong. they must be using $WORKDIR. otherwise, if the tools have been updated to rely on functionality that is only available in mingw64-runtime-4.0.0, building against older headers/libs is going to fail. if upstream themselves don't handle this cleanly, then the thing to do in the ebuild is: - always run first configure w/tools support disabled - do a second configure w/tools enabled (if USE=tools of course) - do the normal make in the first build dir - do the tools-only make in the second build dir and make sure they use the headers/objects in $WORKDIR
(In reply to SpanKY from comment #12) > (In reply to Alon Bar-Lev from comment #8) > > forgot about the crossdev bootstrap case and focus on the other point i > made. once that is fixed, the bootstrap case is automatically handled. > > for example: > - i run `USE=-tools crossdev mingw64` > - this will use mingw64-runtime-3.0.0 > - everything works fine > - i turn on USE=tools and re-emerge mingw64-runtime > - mingw64-runtime-4.0.0 is released and i upgrade things, and USE=tools is > still enabled > > in this scenario, what are the tools going to compile against ? the > headers/libs/crt objects found in /usr/$CTARGET ? or the headers/libs/crt > objects found in $WORKDIR ? I am confused, are you discussing the bug#486832 issue, in which the libc is compiled with pre-installed headers? > based on the description here, they're going to use /usr/$CTARGET and that > is wrong. they must be using $WORKDIR. otherwise, if the tools have been > updated to rely on functionality that is only available in > mingw64-runtime-4.0.0, building against older headers/libs is going to fail. > > if upstream themselves don't handle this cleanly, then the thing to do in > the ebuild is: > - always run first configure w/tools support disabled > - do a second configure w/tools enabled (if USE=tools of course) > - do the normal make in the first build dir > - do the tools-only make in the second build dir and make sure they use the > headers/objects in $WORKDIR I understand... but at clean bootstrap this will fail, is that acceptable? How will the it "once that is fixed, the bootstrap case is automatically handled" be fixed? For the tools I rather just to drop them for now, for the crt bug#486832, I will work on the ebuild to use two step build as you suggest, once I get proper response from upstream.
tool USE was removed for now.
