problems with mingw support for Open Source projects

classic Classic list List threaded Threaded
8 messages Options
ml
Reply | Threaded
Open this post in threaded view
|

problems with mingw support for Open Source projects

ml
I'm running across more and more Open Source projects that are only
supporting mingw64.  When I send in patches, I now need to specify which
mingw project I'm using.  I just reported some problems building aria2 and
sent them some patches for mingw that would allow it to build without
errors.  They told me they are only supporting mingw64.  I ran across the
same situation from the Enlightenment developers a while back.  Other
projects I've contacted are giving similar responses.

I started with the original mingw project and I would like to continue to
use it for Open Source development.  Am finding the whole situation rather
frustrating.  Many Open Source projects don't appear to want to support
mingw (www.mingw.org) development.  Any suggestions?  I'd really rather
not be forced to switch all my Windows development to mingw64 just to get
Open Source programs and libraries to build.  Would it help if more mingw
users contacted or got involved with Open Source projects and asked for
support for the compiler?  Is there anything mingw (www.mingw.org) users
can do to improve the situation?

Thanks.

Sincerely,
Laura
http://www.distasis.com/cpp/mingw.htm


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: problems with mingw support for Open Source projects

Gisle Vanem-3
<[hidden email]> wrote:

> I'm running across more and more Open Source projects that are only
> supporting mingw64.  When I send in patches, I now need to specify which
> mingw project I'm using.  I just reported some problems building aria2 and
> sent them some patches for mingw that would allow it to build without
> errors.

It's kind of confusing situation, yes. I cannot advice much on making
mingw.org more acceptable for projects. But the resentment toward
old-school MingW is probably partly because of the somewhat
confusing situation with how both projects define '__MINGW32__'?

So how should porters/contributor make a distinction between those
2 MingW projects? When working on this porting issue 1 years ago, I
figured the only way was to test for '__MINGW64_VERSION_MAJOR' vs.
'__MINGW_MAJOR_VERSION'. (I got help very good help from Mr. Ozkan
Sezer; a mingw64 contributor). I assume the situation is the same now.
Otherwise, please Laura correct me on the following version+CPU test:

...
  char *p = version_buf;

#if defined(__MINGW32__) && defined(__MINGW64_VERSION_MAJOR)
  p += sprintf (p, "MinGW-w64 %d.%d, ",
                __MINGW64_VERSION_MAJOR, __MINGW64_VERSION_MINOR);

#elif defined(__MINGW32__)
  /* mingw.org: MingW-RunTime-4+ defines '__MINGW_MAJOR_VERSION' */
  #if defined(__MINGW_MAJOR_VERSION)
    p += sprintf (p, "MinGW %d.%d, ", __MINGW_MAJOR_VERSION, __MINGW_MINOR_VERSION);
  #else  /* so this should be MingW-RunTime 3.2 or older */
    p += sprintf (p, "MinGW %d.%d, ", __MINGW32_MAJOR_VERSION, __MINGW32_MINOR_VERSION);
  #endif

#elif defined(__CYGWIN__)
  ... etc.
#endif

Now do the same for 'gcc -mXX':

  /* gcc -m46. One can ass-u-me this is MingW64, but it could also be [1] */
  #if defined(__x86_64__)
    strcpy (p, " (x86-64), ");
  #elif defined(__i386__)
    strcpy (p, " (x32), ");
   ...
  #endif

The tests should be made carefully and in the correct order. Look in respective
<_mingw.h> for details. The above should be simplified; A project should maybe
make a '#define MINGW_OLD_SCHOOL 1' based on the above built-in defines?

The situation was frustrating for Mr Lavavej too. So he made his own very good
MingW (x64 native) light-weight distro;
  [1]  http://nuwen.net/mingw.html

So when I finally upgrade to Win8.1 (with a i7 CPU?), I will use his distro to target
x64-native. And not the rather confusing distro from http://mingw-w64.sourceforge.net/.
Just their options of Mingw-builds, Win-builds, threading-model, SEH/sjlj and the
huge filenames at SF is one reason to scare new user off in a second. E.g.
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/mingw-builds/4.8.2/threads-win32/sjlj/x86_64-4.8.2-release-win32-sjlj-rt_v3-rev2.7z/download

Just my opinion.

--gv





------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: problems with mingw support for Open Source projects

Erwin Waterlander
Gisle Vanem schreef op 2014-02-12 08:17:

>
> It's kind of confusing situation, yes. I cannot advice much on making
> mingw.org more acceptable for projects. But the resentment toward
> old-school MingW is probably partly because of the somewhat
> confusing situation with how both projects define '__MINGW32__'?
>
> So how should porters/contributor make a distinction between those
> 2 MingW projects? When working on this porting issue 1 years ago, I
> figured the only way was to test for '__MINGW64_VERSION_MAJOR' vs.
> '__MINGW_MAJOR_VERSION'. (I got help very good help from Mr. Ozkan
> Sezer; a mingw64 contributor). I assume the situation is the same now.
> Otherwise, please Laura correct me on the following version+CPU test:
>

I use gcc -dumpmachine in the makefile to see the difference, and define
my own variable that I use in my source code.

Makefile:

ifeq ($(shell gcc -dumpmachine),i686-w64-mingw32)
CFLAGS_COMPILER = -DWCD_COMPILER=MINGW32_W64
endif

c code:

#ifdef _WIN32
# ifdef _WIN64
#   ifdef _MSC_VER
     printf(_("Win64 version (MSVC %d).\n"),_MSC_VER);
#   else
     printf(_("Win64 version (MinGW-w64).\n"));
#   endif
# else
#   if defined(__WATCOMC__) && defined(__NT__)
     printf(_("Win32 version (WATCOMC).\n"));
#   elif defined(_MSC_VER)
     printf(_("Win32 version (MSVC %d).\n"),_MSC_VER);
#   elif defined(__MINGW32__) && (WCD_COMPILER == MINGW32_W64)
     printf(_("Win32 version (MinGW-w64).\n"));
#   else
     printf(_("Win32 version (MinGW).\n"));
#   endif
# endif
#endif


--
Erwin Waterlander
http://waterlan.home.xs4all.nl/

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: problems with mingw support for Open Source projects

Erwin Waterlander
In reply to this post by ml
[hidden email] schreef op 2014-02-11 23:13:

> I'm running across more and more Open Source projects that are only
> supporting mingw64.  When I send in patches, I now need to specify
> which
> mingw project I'm using.  I just reported some problems building aria2
> and
> sent them some patches for mingw that would allow it to build without
> errors.  They told me they are only supporting mingw64.  I ran across
> the
> same situation from the Enlightenment developers a while back.  Other
> projects I've contacted are giving similar responses.
>
> I started with the original mingw project and I would like to continue
> to
> use it for Open Source development.  Am finding the whole situation
> rather
> frustrating.  Many Open Source projects don't appear to want to support
> mingw (www.mingw.org) development.  Any suggestions?  I'd really rather
> not be forced to switch all my Windows development to mingw64 just to
> get
> Open Source programs and libraries to build.  Would it help if more
> mingw
> users contacted or got involved with Open Source projects and asked for
> support for the compiler?  Is there anything mingw (www.mingw.org)
> users
> can do to improve the situation?
>

I understand how you feel. I have been using mingw.org since 1999.

Today practically all Windows PCs ship with 64 bit Windows, and if you
want to target 64 bit Windows you have to use mingw-w64. When you made
that step, the next step to use mingw-w64 also for 32 bit is small.
Mingw-w64 seems to support a larger part of the Windows API
(http://qt-project.org/wiki/MinGW-64-bit). For me large file support was
the reason to switch definitively. I got bug reports that my 32 bit
program made errors when it concurrently processed huge files on network
drives. This was fixed by compiling with mingw-w64.

It seems that mingw-w64 development goes faster and it has surpassed
mingw.org. I'm afraid there is nothing mingw users can do, or they have
to help develop mingw. But isn't that a waste of effort to have two
almost the same compilers? I don't know the details, but as far as I
know the mingw/mingw-w64 fork did not happen in good understanding. So I
don't expect these two projects will join efforts.


--
Erwin

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
ml
Reply | Threaded
Open this post in threaded view
|

Re: problems with mingw support for Open Source projects

ml
In reply to this post by ml
Gisle Vanem wrote:
> It's kind of confusing situation, yes. I cannot advice much on making
> mingw.org more acceptable for projects. But the resentment toward
> old-school MingW is probably partly because of the somewhat confusing
> situation with how both projects define '__MINGW32__'?

I'm not seeing an issue with projects having trouble defining #ifdefs
between the two versions.  Projects have straight out told me they will
not support 2 Windows compilers.  They will only support the mingw64
project.  They refuse to take patches to make mingw (from mingw.org) work.
 Some of the projects have been downright nasty when I send patches to
them to add support for mingw (mingw.org version).

It's hard enough porting Open Source projects from other platforms to
Windows and getting them to build.  Having to worry about whether your
using an "accepted" Windows compiler for each particular project makes
matters even worse.

Would like to hear from others encountering this issue.  Please let me
know if you have any techniques for working around it.  Thanks.

I'm building several Open Source libraries and programs from source on
several platforms including Windows.  So far, when I run into a situation
like this, I've written the project off my list of projects to build and
looked for a more accomodating cross-platform project.

> The situation was frustrating for Mr Lavavej too. So he made his own very
> good MingW (x64 native) light-weight distro;
> [1]  http://nuwen.net/mingw.html
>
> So when I finally upgrade to Win8.1 (with a i7 CPU?), I will use his
> distro to target x64-native. And not the rather confusing distro from
> http://mingw-w64.sourceforge.net/.

Thanks for the information on this.  I'm personally still targeting 32 bit
even though I have a 64 bit platform to work with because some of my
machines still use 32 bit.  However, I know some people who are targeting
64 bit.

Sincerely,
Laura
http://www.distasis.com/cpp


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: problems with mingw support for Open Source projects

Eli Zaretskii
> Date: Sat, 15 Feb 2014 11:40:18 -0800 (PST)
> From: [hidden email]
>
> I'm not seeing an issue with projects having trouble defining #ifdefs
> between the two versions.  Projects have straight out told me they will
> not support 2 Windows compilers.  They will only support the mingw64
> project.  They refuse to take patches to make mingw (from mingw.org) work.
>  Some of the projects have been downright nasty when I send patches to
> them to add support for mingw (mingw.org version).
>
> It's hard enough porting Open Source projects from other platforms to
> Windows and getting them to build.  Having to worry about whether your
> using an "accepted" Windows compiler for each particular project makes
> matters even worse.
>
> Would like to hear from others encountering this issue.  Please let me
> know if you have any techniques for working around it.  Thanks.

My technique is very simple: if a project refuses to accept my
patches, I then ignore that project's maintainers, and provide my
binaries from my site (https://sourceforge.net/projects/ezwinports/).

I have never been told that my patches will not be accepted because I
use a "wrong" MinGW, but I was told more than once that
Windows-related patches are not very welcome.  I moved on, and I
suggest that you do, too.  Life is too short to worry about such
upstream maintainers.

So I suggest that you decide for yourself which MinGW you prefer, and
disregard anyone who tries to affect that decision by this kind of
"arguments".

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: problems with mingw support for Open Source projects

lrn-2
In reply to this post by ml
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 15.02.2014 23:40, [hidden email] wrote:

> Gisle Vanem wrote:
>> It's kind of confusing situation, yes. I cannot advice much on
>> making mingw.org more acceptable for projects. But the resentment
>> toward old-school MingW is probably partly because of the
>> somewhat confusing situation with how both projects define
>> '__MINGW32__'?
>
> I'm not seeing an issue with projects having trouble defining
> #ifdefs between the two versions.  Projects have straight out told
> me they will not support 2 Windows compilers.  They will only
> support the mingw64 project.  They refuse to take patches to make
> mingw (from mingw.org) work. Some of the projects have been
> downright nasty when I send patches to them to add support for
> mingw (mingw.org version).

I'm one of the "not support 2 Windows compilers" people. Whatever i
do, i aim at mingw-w64 compatibility. That said, i do tend to accept
(whenever i am the one making the decision, which isn't very often
really) mingw.org-compatibility patches, if they aren't intrusive.

>> The situation was frustrating for Mr Lavavej too. So he made his
>> own very good MingW (x64 native) light-weight distro; [1]
>> http://nuwen.net/mingw.html
>>
>> So when I finally upgrade to Win8.1 (with a i7 CPU?), I will use
>> his distro to target x64-native. And not the rather confusing
>> distro from http://mingw-w64.sourceforge.net/.
>
> Thanks for the information on this.  I'm personally still targeting
> 32 bit even though I have a 64 bit platform to work with because
> some of my machines still use 32 bit.  However, I know some people
> who are targeting 64 bit.

I'm still using i686 as well, though for other reasons (contrary to
popular belief, building correct x86_64 versions of software packages
requires more than changing the toolchain for an x86_64 one (and
changing compiler flags)).

I also maintain my own packages. That said, i don't see a reason to
distance myself from mingw-w64, since i tend to fix up their stuff
whenever needed, and i freely exchange patches with current mingw-w64
package maintainers. And i'm not sure what the "confusing distro" is
being referred to (this might be a reference to cross-compiler'y
layout of the toolchain OR to multilib toolchain - in which case i
agree, i prefer to stick to native toolchains).

- --
O< ascii ribbon - stop html email! - www.asciiribbon.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJS/9YYAAoJEOs4Jb6SI2Cw3hoH/j/F9x9J0zSWzxMQ9lpBj7S/
tE/I7teOixMLVcTdlwGa3rpvNBf+mYEnoHvF/oMce2p9TarwlL+qT2Y1f7fUTQss
n+loag/lhPDhjCxzm7yW4dhyB79eLIRGs5+EEolGuaIIIiCk4pCqbThC4nHzPjx6
bcM+M6LJWKWhc4RQzktoUi9CN0t2OkDzjrQj0dX9hJaRBqr9aOWTImJ6sMhQeI2S
81Ni8eSYRm6OYZbCujqxwNRjP217hFzGOsk5FfxCz+Len218q31h9Gi5bi4QF1Mz
Q1HgHhwE87u3GOCiXHLxiQMzdU4hZkjU8UErukgX07W1V00oseDVjvmbWkzj864=
=Wvq3
-----END PGP SIGNATURE-----

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe
Reply | Threaded
Open this post in threaded view
|

Re: problems with mingw support for Open Source projects

Johnathon Cotner
In reply to this post by ml
The mingw64 project can target both 32 bit and 64 bit windows. And in my eyes, and several others, it is the definitive cross platform compiler, as it can target both bit widths. While it may be true that on 64 bit systems some applications, if not all, when compiled for 32 bit run faster than their 64 bit counterpart, the reality of the matter is that all platforms are moving towards ubiquitous 64 bit widths. This is the reason your seeing a lot of projects supporting mingw64 in favor of mingw (as mingw64 was created due to mingw's refusal to support 64 bit). While it's tempting to write off a lot of open source projects simply because they do not support mingw, mingw64 is easily obtainable, reliable, and industry proven. And that, honestly, is also the reason for their enmity towards your patches, as they would target mingw if they wanted to.


On Sat, Feb 15, 2014 at 1:40 PM, <[hidden email]> wrote:
Gisle Vanem wrote:
> It's kind of confusing situation, yes. I cannot advice much on making
> mingw.org more acceptable for projects. But the resentment toward
> old-school MingW is probably partly because of the somewhat confusing
> situation with how both projects define '__MINGW32__'?

I'm not seeing an issue with projects having trouble defining #ifdefs
between the two versions.  Projects have straight out told me they will
not support 2 Windows compilers.  They will only support the mingw64
project.  They refuse to take patches to make mingw (from mingw.org) work.
 Some of the projects have been downright nasty when I send patches to
them to add support for mingw (mingw.org version).

It's hard enough porting Open Source projects from other platforms to
Windows and getting them to build.  Having to worry about whether your
using an "accepted" Windows compiler for each particular project makes
matters even worse.

Would like to hear from others encountering this issue.  Please let me
know if you have any techniques for working around it.  Thanks.

I'm building several Open Source libraries and programs from source on
several platforms including Windows.  So far, when I run into a situation
like this, I've written the project off my list of projects to build and
looked for a more accomodating cross-platform project.

> The situation was frustrating for Mr Lavavej too. So he made his own very
> good MingW (x64 native) light-weight distro;
> [1]  http://nuwen.net/mingw.html
>
> So when I finally upgrade to Win8.1 (with a i7 CPU?), I will use his
> distro to target x64-native. And not the rather confusing distro from
> http://mingw-w64.sourceforge.net/.

Thanks for the information on this.  I'm personally still targeting 32 bit
even though I have a 64 bit platform to work with because some of my
machines still use 32 bit.  However, I know some people who are targeting
64 bit.

Sincerely,
Laura
http://www.distasis.com/cpp


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe



--
¯`°²º¤æ=.KD.=椺²°`¯

------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
MinGW-users mailing list
[hidden email]

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:[hidden email]?subject=unsubscribe