since upstream mingw-runtime/w32api is largely dormant, and mingw64-runtime is active and supports both 32bit & 64bit, let's convert all mingw targets to use the mingw64-runtime
hmm, the current src_configure does: case ${CTARGET} in x86_64*) extra_conf+=( --disable-lib32 --enable-lib64 ) ;; i?86*) extra_conf+=( --enable-lib32 --disable-lib64 ) ;; *) die "Unsupported ${CTARGET}" ;; esac i guess we should add mingw* to the i?86 case ? any other tuples to worry about ?
I do not follow, it is all working right now as this is executed only for mingw-w64, no?
(In reply to Alon Bar-Lev from comment #2) crossdev needs updating to not refer to mingw-runtime. the choices are: (1) rewrite all "mingw" and "mingw32" tuples to the more verbose equiv (2) change those tuples to use mingw64-runtime i prefer (2) because in the wider world, some people expect "mingw-xxx" or "mingw32-xxx". but when you do that, mingw64-runtime gets upset.
Not sure I understand what you recommend. Personally, I am very happy with the current crossdev approach of specify the tuple explicitly with no magic. I am unsure that if we add magic we are not adding confusion. There is also a glitch in config.guess that leaves the mingw32 in tuple. So we end up with: (x86_64|i?86*)-w64-mingw* While as recommended by upstream it will be: (x86_64|i?86*)-w64-mingw32
(In reply to Alon Bar-Lev from comment #4) so we need to update the mingw64-runtime ebuild to handle more tuples
(In reply to SpanKY from comment #5) > (In reply to Alon Bar-Lev from comment #4) > > so we need to update the mingw64-runtime ebuild to handle more tuples I truly do not understand, my bad probably. In the ebuild we check for x86_64 or i?86 only to know if we building 32bit or 64bit. This ebuild will run only if mingw64-runtime is requested. We know if mingw64-runtime is requested based on the *-w64-mingw* signature in crossdev. All working perfectly now. If we remove mingw it does not affect any of the above. I do not see any reason to change anything, but I must miss something.
(In reply to Alon Bar-Lev from comment #6) systems expect to be able to do `mingw-gcc`. with that in mind, we should be supporting `crossdev mingw`. now we get to my comment #3 in this bug. assuming we go with (2) outlined in comment #3, we need to update the mingw64-runtime ebuild to handle `mingw-gcc` style tuples. which means listing more tuples in the ebuild as i mentioned in comment #5. however, i think we have an even easier route here: if the ebuild merely needs to select between 32-bit & 64-bit, i don't think we need to list any tuples at all. we can look at the characteristics of the compiler output. e.g. change src_configure to do: $(tc-getCPP CTARGET) ${CFLAGS} ${CPPFLAGS} -E -dD -P -o "${T}"/test.i - <<<'' || die if grep -q __MINGW64__ "${T}"/test.i ; then extra_conf+=( --disable-lib32 --enable-lib64 ) else extra_conf+=( --enable-lib32 --disable-lib64 ) fi that make sense ?
Yes, just checked that and it will work. However, I was under the impression that it is bad practice to relay on these macros. xxx-cpp -dM /dev/null | grep -q __MINGW64__ && echo ok xxx-cpp -dM /dev/null | grep -q __MINGW32__ && echo ok I will change sequence for that. One thing I had no courage to do is to build multilib configuration, maybe we should just enable both modes at any mode?
(In reply to Alon Bar-Lev from comment #8) there's also WIN64 & WIN32 defines. i have no experience/opinion on which is recommended. we could do a compile test and then use some tools to figure out whether the object is 32-bit or 64-bit, but just probing the preprocessor seemed easier. i have no problem enabling multilib support, but i think that'll require more plumbing to make sure gcc is DTRT first. let's minimize the changes so we can get mingw-runtime deprecated, and then file a follow up bug to figure out the best way to get multilib going.
Done for mingw64-runtime-4.0.6. I still think that short tuples should be avoided, and having mingw for mingw-w64 is confusing. Nevertheless it should work now.
(In reply to Alon Bar-Lev from comment #10) > Done for mingw64-runtime-4.0.6. > I still think that short tuples should be avoided, and having mingw for > mingw-w64 is confusing. > Nevertheless it should work now. Hi, Sorry to barge in, but I ran into a bug that lead me directly to the check outlined in comment #7 and comment #8. xxx-cpp -dM /dev/null | grep -q __MINGW64__ && echo ok xxx-cpp -dM /dev/null | grep -q __MINGW32__ && echo ok With gcc 5.x x86_64-w64-mingw32-gcc -dM /dev/null I am getting "x86_64-w64-mingw32-gcc: warning: /dev/null: linker input file unused because linking not done" but if I do "x86_64-w64-mingw32-gcc -dM /tmp/hello.c" I get the expected behavior. This is causing a failure in mingw64-runtime-4.0.6 on the following line because __MINGW64__ will never be present: $(tc-getCPP ${CTARGET}) ${CPPFLAGS} -dM /dev/null | grep -q __MINGW64__ \ && echo --disable-lib32 --enable-lib64 \ || echo --enable-lib32 --disable-lib64 Basically I am ending up with lib32 on my x86_64-w64-mingw32 target and then I cant build gcc.
(In reply to Alex Barker from comment #11) > $(tc-getCPP ${CTARGET}) ${CPPFLAGS} -dM /dev/null | grep -q __MINGW64__ \ > && echo --disable-lib32 --enable-lib64 \ > || echo --enable-lib32 --disable-lib64 I am using this to work around the issue: head -c 1 /dev/null | $(tc-getCPP ${CTARGET}) ${CPPFLAGS} -dM - | grep -q __MINGW64__ \ && echo --disable-lib32 --enable-lib64 \ || echo --enable-lib32 --disable-lib64
(In reply to Alex Barker from comment #11) > With gcc 5.x x86_64-w64-mingw32-gcc -dM /dev/null I am getting > "x86_64-w64-mingw32-gcc: warning: /dev/null: linker input file unused > because linking not done" but if I do "x86_64-w64-mingw32-gcc -dM > /tmp/hello.c" I get the expected behavior. You should run the pre-processor not the compiler.
(In reply to Alon Bar-Lev from comment #13) > > You should run the pre-processor not the compiler. I still cant check /dev/null directly: `echo | $(tc-getCPP ${CTARGET}) ${CPPFLAGS} -dM -E -`
(In reply to Alex Barker from comment #14) > (In reply to Alon Bar-Lev from comment #13) > > > > You should run the pre-processor not the compiler. > > I still cant check /dev/null directly: > > `echo | $(tc-getCPP ${CTARGET}) ${CPPFLAGS} -dM -E -` odd... the following should be cpp -dM /dev/null cpp -dM - < /dev/null
(In reply to Alex Barker from comment #14) > (In reply to Alon Bar-Lev from comment #13) > > > > You should run the pre-processor not the compiler. > > I still cant check /dev/null directly: > > `echo | $(tc-getCPP ${CTARGET}) ${CPPFLAGS} -dM -E -` sorry... odd... the following should be the same: --- cpp -dM /dev/null cpp -dM - < /dev/null --- creating another process should not be required and will have same result --- echo -n | cpp -dM - --- in all cases empty stdin is read by cpp. what is not working for you? what do you get? probably not related to this bug, but still.
(In reply to Alon Bar-Lev from comment #16) > the following should be the same: > --- > cpp -dM /dev/null > cpp -dM - < /dev/null > --- > Correct, that produces the same result. The issue for me seems to be that $(tc-getCPP ${CTARGET}) produces a g++ tripe not cpp which exhibit different behavior in this situation: crosscompiler devops # g++ -dM /dev/null /dev/null: file not recognized: File truncated collect2: error: ld returned 1 exit status crosscompiler devops # g++ -dM - < /dev/null g++: error: -E or -x required when input is from standard input > what is not working for you? what do you get? probably not related to this > bug, but still. The above cannot be grepped for __MINGW##__. It's related to this bug in the sense that the proposed fix does not fix in all scenarios.
I do not understand how you get g++ as cpp
(In reply to Alon Bar-Lev from comment #18) > I do not understand how you get g++ as cpp `$(tc-getCPP ${CTARGET})` returned "x86_64-w64-mingw32-gcc -E" for the check in question. It produces the similar problematic output I previously described with cpp vs g++. ----- x86_64-w64-mingw32-gcc -E -dM /dev/null x86_64-w64-mingw32-gcc: warning: /dev/null: linker input file unused because linking not done ----- x86_64-w64-mingw32-gcc -E -dM - < /dev/null #define __DBL_MIN_EXP__ (-1021) #define __UINT_LEAST16_MAX__ 0xffff #define __ATOMIC_ACQUIRE 2 #define __FLT_MIN__ 1.17549435082228750797e-38F #define __GCC_IEC_559_COMPLEX 2 .... -----
ok, not that I understand why you get gcc as cpp and I am not, however, I fixed this to use - and /dev/null as input.
(In reply to Alon Bar-Lev from comment #20) > ok, not that I understand why you get gcc as cpp and I am not, however, I > fixed this to use - and /dev/null as input. Appreciate the fix, thank you. I am not sure what I am getting that result from $(tc-getCPP ${CTARGET}) either. Perhaps it is related to USE=-cxx with cross-x86_64-w64-mingw32/gcc?
(In reply to Alex Barker from comment #21) > (In reply to Alon Bar-Lev from comment #20) > > ok, not that I understand why you get gcc as cpp and I am not, however, I > > fixed this to use - and /dev/null as input. > > Appreciate the fix, thank you. I am not sure what I am getting that result > from $(tc-getCPP ${CTARGET}) either. Perhaps it is related to USE=-cxx with > cross-x86_64-w64-mingw32/gcc? I am unsure what's wrong with your environment, it would be better if you open a different bug. I use -cxx as well. Please attach in new bug the logs of crossdev.
(In reply to Alon Bar-Lev from comment #20) this changed recently -- see bug 582822
almost one year without news, any plan to solve this bug?
Ping. Is anything going to happen here? Those two packages are blocking EAPI 0 removal.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/crossdev.git/commit/?id=b141f7e376212dbda5c70bdabd366a0161caa9ef commit b141f7e376212dbda5c70bdabd366a0161caa9ef Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-10-14 07:34:17 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-10-14 07:34:17 +0000 crossdev:drop support for short 'minw', 'mingw32' aliases From now on to get a 32-bit toolchain users would need to specify full tuple like: i686-w64-mingw32 That will use 'dev-util/mingw64-runtime'. Bug: https://bugs.gentoo.org/584858 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> crossdev | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5e3f338e92040f188e6b92e1a7cdd51908286ed8 commit 5e3f338e92040f188e6b92e1a7cdd51908286ed8 Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-10-14 07:39:08 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-10-14 07:39:14 +0000 sys-devel/crossdev: bump up to 20191014 The only change here is removal of 'mingw*' short aliases. Bug: https://bugs.gentoo.org/584858 Package-Manager: Portage-2.3.76, Repoman-2.3.17 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> sys-devel/crossdev/Manifest | 1 + sys-devel/crossdev/crossdev-20191014.ebuild | 36 +++++++++++++++++++++++++++++ 2 files changed, 37 insertions(+)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=b540ee3a734750265d5ca4a463a97a5d508ca3ff commit b540ee3a734750265d5ca4a463a97a5d508ca3ff Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-10-19 19:53:16 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-10-19 21:20:34 +0000 toolchain.eclass: drop support for deprecated mingw-runtime Bug: https://bugs.gentoo.org/584858 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> eclass/toolchain.eclass | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c61bbbef5950cf52bf752043efcb7ce68357cb7e commit c61bbbef5950cf52bf752043efcb7ce68357cb7e Author: Sergei Trofimovich <slyfox@gentoo.org> AuthorDate: 2019-10-20 08:35:26 +0000 Commit: Sergei Trofimovich <slyfox@gentoo.org> CommitDate: 2019-10-20 08:41:40 +0000 dev-util/w32api, dev-util/mingw-runtime: drop packages Drop mingw-runtime-based packages. Use mingw64-runtime-based ones instead. Here are example mingw64-based tuples to use: - i686-w64-mingw32 (equivalent of mingw32) - x86_64-w64-mingw32 (equivalent on migw64?) crossdev can be used to recreate new cross-environment. Closes: https://bugs.gentoo.org/584858 Closes: https://bugs.gentoo.org/511492 Closes: https://bugs.gentoo.org/568500 Closes: https://bugs.gentoo.org/574556 Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org> dev-util/mingw-runtime/Manifest | 4 - .../files/mingw-runtime-3.18-gcc-4.6.patch | 27 ---- .../files/mingw-runtime-3.20-LDBL_MIN_EXP.patch | 145 --------------------- dev-util/mingw-runtime/metadata.xml | 11 -- dev-util/mingw-runtime/mingw-runtime-3.18.ebuild | 76 ----------- dev-util/mingw-runtime/mingw-runtime-3.20.2.ebuild | 77 ----------- dev-util/mingw-runtime/mingw-runtime-3.20.ebuild | 75 ----------- .../mingw-runtime/mingw-runtime-4.0.3.1.ebuild | 82 ------------ dev-util/w32api/Manifest | 2 - dev-util/w32api/metadata.xml | 11 -- dev-util/w32api/w32api-3.17.2.ebuild | 64 --------- dev-util/w32api/w32api-4.0.3.1.ebuild | 66 ---------- profiles/package.mask | 2 - 13 files changed, 642 deletions(-)
