From: Joe B. <joe...@gm...> - 2012-05-16 14:41:03
|
Hi guys, Anyone else noticed this very minor build bug with make's configure: https://sourceforge.net/tracker/?func=detail&atid=202435&aid=3523436&group_id=2435 <https://sourceforge.net/tracker/?func=detail&atid=202435&aid=3523436&group_id=2435> I don't agree with the response: This is a user error in specifying the host for which the package is to be residing for. You should specify --host=mingw32 to resolve this issue. There is no such system as mingw32msvc. This doesn't fit with what I'm seeing, see below. Even if you use "--host=mingw32" you see the same problem as with "--host=i586-mingw32" below. Only "--host=i586-mingw32msvc" builds and only if you do that one character fix to make the offending line match the wild cards of other parts that also refer to mingw32. The name must match what the mingw executables are called, and for me at least, that's "i586-mingw32msvc". Joe -------- Original Message -------- Subject: Re: make bug 3523436 Date: Wed, 16 May 2012 07:16:56 -0400 From: Earnie Boyd <ea...@us...> To: Joe Burmeister <ja...@us...> Take it to min...@li... for follow-up. On Wed, May 16, 2012 at 6:18 AM, Joe Burmeister <ja...@us...> wrote: > Hi Earnie, > > Didn\'t see how to reopen the bug. > > If I use \"./configure --host=i586-mingw32\", when I come to > do \"make\" I get \"fatal error: windows.h: No such file or > directory\". > Once the tiny one character fix is added (that makes it > consistent with other mingw references), doing \"./configure > --host=i586-mingw32msvc\" compiles without issue. > > The reason why can be seen during the configure output when > given just \"i586-mingw32\". > > checking for i586-mingw32-strip... no > checking for i586-mingw32-gcc... no > checking for i586-mingw32-ranlib... no > > compared with: > > checking for i586-mingw32msvc-strip... i586-mingw32msvc-strip > checking for i586-mingw32msvc-gcc... i586-mingw32msvc-gcc > checking for i586-mingw32msvc-ranlib... i586-mingw32msvc-ranlib > > etc etc. You get the idea. > > If you do \"dpkg -L mingw32\" everything is mingw32msvc, least > in Ubuntu 11.10. > > -- > This message was sent to your SourceForge.net email alias via the web mail form. You may reply to this message directly, or via https://sourceforge.net/sendmessage.php?touser=2640546 > To update your email alias preferences, please visit https://sourceforge.net/account -- Earnie -- https://sites.google.com/site/earnieboyd |
From: Teemu N. <sti...@ya...> - 2012-05-16 14:54:28
|
On 16.5.2012 17:40, Joe Burmeister wrote: > Even if you use "--host=mingw32" you see the same problem as with > "--host=i586-mingw32" below. > Only "--host=i586-mingw32msvc" builds and only if you do that one > character fix to make the offending line match the wild cards of other > parts that also refer to mingw32. > > The name must match what the mingw executables are called, and for me at > least, that's "i586-mingw32msvc". Whoever is releasing Ubuntu's cross-compiler should really migrate away from i586-mingw32msvc naming. I haven't seen that in years and it really should be deprecated. |
From: Joe B. <joe...@gm...> - 2012-05-16 15:07:14
|
Quite possibly, but at the cost of one extra wild card, making the line in question match the others, it and and other crazy names, can be supported in the ./configure file though. On 16/05/12 15:54, Teemu Nätkinniemi wrote: > On 16.5.2012 17:40, Joe Burmeister wrote: > >> Even if you use "--host=mingw32" you see the same problem as with >> "--host=i586-mingw32" below. >> Only "--host=i586-mingw32msvc" builds and only if you do that one >> character fix to make the offending line match the wild cards of other >> parts that also refer to mingw32. >> >> The name must match what the mingw executables are called, and for me at >> least, that's "i586-mingw32msvc". > Whoever is releasing Ubuntu's cross-compiler should really migrate away > from i586-mingw32msvc naming. I haven't seen that in years and it really > should be deprecated. > > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe |
From: Teemu N. <sti...@ya...> - 2012-05-17 02:47:33
|
On 16.5.2012 18:06, Joe Burmeister wrote: > On 16/05/12 15:54, Teemu Nätkinniemi wrote: >> On 16.5.2012 17:40, Joe Burmeister wrote: >> >>> Even if you use "--host=mingw32" you see the same problem as with >>> "--host=i586-mingw32" below. >>> Only "--host=i586-mingw32msvc" builds and only if you do that one >>> character fix to make the offending line match the wild cards of other >>> parts that also refer to mingw32. >>> >>> The name must match what the mingw executables are called, and for me at >>> least, that's "i586-mingw32msvc". >> Whoever is releasing Ubuntu's cross-compiler should really migrate away >> from i586-mingw32msvc naming. I haven't seen that in years and it really >> should be deprecated. > Quite possibly, but at the cost of one extra wild card, making the line > in question match the others, it and and other crazy names, can be > supported in the ./configure file though. You do have a valid point but at the moment both official MinGW and most major Linux distributions apart from Debian based use *-*-mingw32 as a host triplet. Supporting *-*-mingw32* would mean all the sources using autotools would have to be patched instead of going the easier route which would mean Debian based distros toeing the line and using *-*-mingw32 as a host triplet. |
From: Joe B. <joe...@gm...> - 2012-05-17 07:53:18
|
On 17/05/12 03:47, Teemu Nätkinniemi wrote: > On 16.5.2012 18:06, Joe Burmeister wrote: > >> On 16/05/12 15:54, Teemu Nätkinniemi wrote: >>> On 16.5.2012 17:40, Joe Burmeister wrote: >>> >>>> Even if you use "--host=mingw32" you see the same problem as with >>>> "--host=i586-mingw32" below. >>>> Only "--host=i586-mingw32msvc" builds and only if you do that one >>>> character fix to make the offending line match the wild cards of other >>>> parts that also refer to mingw32. >>>> >>>> The name must match what the mingw executables are called, and for me at >>>> least, that's "i586-mingw32msvc". >>> Whoever is releasing Ubuntu's cross-compiler should really migrate away >>> from i586-mingw32msvc naming. I haven't seen that in years and it really >>> should be deprecated. > > Quite possibly, but at the cost of one extra wild card, making the line > > in question match the others, it and and other crazy names, can be > > supported in the ./configure file though. > > You do have a valid point but at the moment both official MinGW and most > major Linux distributions apart from Debian based use *-*-mingw32 as a > host triplet. Supporting *-*-mingw32* would mean all the sources using > autotools would have to be patched instead of going the easier route > which would mean Debian based distros toeing the line and using > *-*-mingw32 as a host triplet. But Debian based distributions is an awful lot of distributions and an awful lot of current installs. In many polls I've seen, it seams to be over half of the Linux installs. We aren't talking a big change to support them, it's one character, and it's not even a unique change, it's merely making one line match others doing the same thing. Arguing Debian distros should instead make much bigger changes doesn't make sense to me. |
From: Teemu N. <sti...@ya...> - 2012-05-17 08:15:02
|
On 17.5.2012 10:53, Joe Burmeister wrote: > On 17/05/12 03:47, Teemu Nätkinniemi wrote: >> On 16.5.2012 18:06, Joe Burmeister wrote: >> >>> On 16/05/12 15:54, Teemu Nätkinniemi wrote: >>>> On 16.5.2012 17:40, Joe Burmeister wrote: >>>> >>>>> Even if you use "--host=mingw32" you see the same problem as with >>>>> "--host=i586-mingw32" below. >>>>> Only "--host=i586-mingw32msvc" builds and only if you do that one >>>>> character fix to make the offending line match the wild cards of other >>>>> parts that also refer to mingw32. >>>>> >>>>> The name must match what the mingw executables are called, and for me at >>>>> least, that's "i586-mingw32msvc". >>>> Whoever is releasing Ubuntu's cross-compiler should really migrate away >>>> from i586-mingw32msvc naming. I haven't seen that in years and it really >>>> should be deprecated. >> > Quite possibly, but at the cost of one extra wild card, making the line >> > in question match the others, it and and other crazy names, can be >> > supported in the ./configure file though. >> >> You do have a valid point but at the moment both official MinGW and most >> major Linux distributions apart from Debian based use *-*-mingw32 as a >> host triplet. Supporting *-*-mingw32* would mean all the sources using >> autotools would have to be patched instead of going the easier route >> which would mean Debian based distros toeing the line and using >> *-*-mingw32 as a host triplet. > > But Debian based distributions is an awful lot of distributions and an > awful lot of current installs. In many polls I've seen, it seams to be > over half of the Linux installs. We aren't talking a big change to > support them, it's one character, and it's not even a unique change, > it's merely making one line match others doing the same thing. Arguing > Debian distros should instead make much bigger changes doesn't make > sense to me. That one character change needs to be done to all packages that support Autoconf/Automake whereas whoever maintains Debian-based MinGW packages could just change their build script to say --host=i686-pc-mingw32 or just =mingw32 and the next release of packages would be automatically compatible with rest of the MinGW world. |
From: Joe B. <joe...@gm...> - 2012-05-17 08:37:42
|
On 17/05/12 09:14, Teemu Nätkinniemi wrote: > On 17.5.2012 10:53, Joe Burmeister wrote: >> On 17/05/12 03:47, Teemu Nätkinniemi wrote: >>> On 16.5.2012 18:06, Joe Burmeister wrote: >>> >>>> On 16/05/12 15:54, Teemu Nätkinniemi wrote: >>>>> On 16.5.2012 17:40, Joe Burmeister wrote: >>>>> >>>>>> Even if you use "--host=mingw32" you see the same problem as with >>>>>> "--host=i586-mingw32" below. >>>>>> Only "--host=i586-mingw32msvc" builds and only if you do that one >>>>>> character fix to make the offending line match the wild cards of other >>>>>> parts that also refer to mingw32. >>>>>> >>>>>> The name must match what the mingw executables are called, and for me at >>>>>> least, that's "i586-mingw32msvc". >>>>> Whoever is releasing Ubuntu's cross-compiler should really migrate away >>>>> from i586-mingw32msvc naming. I haven't seen that in years and it really >>>>> should be deprecated. >>> > Quite possibly, but at the cost of one extra wild card, making the line >>> > in question match the others, it and and other crazy names, can be >>> > supported in the ./configure file though. >>> >>> You do have a valid point but at the moment both official MinGW and most >>> major Linux distributions apart from Debian based use *-*-mingw32 as a >>> host triplet. Supporting *-*-mingw32* would mean all the sources using >>> autotools would have to be patched instead of going the easier route >>> which would mean Debian based distros toeing the line and using >>> *-*-mingw32 as a host triplet. >> But Debian based distributions is an awful lot of distributions and an >> awful lot of current installs. In many polls I've seen, it seams to be >> over half of the Linux installs. We aren't talking a big change to >> support them, it's one character, and it's not even a unique change, >> it's merely making one line match others doing the same thing. Arguing >> Debian distros should instead make much bigger changes doesn't make >> sense to me. > That one character change needs to be done to all packages that support > Autoconf/Automake whereas whoever maintains Debian-based MinGW packages > could just change their build script to say --host=i686-pc-mingw32 or > just =mingw32 and the next release of packages would be automatically > compatible with rest of the MinGW world. > How come there are other lines that already have this? Is this a older way of doing things that has been moved from and those other lines are left overs? I was just thinking that one character can be added. I wasn't thinking big picture. Perhaps maybe what you want to do instead is remove the trailing wildcard from the other lines (when found, not worth a hunt), least making it consistent. If there is a debate about the mingw naming, a compromise would be to fix lines as they come up to support both camps, but not actively hunt them. |
From: Keith M. <kei...@us...> - 2012-05-17 09:03:45
|
On 17 May 2012 09:37, Joe Burmeister wrote: > If there is a debate about the mingw naming, a compromise would be to > fix lines as they come up to support both camps, but not actively hunt them. There is no debate. This project is concerned with an OS designated as mingw32; you need a cross compiler which builds for that[*]. Your cross compiler builds for an OS designated as mingw32msvc; we don't maintain any such OS. If you wish to effect changes WRT the mingw32msvc OS, then you should direct your concerns to the owners/maintainers of that OS; you will not find them here. [*] FWIW, I routinely build all of my contributions to MinGW.org by cross compiling on a LinuxMint -- a Debian/Ubuntu derivative -- host; my cross compiler builds for mingw32, NOT for mingw32msvc. (Yes, I did build it myself, from source, because LinuxMint doesn't offer a ready built cross compiler for the mingw32 OS which we support). -- Regards, Keith. |
From: Joe B. <joe...@gm...> - 2012-05-17 10:02:54
|
On 17/05/12 10:03, Keith Marshall wrote: > On 17 May 2012 09:37, Joe Burmeister wrote: >> If there is a debate about the mingw naming, a compromise would be to >> fix lines as they come up to support both camps, but not actively hunt them. > There is no debate. This project is concerned with an OS designated as > mingw32; you need a cross compiler which builds for that[*]. Your cross > compiler builds for an OS designated as mingw32msvc; we don't maintain > any such OS. If you wish to effect changes WRT the mingw32msvc OS, then > you should direct your concerns to the owners/maintainers of that OS; > you will not find them here. > > [*] FWIW, I routinely build all of my contributions to MinGW.org by > cross compiling on a LinuxMint -- a Debian/Ubuntu derivative -- host; > my cross compiler builds for mingw32, NOT for mingw32msvc. (Yes, I did > build it myself, from source, because LinuxMint doesn't offer a ready > built cross compiler for the mingw32 OS which we support). > The maintainers of mingw32msvc don't build make like this. Anyway, had a look and does indeed look like Debain is moving away from mingw32msvc name at the same time as they are supporting MinGW-w64. Feel I did my due diligence on this and learned some stuff. Cheers for the info. :-) |
From: Sam M. <sa...@ro...> - 2012-05-17 09:52:05
|
On Thu, 17 May 2012 05:47:20 +0300, Teemu Nätkinniemi wrote: > On 16.5.2012 18:06, Joe Burmeister wrote: > >> On 16/05/12 15:54, Teemu Nätkinniemi wrote: >>> On 16.5.2012 17:40, Joe Burmeister wrote: >>> >>>> Even if you use "--host=mingw32" you see the same problem as with >>>> "--host=i586-mingw32" below. >>>> Only "--host=i586-mingw32msvc" builds and only if you do that one >>>> character fix to make the offending line match the wild cards of >>>> other parts that also refer to mingw32. >>>> >>>> The name must match what the mingw executables are called, and for me >>>> at least, that's "i586-mingw32msvc". >>> Whoever is releasing Ubuntu's cross-compiler should really migrate >>> away from i586-mingw32msvc naming. I haven't seen that in years and it >>> really should be deprecated. > > > Quite possibly, but at the cost of one extra wild card, making the > > line in question match the others, it and and other crazy names, can > > be supported in the ./configure file though. > > You do have a valid point but at the moment both official MinGW and most > major Linux distributions apart from Debian based use *-*-mingw32 as a > host triplet. Supporting *-*-mingw32* would mean all the sources using > autotools would have to be patched instead of going the easier route > which would mean Debian based distros toeing the line and using > *-*-mingw32 as a host triplet. The current state of the various GCC/mingw* packages in Debian is quite confusing. The removal of the 'msvc' suffix took place some time ago with the transition to GCC 4.6 & mingw-w64. There is a transitional 'gcc- mingw32' package that used to provide GCC 4.4 with the 'msvc' suffix; nowadays it only provides compatibility symlinks and depends on 'gcc- mingw-64'. This work will be part of the next Stable release, 7.0. The old, obsolete 'mingw32' package, which is the source of the 'msvc' suffix AFAIK, still exists. The last time it was touched save for build system maintenance was 2007. Unfortunately, some users will inevitably find it and try to use it. As far as I can see, it remains in the Distribution so that autorun4linuxcd, cpio-win32 and netbeans can be built. -- Sam |
From: Joe B. <joe...@gm...> - 2012-05-17 10:07:03
|
On 17/05/12 10:51, Sam Morris wrote: > On Thu, 17 May 2012 05:47:20 +0300, Teemu Nätkinniemi wrote: > >> On 16.5.2012 18:06, Joe Burmeister wrote: >> >>> On 16/05/12 15:54, Teemu Nätkinniemi wrote: >>>> On 16.5.2012 17:40, Joe Burmeister wrote: >>>> >>>>> Even if you use "--host=mingw32" you see the same problem as with >>>>> "--host=i586-mingw32" below. >>>>> Only "--host=i586-mingw32msvc" builds and only if you do that one >>>>> character fix to make the offending line match the wild cards of >>>>> other parts that also refer to mingw32. >>>>> >>>>> The name must match what the mingw executables are called, and for me >>>>> at least, that's "i586-mingw32msvc". >>>> Whoever is releasing Ubuntu's cross-compiler should really migrate >>>> away from i586-mingw32msvc naming. I haven't seen that in years and it >>>> really should be deprecated. >> > Quite possibly, but at the cost of one extra wild card, making the >> > line in question match the others, it and and other crazy names, can >> > be supported in the ./configure file though. >> >> You do have a valid point but at the moment both official MinGW and most >> major Linux distributions apart from Debian based use *-*-mingw32 as a >> host triplet. Supporting *-*-mingw32* would mean all the sources using >> autotools would have to be patched instead of going the easier route >> which would mean Debian based distros toeing the line and using >> *-*-mingw32 as a host triplet. > The current state of the various GCC/mingw* packages in Debian is quite > confusing. The removal of the 'msvc' suffix took place some time ago with > the transition to GCC 4.6& mingw-w64. There is a transitional 'gcc- > mingw32' package that used to provide GCC 4.4 with the 'msvc' suffix; > nowadays it only provides compatibility symlinks and depends on 'gcc- > mingw-64'. This work will be part of the next Stable release, 7.0. > > The old, obsolete 'mingw32' package, which is the source of the 'msvc' > suffix AFAIK, still exists. The last time it was touched save for build > system maintenance was 2007. Unfortunately, some users will inevitably > find it and try to use it. As far as I can see, it remains in the > Distribution so that autorun4linuxcd, cpio-win32 and netbeans can be > built. > Thats basically what happened to me. Just found out about all this. Easy to think mingw32 is for 32bit and mingw-w64 for 64bit! All makes sense now I know mingw32 is ye old and things have changed. |