Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 584858 - dev-util/mingw-runtime & dev-util/w32api: drop in favor of dev-util/mingw64-runtime
Summary: dev-util/mingw-runtime & dev-util/w32api: drop in favor of dev-util/mingw64-r...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal with 1 vote (vote)
Assignee: Gentoo Crossdev team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 473708 511490 568500 574556 EAPI0Removal
  Show dependency tree
 
Reported: 2016-06-02 15:50 UTC by SpanKY
Modified: 2019-10-20 08:41 UTC (History)
4 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description SpanKY gentoo-dev 2016-06-02 15:50:32 UTC
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
Comment 1 SpanKY gentoo-dev 2016-06-02 16:00:07 UTC
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 ?
Comment 2 Alon Bar-Lev (RETIRED) gentoo-dev 2016-06-02 16:06:32 UTC
I do not follow, it is all working right now as this is executed only for mingw-w64, no?
Comment 3 SpanKY gentoo-dev 2016-06-02 16:16:26 UTC
(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.
Comment 4 Alon Bar-Lev (RETIRED) gentoo-dev 2016-06-02 20:54:38 UTC
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
Comment 5 SpanKY gentoo-dev 2016-06-03 02:15:01 UTC
(In reply to Alon Bar-Lev from comment #4)

so we need to update the mingw64-runtime ebuild to handle more tuples
Comment 6 Alon Bar-Lev (RETIRED) gentoo-dev 2016-06-03 09:19:40 UTC
(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.
Comment 7 SpanKY gentoo-dev 2016-06-06 19:14:03 UTC
(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 ?
Comment 8 Alon Bar-Lev (RETIRED) gentoo-dev 2016-06-06 19:44:40 UTC
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?
Comment 9 SpanKY gentoo-dev 2016-06-06 22:11:56 UTC
(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.
Comment 10 Alon Bar-Lev (RETIRED) gentoo-dev 2016-06-07 19:13:09 UTC
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.
Comment 11 Alex Barker 2016-07-31 20:57:02 UTC
(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.
Comment 12 Alex Barker 2016-07-31 21:14:14 UTC
(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
Comment 13 Alon Bar-Lev (RETIRED) gentoo-dev 2016-08-01 03:39:33 UTC
(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.
Comment 14 Alex Barker 2016-08-06 18:42:57 UTC
(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 -`
Comment 15 Alon Bar-Lev (RETIRED) gentoo-dev 2016-08-06 21:43:18 UTC
(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
Comment 16 Alon Bar-Lev (RETIRED) gentoo-dev 2016-08-06 21:45:48 UTC
(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.
Comment 17 Alex Barker 2016-08-07 16:52:32 UTC
(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.
Comment 18 Alon Bar-Lev (RETIRED) gentoo-dev 2016-08-07 16:54:54 UTC
I do not understand how you get g++ as cpp
Comment 19 Alex Barker 2016-08-07 19:04:49 UTC
(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
....
-----
Comment 20 Alon Bar-Lev (RETIRED) gentoo-dev 2016-08-07 19:44:08 UTC
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.
Comment 21 Alex Barker 2016-08-07 20:19:24 UTC
(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?
Comment 22 Alon Bar-Lev (RETIRED) gentoo-dev 2016-08-07 20:24:10 UTC
(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.
Comment 23 SpanKY gentoo-dev 2016-08-10 06:00:40 UTC
(In reply to Alon Bar-Lev from comment #20)

this changed recently -- see bug 582822
Comment 24 Fabio Rossi 2017-07-03 13:42:26 UTC
almost one year without news, any plan to solve this bug?
Comment 25 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2019-10-04 21:29:22 UTC
Ping.  Is anything going to happen here?  Those two packages are blocking EAPI 0 removal.
Comment 26 Larry the Git Cow gentoo-dev 2019-10-14 07:35:43 UTC
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(-)
Comment 27 Larry the Git Cow gentoo-dev 2019-10-14 07:39:21 UTC
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(+)
Comment 28 Larry the Git Cow gentoo-dev 2019-10-19 21:20:45 UTC
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(-)
Comment 29 Larry the Git Cow gentoo-dev 2019-10-20 08:41:55 UTC
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(-)