Trying to build cross-i686-mingw32 using following command: crossdev -C i686-mingw32; crossdev -t i686-mingw32 but it fails emerging cross-gcc-stage2
Created attachment 237375 [details] info.log
Created attachment 237377 [details] gcc-stage2.log
dont USE=openmp unless you provide for it
This is a bit hard to find in the build log due to parallelism, but it looks like the first hard error is: configure: error: Pthreads are required to build libgomp If so, then you need to --disable-libgomp, which would be achieved by setting USE=-openmp. A quick scan of the crossdev script suggests it should have done this for you, but we can see in the configure output that it did not: * USE: amd64 elibc_glibc fortran kernel_linux multilib nls nptl openmp userland_GNU * Configuring GCC with: * --enable-libgomp You can get a working cross compiler by changing the USE flag.
Actually I don't define USE=openmp by myself: # fgrep -c openmp /etc/portage/package.use /etc/make.conf /etc/portage/package.use:0 /etc/make.conf:0 so I think that it is a crossdev failure if it is used even if not working. I think it is read here (but I'm not sure): # fgrep -B2 openmp /usr/portage/profiles/default/linux/make.defaults # make sure toolchain has sane defaults <tooclhain@gentoo.org> USE="${USE} fortran mudflap openmp" Because of this, I reopen this bug. My profile: # eselect profile show Current make.profile symlink: default/linux/amd64/10.0/desktop/kde
It looks like crossdev version 20100620 no longer disables openmp, presumably because there are some cross environments where you can use it so somebody objected to it being forced off. I think those cases are relatively rare though, and it doesn't seem optimal to have crossdev fail mysteriously when attempting to build cross-tools with a standard profile. At least crossdev could show a message for USE=openmp, suggesting that you should turn it off unless you know what you're doing...
I've faced the same problem and it took me 1 hour to figure out what is going on. This bug is closed as INVALID, so what is the recommended fix (other than changing the global make.conf to disable openmp)? Thanks for any hint!
set -openmp via per-package use files if you dont want to support it under mingw
(In reply to comment #8) > set -openmp via per-package use files if you dont want to support it under > mingw I know about this (I'm using it already in /etc/portage/package.use), but how to do it for crossdev (mingw32) gcc package only?
(In reply to comment #9) > (In reply to comment #8) > > set -openmp via per-package use files if you dont want to support it under > > mingw > > I know about this (I'm using it already in /etc/portage/package.use), but how > to do it for crossdev (mingw32) gcc package only? For those seeking for help, the correct line in package.use is: cross-i686-pc-mingw32/gcc -openmp
(In reply to comment #10) > For those seeking for help, the correct line in package.use is: > > cross-i686-pc-mingw32/gcc -openmp > The above line or the following cross-i686-mingw32/gcc -openmp doesn't work for me: the line in package.use is replaced by crossdev every time. I were able to compile it only with following command: # USE=-openmp crossdev -t i686-mingw32 Could someone explain me why this bug is closed as INVALID? I use a default profile and don't enable USE=openmp by myself (comment #5), so why should I have to run the above command to get it working? Shouldn't openmp use-flag be managed by crossdev utility? Thanks, Roberto
(In reply to comment #11) > (In reply to comment #10) > > For those seeking for help, the correct line in package.use is: > > > > cross-i686-pc-mingw32/gcc -openmp > > > > The above line or the following > cross-i686-mingw32/gcc -openmp > doesn't work for me: the line in package.use is replaced by crossdev every > time. I were able to compile it only with following command: > # USE=-openmp crossdev -t i686-mingw32 Strange. Do you use the latest crossdev-20100620? I've compiled i686-pc-mingw32 target successfully. Maybe your target (i686-mingw32) isn't exactly the same, but I'm not an expert. > Could someone explain me why this bug is closed as INVALID? > I use a default profile and don't enable USE=openmp by myself (comment #5), so > why should I have to run the above command to get it working? Shouldn't openmp > use-flag be managed by crossdev utility? Yeah, mingw32 doesn't have pthreads during the building of the toolchain. I don't know if it is possible, but it would be great to have the default "-openmp" for mingw32 target.
No proper reply were given to my questions in comment #11, so I consider this bug still VALID. Workaround given in comment #8 doesn't work for me; the line in /etc/portage/package.use is replaced by crossdev as following: - before running 'crossdev -t i686-pc-mingw32': cross-i686-pc-mingw32/gcc -openmp - while Emerging cross-gcc-stage1: cross-i686-pc-mingw32/gcc -selinux -boundschecking -d -gtk -gcj -libffi -mudflap -objc -objc++ -objc-gc -fortran nocxx -openmp - while Emerging cross-gcc-stage2: cross-i686-pc-mingw32/gcc -selinux -boundschecking -d -gtk -gcj -libffi -mudflap -objc -objc++ -objc-gc If *mingw32-gcc doesn't compile with a use-flag enabled by a default profile, I think crossdev utility should disable this use-flag. Proposed patch: --- crossdev 2010-06-26 14:59:12.000000000 +0200 +++ /usr/bin/crossdev 2010-07-26 11:20:15.610562738 +0200 @@ -165,7 +165,8 @@ mingw*|*-mingw*) WITH_DEF_HEADERS="yes"; KCAT="dev-util"; KPKG="w32api"; - LCAT="dev-util"; LPKG="mingw-runtime";; + LCAT="dev-util"; LPKG="mingw-runtime"; + GUSE_DISABLE_STAGE_2="${GUSE_DISABLE_STAGE_2} -openmp";; msp430) STAGE_DEFAULT=${STAGE_BINUTILS};;
I'm still waiting for a comment where is explained the reason because this bug is INVALID. Why my proposed patch in comment #13 cannot be applied? Should I open a new bug because I cannot enable/disable a use-flag via per-package use file since the line is replaced by crossdev (as explained in comment #13)? Thanks and Regards, Roberto
Is the i686-mingw32 profile supported? If yes (which I hope so), it cannot be used with the default Gentoo's profile, which I think is a problem of crossdev/Gentoo profile, not the problem of the user. So this bug looks like perfectly valid for me. I thought that the default is here because it "just works" for _most_ of the users, but for i686-mingw32 target I think the building of cross-toolchain have to fail for _everybody_ using the default.
*** Bug 332085 has been marked as a duplicate of this bug. ***
This is obviously not fixed and the proposed workaround doesn't work as statet in comment #11.
I also hit this bug, and I never fiddled with the openmp useflag. Hence I also feel that crossdev should manage it. Additionaly my question: Why should there be no support for OpenMP for mingw32? There seem to be builds of the GCC suite for mingw32 which include this support (Google suggests this at least). Did they use special patches? If so, can these be included in Gentoo?
openmp works fine if you provide the packages for it. pthreads-win32 in other words. exactly like the error message told you: configure: error: Pthreads are required to build libgomp
(In reply to comment #19) > openmp works fine if you provide the packages for it. pthreads-win32 in other > words. exactly like the error message told you: > configure: error: Pthreads are required to build libgomp Can this package be included in Gentoo and then be managed via useflags, so crossdev can be adapted to not fail?
feel free to post an ebuild for it
In the meantime, is there any reason not to add GUSE="-openmp" to the mingw*|*-mingw* branch of the case ${CTARGET} statement? That should ensure that MinGW users disable OpenMP by default and it will not affect any other target architectures. Per the exchange in comment #18 through comment #21, it appears that at present there is no way for someone using only in-Portage packages to successfully build cross-mingw32/gcc with USE=openmp, so defaulting it to off should not hurt anyone, and would help people who run 'crossdev mingw32' and expect it to just work. The people reporting problems in this bug received USE=openmp because their profile set it for them, _not_ because they requested it.
See bug #333771 for a pthreads-w32 ebuild
(In reply to comment #23) > See bug #333771 for a pthreads-w32 ebuild The latest version of my ebuild makes libgomp compile.
mingw64 also won't compile with openmp
Just came across this problem with the latest version of crossdev. I added -openmp to gcc in /etc/portage/package.use but it gets removed again, and I can't mark the file read only because I have to run crossdev as root...
openmp is automatically disabled now when C library lacks pthreads support http://sources.gentoo.org/eclass/toolchain.eclass?r1=1.439&r2=1.440
This is 2016 now and this packages still fails to compile. Why is this marked RESOLVED when obviously it is NOT resolved? Nothing in the comments works. Please re-open and fix.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=37dded9b48c93a67b9a32b5eca2b1ef0fc6e8b9e commit 37dded9b48c93a67b9a32b5eca2b1ef0fc6e8b9e Author: Sam James <sam@gentoo.org> AuthorDate: 2025-04-21 06:10:28 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2025-04-21 06:18:14 +0000 sys-devel/gcc: add fixincludes patch to 15 too to fix openmp on regular cross targets Using lu_zero's repro instructions ... ``` $ crossdev -C riscv64 $ crossdev riscv64 -s3 $ find /usr -name pthread.h # to make sure glibc isn't doing something strange $ riscv64-unknown-linux-gnu-gcc -E - <<<"#include <pthread.h>" # this should work $ crossdev -C riscv64 $ crossdev riscv64 -s3 --g 15.0.1_pre20250418-r1 $ find /usr -name pthread.h # to make sure glibc isn't doing something strange $ riscv64-unknown-linux-gnu-gcc -E - <<<"#include <pthread.h>" # this should fail because it looks only on the compiler dir ``` ... we see that openmp.h is missing and --disable-libgomp was passed because our test in toolchain.eclass was failing: ``` # Make sure target has pthreads support: bug #326757, bug #335883 # There shouldn't be a chicken & egg problem here as openmp won't # build without a C library, and you can't build that w/o # already having a compiler... if ! is_crosscompile || $(tc-getCPP ${CTARGET}) -E - <<<"#include <pthread.h>" >& /dev/null ; then confgcc+=( $(use_enable openmp libgomp) ) else # Force disable as the configure script can be dumb, bug #359855 confgcc+=( --disable-libgomp ) fi ``` Adding in the gcc-13-fix-cross-fixincludes.patch patch we're already using for other versions fixes it by adding /usr/${CHOST}/usr/include in the search path of the stage1 crossdev GCC. We may still want to add a workaround in toolchain.eclass like: ``` - $(tc-getCPP ${CTARGET}) -E - <<<"#include <pthread.h>" >& /dev/null + $(tc-getCPP ${CTARGET}) -I/usr/${CTARGET}/usr/include -E - <<<"#include <pthread.h>" >& /dev/null ``` Or maybe add some warning if it failed when weren't expecting it to on some targets. I'll move this patch to gcc-patches at some point. Bug: https://gcc.gnu.org/PR115416 Bug: https://bugs.gentoo.org/326757 Bug: https://bugs.gentoo.org/335883 Bug: https://bugs.gentoo.org/905118 Bug: https://bugs.gentoo.org/909453 Bug: https://bugs.gentoo.org/925204 Bug: https://bugs.gentoo.org/926059 Thanks-to: Luca Barbato <lu_zero@gentoo.org> Signed-off-by: Sam James <sam@gentoo.org> sys-devel/gcc/gcc-15.0.1_pre20250418-r1.ebuild | 1 + 1 file changed, 1 insertion(+)
