Thread: Re: [Mingw-users] 64-bit MinGW | MinGW (original) (raw)

Summary
Files
Reviews
Support
News
Mailing Lists
Tickets ▾
Git ▾
- catgets
- lpr-enhanced
- mingw-get
- mingw-get-inst
- mingw-org-wsl
- msys-runtime
- msys2-runtime
- ports
- utils
- More...

From: Romain G. <dar...@do...> - 2014-05-03 10:39:43
Hi ! It is clear that this kind of attitude should not exist. However, it is always sad to miss an important features, especially when the cause is an issue between developpers, rather than a techinal issue. I think copyright infringment is somewhat a pretext in order not to do anything. When I download a software (either free or not), I can not be sure that this software is actually not infringing anyone's copyright (unless I read the entire source, and I allmost never do that, even for works I modify), so for me, it work like a giant web of trust. I'm also sceptic about the fact that microsoft would like to sink MinGW, because it's one of the most widely used compilers for windows... However, I'll confess I'm not really aware of consequences of copyright infringment, for instance, I don't really now to what extent I could be considered liable for contributing to a copyright-infringing project, or for using it. Because I'm french, and in france, we use "droits d'auteurs" laws that are slightly different of copyright laws (making some licenses totally unlawful btw). If anyone is anyone can shed some light on this, it would probably help me. The real problem is Mingw-w64, is undocumented to such a extent that it is really hard to get something working the right way, not because it is hard to use or build, but because you actually don't know what to do ! A couple of months ago, I decided to try it, but that so fucking hard that I ended up downloading the x64 version of tdm-gcc. It was far better than what you can get on mingw-w64 site. But you still need to build manually lot of tools (at least libcharset, libiconv, and libintl for me), and this really anoying. I haven't experienced a bug yet though. I think that allmost things wrong about mingw-w64 are the lack of documentation and stable releases. Regards Romain Keith Marshall <kei...@us...> wrote: On 03/05/14 03:56, Nathan Ridge wrote: > So why not look at the patches that were offered, and arrive at a > conclusion about their copyright infringement or lack thereof, on > their merits, rather than saying things like "we must surely conclude > that his project has a carelessly cavalier attitude to this"? Because, at the time he just threw a huge tarball of all his headers at us; he never broke it down into patches. When politely asked to do so, he just ran off in a sulk, an the next thing we knew, the fork appeared. -- Regards, Keith. ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ 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: Romain G. <dar...@do...> - 2014-05-03 10:39:43

Hi ! It is clear that this kind of attitude should not exist. However, it is always sad to miss an important features, especially when the cause is an issue between developpers, rather than a techinal issue. I think copyright infringment is somewhat a pretext in order not to do anything. When I download a software (either free or not), I can not be sure that this software is actually not infringing anyone's copyright (unless I read the entire source, and I allmost never do that, even for works I modify), so for me, it work like a giant web of trust. I'm also sceptic about the fact that microsoft would like to sink MinGW, because it's one of the most widely used compilers for windows... However, I'll confess I'm not really aware of consequences of copyright infringment, for instance, I don't really now to what extent I could be considered liable for contributing to a copyright-infringing project, or for using it. Because I'm french, and in france, we use "droits d'auteurs" laws that are slightly different of copyright laws (making some licenses totally unlawful btw). If anyone is anyone can shed some light on this, it would probably help me. The real problem is Mingw-w64, is undocumented to such a extent that it is really hard to get something working the right way, not because it is hard to use or build, but because you actually don't know what to do ! A couple of months ago, I decided to try it, but that so fucking hard that I ended up downloading the x64 version of tdm-gcc. It was far better than what you can get on mingw-w64 site. But you still need to build manually lot of tools (at least libcharset, libiconv, and libintl for me), and this really anoying. I haven't experienced a bug yet though. I think that allmost things wrong about mingw-w64 are the lack of documentation and stable releases. Regards Romain Keith Marshall <kei...@us...> wrote: On 03/05/14 03:56, Nathan Ridge wrote: > So why not look at the patches that were offered, and arrive at a > conclusion about their copyright infringement or lack thereof, on > their merits, rather than saying things like "we must surely conclude > that his project has a carelessly cavalier attitude to this"? Because, at the time he just threw a huge tarball of all his headers at us; he never broke it down into patches. When politely asked to do so, he just ran off in a sulk, an the next thing we knew, the fork appeared. -- Regards, Keith. ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ 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: Romain G. <dar...@do...> - 2014-05-03 14:29:23
Ok, you're right about lawsuits. Never though that so little things could have such consequences (I'm talking about tz lawsuit, don't think I say "copyright infringment is just a little problem"). However, I can't agree when people say the actual problem with mingw-w64 hypothetical copyright infringment. It is clearly not. The problem is dissagreements between devellopers. If the only problem was this, it would have been solved for years, only by examining sources, and licenses, and we would have a unique compiler supporting both x64 and x86. Instead, we have two compilers : mingw, a user-friendly compiler that supports only x86, and mingw-w64, an incredibly user-unfriendly compiler that supports x64, so what's gone wrong ? :-) I know it is easy to say that when you're not involved in the dissagreement, but the problem is that probably nobody attempted to merge mingw-w64 back. Regards KHMan <kei...@gm...> wrote: On 5/3/2014 6:39 PM, Romain Garbi wrote: > It is clear that this kind of attitude should not exist. However, > it is always sad to miss an important features, especially when > the cause is an issue between developpers, rather than a techinal > issue. A long time list member here. MinGW has always required public documentation for API patches, I've seen many people making such contributions with no fuss at all, no problem at all. It is an important legal issue, well worth the extra effort IMHO. If younger fellas want to be cavalier about their legal position, then let them take on the increased risk of a lawsuit. If they choose to interpret copyright law in a way very favourably to themselves and in a non-US setting, then let them take the risk. > I think copyright infringment is somewhat a pretext in order not > to do anything. When I download a software (either free or not), I > can not be sure that this software is actually not infringing > anyone's copyright (unless I read the entire source, and I allmost > never do that, even for works I modify), so for me, it work like a > giant web of trust. I'm also sceptic about the fact that microsoft > would like to sink MinGW, because it's one of the most widely used > compilers for windows... You'd better learn more about copyright law before writing such things. In large corporations, the left hand knows not what the right hand is doing. Lawyers are not developers, they won't know the ecosystem benefits MinGW bring to Win32. An attack dog wanting to stand out in a horde of attack dogs might strike at MinGW as a career-making move, however bad it may look to the developer community (lawyers might follow the old adage of "asking for forgiveness is easier than asking for permission" too.) One frivolous lawsuit even if it's later dismissed, can easily ruin many lives. Remember the timezone database lawsuit? Go read about it. Plenty more examples of out-of-the-blue lawsuits to choose from... Do you think it's fun if it happened to you? So I must agree with the MinGW team on their procedures to minimize legal risk. I would not want the MinGW project to drop all the hard work done over the years and going to a cavalier mode. If the other forks want to take on increased risk, let them since it's the path they have chosen, but for me I think there will still be the original MinGW to fall back on. > [snip snip] -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ 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: Romain G. <dar...@do...> - 2014-05-03 14:29:23

Ok, you're right about lawsuits. Never though that so little things could have such consequences (I'm talking about tz lawsuit, don't think I say "copyright infringment is just a little problem"). However, I can't agree when people say the actual problem with mingw-w64 hypothetical copyright infringment. It is clearly not. The problem is dissagreements between devellopers. If the only problem was this, it would have been solved for years, only by examining sources, and licenses, and we would have a unique compiler supporting both x64 and x86. Instead, we have two compilers : mingw, a user-friendly compiler that supports only x86, and mingw-w64, an incredibly user-unfriendly compiler that supports x64, so what's gone wrong ? :-) I know it is easy to say that when you're not involved in the dissagreement, but the problem is that probably nobody attempted to merge mingw-w64 back. Regards KHMan <kei...@gm...> wrote: On 5/3/2014 6:39 PM, Romain Garbi wrote: > It is clear that this kind of attitude should not exist. However, > it is always sad to miss an important features, especially when > the cause is an issue between developpers, rather than a techinal > issue. A long time list member here. MinGW has always required public documentation for API patches, I've seen many people making such contributions with no fuss at all, no problem at all. It is an important legal issue, well worth the extra effort IMHO. If younger fellas want to be cavalier about their legal position, then let them take on the increased risk of a lawsuit. If they choose to interpret copyright law in a way very favourably to themselves and in a non-US setting, then let them take the risk. > I think copyright infringment is somewhat a pretext in order not > to do anything. When I download a software (either free or not), I > can not be sure that this software is actually not infringing > anyone's copyright (unless I read the entire source, and I allmost > never do that, even for works I modify), so for me, it work like a > giant web of trust. I'm also sceptic about the fact that microsoft > would like to sink MinGW, because it's one of the most widely used > compilers for windows... You'd better learn more about copyright law before writing such things. In large corporations, the left hand knows not what the right hand is doing. Lawyers are not developers, they won't know the ecosystem benefits MinGW bring to Win32. An attack dog wanting to stand out in a horde of attack dogs might strike at MinGW as a career-making move, however bad it may look to the developer community (lawyers might follow the old adage of "asking for forgiveness is easier than asking for permission" too.) One frivolous lawsuit even if it's later dismissed, can easily ruin many lives. Remember the timezone database lawsuit? Go read about it. Plenty more examples of out-of-the-blue lawsuits to choose from... Do you think it's fun if it happened to you? So I must agree with the MinGW team on their procedures to minimize legal risk. I would not want the MinGW project to drop all the hard work done over the years and going to a cavalier mode. If the other forks want to take on increased risk, let them since it's the path they have chosen, but for me I think there will still be the original MinGW to fall back on. > [snip snip] -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia ------------------------------------------------------------------------------ "Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE Instantly run your Selenium tests across 300+ browser/OS combos. Get unparalleled scalability from the best Selenium testing platform available. Simple to use. Nothing to install. Get started now for free." http://p.sf.net/sfu/SauceLabs _______________________________________________ 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: <ml...@di...> - 2014-05-04 13:29:26
I'll just throw in my two cents. Was recently reading through header files for MinGW, MinGW-64 and Wine. Was trying to get some software that needs DirectX working properly. There wasn't enough information in MinGW itself to get it to compile, but I didn't want to extend the headers unless I could find publicly documented materials to back up any changes. Keith Marshall wrote: >Any patch which was not developed on the basis of examination of freely available (e.g. MSDN) documentation, and in > particular any patch derived from examination of MS PDK headers, (or worse still copied verbatim from any such headers), or even by reverse > engineering of any MS PDK, has always been rejected by MinGW.org. >From the parts of the header files I was examining, I'd have to say this was very much the case. I did not see any material in the header files I looked at that did not come from public documentation. A lot of it is from the public documentation on the Microsoft site. The MinGW project even went so far as to track down public RFCs that provided more information. I think they've done a good job with what little information they have. >That may be so, but your suggested examination or reverse engineering methodology is not acceptable to MinGW.org; MinGW-W64 seem to be less > careful in this respect. There's some correlation between the Wine and MinGW-64 headers (at least with regards to DirectX). I have been unable to track down where either project got certain information found in those headers (unless possibly they reverse engineered or looked at the official headers). I would really like to see some documentation on where they did get certain pieces of information that are in their header files. Would be nice to see that information added to the MinGW project if it is public information. One last consideration I'd like to throw in, as per Oracle America, Inc. v. Google, Inc ( http://en.wikipedia.org/wiki/Oracle_v._Google ) as decided in the United States District Court for the Northern District of California, APIs are not copyrightable. This has already been through the courts. If it continues to hold up, borrowing from others' header files if it's API related only may be perfectly fine. There is precedence for it. I really don't have a decent test machine for a 64 bit version of MinGW, so I can't test this myself at this time. However, I can't help wondering, if the current MinGW compiler is built targeting 64 bit rather than 32 bit, just how far is it from working properly? The MinGW32 project changed its name to MinGW several years ago to emphasize it wasn't just going to be for 32 bit systems. Would be nice to look into just what would it take to make 64 bit support a reality with what MinGW has to offer now as a starting point. Sincerely, Laura http://www.distasis.com/cpp/mingw.htm

From: <ml...@di...> - 2014-05-04 13:29:26

I'll just throw in my two cents. Was recently reading through header files for MinGW, MinGW-64 and Wine. Was trying to get some software that needs DirectX working properly. There wasn't enough information in MinGW itself to get it to compile, but I didn't want to extend the headers unless I could find publicly documented materials to back up any changes. Keith Marshall wrote: >Any patch which was not developed on the basis of examination of freely available (e.g. MSDN) documentation, and in > particular any patch derived from examination of MS PDK headers, (or worse still copied verbatim from any such headers), or even by reverse > engineering of any MS PDK, has always been rejected by MinGW.org. >From the parts of the header files I was examining, I'd have to say this was very much the case. I did not see any material in the header files I looked at that did not come from public documentation. A lot of it is from the public documentation on the Microsoft site. The MinGW project even went so far as to track down public RFCs that provided more information. I think they've done a good job with what little information they have. >That may be so, but your suggested examination or reverse engineering methodology is *not* acceptable to MinGW.org; MinGW-W64 seem to be less > careful in this respect. There's some correlation between the Wine and MinGW-64 headers (at least with regards to DirectX). I have been unable to track down where either project got certain information found in those headers (unless possibly they reverse engineered or looked at the official headers). I would really like to see some documentation on where they did get certain pieces of information that are in their header files. Would be nice to see that information added to the MinGW project if it is public information. One last consideration I'd like to throw in, as per Oracle America, Inc. v. Google, Inc ( http://en.wikipedia.org/wiki/Oracle_v._Google ) as decided in the United States District Court for the Northern District of California, APIs are not copyrightable. This has already been through the courts. If it continues to hold up, borrowing from others' header files if it's API related only may be perfectly fine. There is precedence for it. I really don't have a decent test machine for a 64 bit version of MinGW, so I can't test this myself at this time. However, I can't help wondering, if the current MinGW compiler is built targeting 64 bit rather than 32 bit, just how far is it from working properly? The MinGW32 project changed its name to MinGW several years ago to emphasize it wasn't just going to be for 32 bit systems. Would be nice to look into just what would it take to make 64 bit support a reality with what MinGW has to offer now as a starting point. Sincerely, Laura http://www.distasis.com/cpp/mingw.htm

From: Tony T. <ton...@gm...> - 2014-05-04 14:48:34
On 4 May 2014, at 23:09, ml...@di... wrote: > > I really don't have a decent test machine for a 64 bit version of MinGW, > so I can't test this myself at this time. However, I can't help > wondering, if the current MinGW compiler is built targeting 64 bit rather > than 32 bit, just how far is it from working properly? I think I recall reading that the wsl-4 branch had initial 64-bit support but haven't actually tested it yet - that branch seems to be on hold for the time being[1]. Cheers, Tony [1] http://sourceforge.net/p/mingw/bugs/2202/#fc56

From: Tony T. <ton...@gm...> - 2014-05-04 14:48:34

On 4 May 2014, at 23:09, ml...@di... wrote: > > I really don't have a decent test machine for a 64 bit version of MinGW, > so I can't test this myself at this time. However, I can't help > wondering, if the current MinGW compiler is built targeting 64 bit rather > than 32 bit, just how far is it from working properly? I think I recall reading that the wsl-4 branch had initial 64-bit support but haven't actually tested it yet - that branch seems to be on hold for the time being[1]. Cheers, Tony [1] http://sourceforge.net/p/mingw/bugs/2202/#fc56

From: Eli Z. <el...@gn...> - 2014-05-04 17:17:38
> Date: Sun, 4 May 2014 06:09:25 -0700 (PDT) > From: ml...@di... > > One last consideration I'd like to throw in, as per Oracle America, Inc. > v. Google, Inc ( http://en.wikipedia.org/wiki/Oracle_v._Google ) as > decided in the United States District Court for the Northern District of > California, APIs are not copyrightable. This has already been through > the courts. If it continues to hold up, borrowing from others' header > files if it's API related only may be perfectly fine. There is precedence > for it. This ruling is indeed good news, but (a) it is still a matter of continued litigation, as that article describes, so the ruling can still be reversed by a higher court (I hope it won't); and (b) header files are not just documentation of the APIs, they include some code as well. So even if APIs are not copyrightable (which is still not 100% clear), you cannot freely copy MS headers, especially since they include explicit copyright notices by MS.

From: Eli Z. <el...@gn...> - 2014-05-04 17:17:38

> Date: Sun, 4 May 2014 06:09:25 -0700 (PDT) > From: ml...@di... > > One last consideration I'd like to throw in, as per Oracle America, Inc. > v. Google, Inc ( http://en.wikipedia.org/wiki/Oracle_v._Google ) as > decided in the United States District Court for the Northern District of > California, APIs are not copyrightable. This has already been through > the courts. If it continues to hold up, borrowing from others' header > files if it's API related only may be perfectly fine. There is precedence > for it. This ruling is indeed good news, but (a) it is still a matter of continued litigation, as that article describes, so the ruling can still be reversed by a higher court (I hope it won't); and (b) header files are not just documentation of the APIs, they include some code as well. So even if APIs are not copyrightable (which is still not 100% clear), you cannot freely copy MS headers, especially since they include explicit copyright notices by MS.

From: Erwin W. <wat...@xs...> - 2014-05-06 16:35:30
Op 4-5-2014 19:17, Eli Zaretskii schreef: >> Date: Sun, 4 May 2014 06:09:25 -0700 (PDT) >> From: ml...@di... >> >> One last consideration I'd like to throw in, as per Oracle America, Inc. >> v. Google, Inc ( http://en.wikipedia.org/wiki/Oracle_v._Google ) as >> decided in the United States District Court for the Northern District of >> California, APIs are not copyrightable. This has already been through >> the courts. If it continues to hold up, borrowing from others' header >> files if it's API related only may be perfectly fine. There is precedence >> for it. > This ruling is indeed good news, but (a) it is still a matter of > continued litigation, as that article describes, so the ruling can > still be reversed by a higher court (I hope it won't); and (b) header > files are not just documentation of the APIs, they include some code > as well. So even if APIs are not copyrightable (which is still not > 100% clear), you cannot freely copy MS headers, especially since they > include explicit copyright notices by MS. > Hi, I don't think that mingw needs to be "holier than the pope" as we say in The Netherlands. What would Microsoft gain if they would chase away mingw from Windows? Sell a few more VC licenses... If you look at all the computing devices together then Windows is loosing ground big time. PC sales are going down and on the mobile devices Android and iOS rule. So I think that Windows needs all the developers it can get, even if they don't use MS tooling. I would not develop for Windows if I had to pay for the compiler. Forcing hobbyists and professionals to use VC would make the Windows target only more unpopular. All commercial C compilers for Windows have already given up. The few freeware compilers that remain are not a threat to MS VC. VC is THE compiler for Windows. I think it is unlikely that this will change in the near future. The mingw organisation is not a multi-million dollar company. "You can't pluck a bald chicken" (Dutch saying). Mingw has no money, so why would they start a costly court case which would bring them no money and would make them only more unpopular. The trend is actually that big companies support free compilers and other free software. See Apple's contribution to LLVM (clang). By investing in it they also get a lot of code and goodwill in return. regards, Erwin

From: Erwin W. <wat...@xs...> - 2014-05-06 16:35:30

Op 4-5-2014 19:17, Eli Zaretskii schreef: >> Date: Sun, 4 May 2014 06:09:25 -0700 (PDT) >> From: ml...@di... >> >> One last consideration I'd like to throw in, as per Oracle America, Inc. >> v. Google, Inc ( http://en.wikipedia.org/wiki/Oracle_v._Google ) as >> decided in the United States District Court for the Northern District of >> California, APIs are not copyrightable. This has already been through >> the courts. If it continues to hold up, borrowing from others' header >> files if it's API related only may be perfectly fine. There is precedence >> for it. > This ruling is indeed good news, but (a) it is still a matter of > continued litigation, as that article describes, so the ruling can > still be reversed by a higher court (I hope it won't); and (b) header > files are not just documentation of the APIs, they include some code > as well. So even if APIs are not copyrightable (which is still not > 100% clear), you cannot freely copy MS headers, especially since they > include explicit copyright notices by MS. > Hi, I don't think that mingw needs to be "holier than the pope" as we say in The Netherlands. What would Microsoft gain if they would chase away mingw from Windows? Sell a few more VC licenses... If you look at all the computing devices together then Windows is loosing ground big time. PC sales are going down and on the mobile devices Android and iOS rule. So I think that Windows needs all the developers it can get, even if they don't use MS tooling. I would not develop for Windows if I had to pay for the compiler. Forcing hobbyists and professionals to use VC would make the Windows target only more unpopular. All commercial C compilers for Windows have already given up. The few freeware compilers that remain are not a threat to MS VC. VC is THE compiler for Windows. I think it is unlikely that this will change in the near future. The mingw organisation is not a multi-million dollar company. "You can't pluck a bald chicken" (Dutch saying). Mingw has no money, so why would they start a costly court case which would bring them no money and would make them only more unpopular. The trend is actually that big companies support free compilers and other free software. See Apple's contribution to LLVM (clang). By investing in it they also get a lot of code and goodwill in return. regards, Erwin

From: KHMan <kei...@gm...> - 2014-05-06 17:16:01
On 5/7/2014 12:35 AM, Erwin Waterlander wrote: > Op 4-5-2014 19:17, Eli Zaretskii schreef: >>> Date: Sun, 4 May 2014 06:09:25 -0700 (PDT) >>> From: ml...@di... >>> >>> One last consideration I'd like to throw in, as per Oracle America, Inc. >>> v. Google, Inc ( http://en.wikipedia.org/wiki/Oracle_v._Google ) as >>> decided in the United States District Court for the Northern District of >>> California, APIs are not copyrightable. This has already been through >>> the courts. If it continues to hold up, borrowing from others' header >>> files if it's API related only may be perfectly fine. There is precedence >>> for it. >> This ruling is indeed good news, but (a) it is still a matter of >> continued litigation, as that article describes, so the ruling can >> still be reversed by a higher court (I hope it won't); and (b) header >> files are not just documentation of the APIs, they include some code >> as well. So even if APIs are not copyrightable (which is still not >> 100% clear), you cannot freely copy MS headers, especially since they >> include explicit copyright notices by MS. >> >[snip] > All commercial C compilers for Windows have already given up. The few > freeware compilers that remain are not a threat to MS VC. VC is THE > compiler for Windows. I think it is unlikely that this will change in > the near future. > The mingw organisation is not a multi-million dollar company. "You can't > pluck a bald chicken" (Dutch saying). Mingw has no money, so why would > they start a costly court case which would bring them no money and would > make them only more unpopular. Easy for us end users to talk of dismissing risk. Would you do the same as a US developer with a family? I think the position of both projects is clear. I believe no one is going to change their positions however unlikely the threat from Microsoft. That said, all of Microsoft's header files are copyrighted, slurping too much and too long from them might be unwise in certain countries. > The trend is actually that big companies support free compilers and > other free software. See Apple's contribution to LLVM (clang). By > investing in it they also get a lot of code and goodwill in return. Perhaps cooperation is not out of the question, look at Samba these days. Look, why don't someone ping Satya Nadella and ask him to get the compiler team to update their API documentation, then MinGW can get all the info they need... -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia

From: KHMan <kei...@gm...> - 2014-05-06 17:16:01

On 5/7/2014 12:35 AM, Erwin Waterlander wrote: > Op 4-5-2014 19:17, Eli Zaretskii schreef: >>> Date: Sun, 4 May 2014 06:09:25 -0700 (PDT) >>> From: ml...@di... >>> >>> One last consideration I'd like to throw in, as per Oracle America, Inc. >>> v. Google, Inc ( http://en.wikipedia.org/wiki/Oracle_v._Google ) as >>> decided in the United States District Court for the Northern District of >>> California, APIs are not copyrightable. This has already been through >>> the courts. If it continues to hold up, borrowing from others' header >>> files if it's API related only may be perfectly fine. There is precedence >>> for it. >> This ruling is indeed good news, but (a) it is still a matter of >> continued litigation, as that article describes, so the ruling can >> still be reversed by a higher court (I hope it won't); and (b) header >> files are not just documentation of the APIs, they include some code >> as well. So even if APIs are not copyrightable (which is still not >> 100% clear), you cannot freely copy MS headers, especially since they >> include explicit copyright notices by MS. >> >[snip] > All commercial C compilers for Windows have already given up. The few > freeware compilers that remain are not a threat to MS VC. VC is THE > compiler for Windows. I think it is unlikely that this will change in > the near future. > The mingw organisation is not a multi-million dollar company. "You can't > pluck a bald chicken" (Dutch saying). Mingw has no money, so why would > they start a costly court case which would bring them no money and would > make them only more unpopular. Easy for us end users to talk of dismissing risk. Would you do the same as a US developer with a family? I think the position of both projects is clear. I believe no one is going to change their positions however unlikely the threat from Microsoft. That said, all of Microsoft's header files are copyrighted, slurping too much and too long from them might be unwise in certain countries. > The trend is actually that big companies support free compilers and > other free software. See Apple's contribution to LLVM (clang). By > investing in it they also get a lot of code and goodwill in return. Perhaps cooperation is not out of the question, look at Samba these days. Look, why don't someone ping Satya Nadella and ask him to get the compiler team to update their API documentation, then MinGW can get all the info they need... -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia

From: David G. <jdg...@ho...> - 2014-05-06 17:22:30
> Date: Tue, 6 May 2014 18:35:10 +0200 > From: wat...@xs... > To: min...@li... > Subject: Re: [Mingw-users] 64-bit MinGW > > Op 4-5-2014 19:17, Eli Zaretskii schreef: > >> Date: Sun, 4 May 2014 06:09:25 -0700 (PDT) > >> From: ml...@di... > >> > >> One last consideration I'd like to throw in, as per Oracle America, Inc. > >> v. Google, Inc ( http://en.wikipedia.org/wiki/Oracle_v._Google ) as > >> decided in the United States District Court for the Northern District of > >> California, APIs are not copyrightable. This has already been through > >> the courts. If it continues to hold up, borrowing from others' header > >> files if it's API related only may be perfectly fine. There is precedence > >> for it. > > This ruling is indeed good news, but (a) it is still a matter of > > continued litigation, as that article describes, so the ruling can > > still be reversed by a higher court (I hope it won't); and (b) header > > files are not just documentation of the APIs, they include some code > > as well. So even if APIs are not copyrightable (which is still not > > 100% clear), you cannot freely copy MS headers, especially since they > > include explicit copyright notices by MS. > > > Hi, > > I don't think that mingw needs to be "holier than the pope" as we say in > The Netherlands. What would Microsoft gain if they would chase away > mingw from Windows? Sell a few more VC licenses... If you look at all > the computing devices together then Windows is loosing ground big time. > PC sales are going down and on the mobile devices Android and iOS rule. > So I think that Windows needs all the developers it can get, even if > they don't use MS tooling. I would not develop for Windows if I had to > pay for the compiler. Forcing hobbyists and professionals to use VC > would make the Windows target only more unpopular. > All commercial C compilers for Windows have already given up. The few > freeware compilers that remain are not a threat to MS VC. VC is THE > compiler for Windows. I think it is unlikely that this will change in > the near future. > The mingw organisation is not a multi-million dollar company. "You can't > pluck a bald chicken" (Dutch saying). Mingw has no money, so why would > they start a costly court case which would bring them no money and would > make them only more unpopular. > The trend is actually that big companies support free compilers and > other free software. See Apple's contribution to LLVM (clang). By > investing in it they also get a lot of code and goodwill in return. > > regards, > Erwin The simplest way to deal with this would be to request Microsoft to explicitly fill in the gaps where people are making assumptions about what Microsoft will or will not do.

From: David G. <jdg...@ho...> - 2014-05-06 17:22:30

> Date: Tue, 6 May 2014 18:35:10 +0200 > From: wat...@xs... > To: min...@li... > Subject: Re: [Mingw-users] 64-bit MinGW > > Op 4-5-2014 19:17, Eli Zaretskii schreef: > >> Date: Sun, 4 May 2014 06:09:25 -0700 (PDT) > >> From: ml...@di... > >> > >> One last consideration I'd like to throw in, as per Oracle America, Inc. > >> v. Google, Inc ( http://en.wikipedia.org/wiki/Oracle_v._Google ) as > >> decided in the United States District Court for the Northern District of > >> California, APIs are not copyrightable. This has already been through > >> the courts. If it continues to hold up, borrowing from others' header > >> files if it's API related only may be perfectly fine. There is precedence > >> for it. > > This ruling is indeed good news, but (a) it is still a matter of > > continued litigation, as that article describes, so the ruling can > > still be reversed by a higher court (I hope it won't); and (b) header > > files are not just documentation of the APIs, they include some code > > as well. So even if APIs are not copyrightable (which is still not > > 100% clear), you cannot freely copy MS headers, especially since they > > include explicit copyright notices by MS. > > > Hi, > > I don't think that mingw needs to be "holier than the pope" as we say in > The Netherlands. What would Microsoft gain if they would chase away > mingw from Windows? Sell a few more VC licenses... If you look at all > the computing devices together then Windows is loosing ground big time. > PC sales are going down and on the mobile devices Android and iOS rule. > So I think that Windows needs all the developers it can get, even if > they don't use MS tooling. I would not develop for Windows if I had to > pay for the compiler. Forcing hobbyists and professionals to use VC > would make the Windows target only more unpopular. > All commercial C compilers for Windows have already given up. The few > freeware compilers that remain are not a threat to MS VC. VC is THE > compiler for Windows. I think it is unlikely that this will change in > the near future. > The mingw organisation is not a multi-million dollar company. "You can't > pluck a bald chicken" (Dutch saying). Mingw has no money, so why would > they start a costly court case which would bring them no money and would > make them only more unpopular. > The trend is actually that big companies support free compilers and > other free software. See Apple's contribution to LLVM (clang). By > investing in it they also get a lot of code and goodwill in return. > > regards, > Erwin The simplest way to deal with this would be to request Microsoft to explicitly fill in the gaps where people are making assumptions about what Microsoft will or will not do.

From: Kirk J. <kir...@gm...> - 2014-05-06 18:45:04
> What would Microsoft gain if they would chase away mingw from Windows? If mingw has a policy to remain bullet-proof against possible legal action then guessing the mind of the party which might bring that action is missing the point. > The mingw organisation is not a multi-million dollar company. "You can't > pluck a bald chicken" (Dutch saying). False. Innocuous, free, and small projects posing no significant economic threat get taken down and their developers sued. The dollar amount doesn't even matter: you are going to settle for a fee that's so small it can't possibly matter to the company suing you. The real problem problem for you is that you will have to pay a lawyer and waste enormous amounts of time. Not too long ago the Cockatrice project (a small online card gaming program) was taken down and its developer sued. Users of the program argued that they used it to test the value of various cards before buying them through a paid gaming service offered by the company the brought the legal action. Apparently the company did not agree with this logic. Arguments similar to those you are making about mingw enlarging the Windows user base could be made for the incident I described in the previous paragraph. My _guess_ is that the company did this to prevent legal precedent in which their copyright was not protected. Anyway, my point is, it is not only beside the point to guess about what legal action Microsoft might take against mingw, it is also potentially ruinous. On Tue, May 6, 2014 at 10:22 AM, David Gressett <jdg...@ho...> wrote: > > >> Date: Tue, 6 May 2014 18:35:10 +0200 >> From: wat...@xs... >> To: min...@li... >> Subject: Re: [Mingw-users] 64-bit MinGW > >> >> Op 4-5-2014 19:17, Eli Zaretskii schreef: >> >> Date: Sun, 4 May 2014 06:09:25 -0700 (PDT) >> >> From: ml...@di... >> >> >> >> One last consideration I'd like to throw in, as per Oracle America, >> >> Inc. >> >> v. Google, Inc ( http://en.wikipedia.org/wiki/Oracle_v._Google ) as >> >> decided in the United States District Court for the Northern District >> >> of >> >> California, APIs are not copyrightable. This has already been through >> >> the courts. If it continues to hold up, borrowing from others' header >> >> files if it's API related only may be perfectly fine. There is >> >> precedence >> >> for it. >> > This ruling is indeed good news, but (a) it is still a matter of >> > continued litigation, as that article describes, so the ruling can >> > still be reversed by a higher court (I hope it won't); and (b) header >> > files are not just documentation of the APIs, they include some code >> > as well. So even if APIs are not copyrightable (which is still not >> > 100% clear), you cannot freely copy MS headers, especially since they >> > include explicit copyright notices by MS. >> > >> Hi, >> >> I don't think that mingw needs to be "holier than the pope" as we say in >> The Netherlands. What would Microsoft gain if they would chase away >> mingw from Windows? Sell a few more VC licenses... If you look at all >> the computing devices together then Windows is loosing ground big time. >> PC sales are going down and on the mobile devices Android and iOS rule. >> So I think that Windows needs all the developers it can get, even if >> they don't use MS tooling. I would not develop for Windows if I had to >> pay for the compiler. Forcing hobbyists and professionals to use VC >> would make the Windows target only more unpopular. >> All commercial C compilers for Windows have already given up. The few >> freeware compilers that remain are not a threat to MS VC. VC is THE >> compiler for Windows. I think it is unlikely that this will change in >> the near future. >> The mingw organisation is not a multi-million dollar company. "You can't >> pluck a bald chicken" (Dutch saying). Mingw has no money, so why would >> they start a costly court case which would bring them no money and would >> make them only more unpopular. >> The trend is actually that big companies support free compilers and >> other free software. See Apple's contribution to LLVM (clang). By >> investing in it they also get a lot of code and goodwill in return. >> >> regards, >> Erwin > > The simplest way to deal with this would be to request Microsoft to > explicitly fill in the gaps where people are making assumptions about what > Microsoft will or will not do. > > ------------------------------------------------------------------------------ > Is your legacy SCM system holding you back? Join Perforce May 7 to find out: > 3 signs your SCM is hindering your productivity > Requirements for releasing software faster > Expert tips and advice for migrating your SCM now > http://p.sf.net/sfu/perforce > _______________________________________________ > 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: Kirk J. <kir...@gm...> - 2014-05-06 18:45:04

> What would Microsoft gain if they would chase away mingw from Windows? If mingw has a policy to remain bullet-proof against possible legal action then guessing the mind of the party which might bring that action is missing the point. > The mingw organisation is not a multi-million dollar company. "You can't > pluck a bald chicken" (Dutch saying). False. Innocuous, free, and small projects posing no significant economic threat get taken down and their developers sued. The dollar amount doesn't even matter: you are going to settle for a fee that's so small it can't possibly matter to the company suing you. The real problem problem for you is that you will have to pay a lawyer and waste enormous amounts of time. Not too long ago the Cockatrice project (a small online card gaming program) was taken down and its developer sued. Users of the program argued that they used it to test the value of various cards before buying them through a paid gaming service offered by the company the brought the legal action. Apparently the company did not agree with this logic. Arguments similar to those you are making about mingw enlarging the Windows user base could be made for the incident I described in the previous paragraph. My _guess_ is that the company did this to prevent legal precedent in which their copyright was not protected. Anyway, my point is, it is not only beside the point to guess about what legal action Microsoft might take against mingw, it is also potentially ruinous. On Tue, May 6, 2014 at 10:22 AM, David Gressett <jdg...@ho...> wrote: > > >> Date: Tue, 6 May 2014 18:35:10 +0200 >> From: wat...@xs... >> To: min...@li... >> Subject: Re: [Mingw-users] 64-bit MinGW > >> >> Op 4-5-2014 19:17, Eli Zaretskii schreef: >> >> Date: Sun, 4 May 2014 06:09:25 -0700 (PDT) >> >> From: ml...@di... >> >> >> >> One last consideration I'd like to throw in, as per Oracle America, >> >> Inc. >> >> v. Google, Inc ( http://en.wikipedia.org/wiki/Oracle_v._Google ) as >> >> decided in the United States District Court for the Northern District >> >> of >> >> California, APIs are not copyrightable. This has already been through >> >> the courts. If it continues to hold up, borrowing from others' header >> >> files if it's API related only may be perfectly fine. There is >> >> precedence >> >> for it. >> > This ruling is indeed good news, but (a) it is still a matter of >> > continued litigation, as that article describes, so the ruling can >> > still be reversed by a higher court (I hope it won't); and (b) header >> > files are not just documentation of the APIs, they include some code >> > as well. So even if APIs are not copyrightable (which is still not >> > 100% clear), you cannot freely copy MS headers, especially since they >> > include explicit copyright notices by MS. >> > >> Hi, >> >> I don't think that mingw needs to be "holier than the pope" as we say in >> The Netherlands. What would Microsoft gain if they would chase away >> mingw from Windows? Sell a few more VC licenses... If you look at all >> the computing devices together then Windows is loosing ground big time. >> PC sales are going down and on the mobile devices Android and iOS rule. >> So I think that Windows needs all the developers it can get, even if >> they don't use MS tooling. I would not develop for Windows if I had to >> pay for the compiler. Forcing hobbyists and professionals to use VC >> would make the Windows target only more unpopular. >> All commercial C compilers for Windows have already given up. The few >> freeware compilers that remain are not a threat to MS VC. VC is THE >> compiler for Windows. I think it is unlikely that this will change in >> the near future. >> The mingw organisation is not a multi-million dollar company. "You can't >> pluck a bald chicken" (Dutch saying). Mingw has no money, so why would >> they start a costly court case which would bring them no money and would >> make them only more unpopular. >> The trend is actually that big companies support free compilers and >> other free software. See Apple's contribution to LLVM (clang). By >> investing in it they also get a lot of code and goodwill in return. >> >> regards, >> Erwin > > The simplest way to deal with this would be to request Microsoft to > explicitly fill in the gaps where people are making assumptions about what > Microsoft will or will not do. > > ------------------------------------------------------------------------------ > Is your legacy SCM system holding you back? Join Perforce May 7 to find out: > 3 signs your SCM is hindering your productivity > Requirements for releasing software faster > Expert tips and advice for migrating your SCM now > http://p.sf.net/sfu/perforce > _______________________________________________ > 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: Zouzou <int...@12...> - 2014-05-08 22:15:55
On 06/05/2014 20:44, Kirk Joppy wrote: >> What would Microsoft gain if they would chase away mingw from Windows? > > If mingw has a policy to remain bullet-proof against possible legal > action then guessing the mind of the party which might bring that > action is missing the point. > >> The mingw organisation is not a multi-million dollar company. "You can't >> pluck a bald chicken" (Dutch saying). > > False. Innocuous, free, and small projects posing no significant > economic threat get taken down and their developers sued. The dollar > amount doesn't even matter: you are going to settle for a fee that's > so small it can't possibly matter to the company suing you. The real > problem problem for you is that you will have to pay a lawyer and > waste enormous amounts of time. > > Not too long ago the Cockatrice project (a small online card gaming > program) was taken down and its developer sued. Users of the program > argued that they used it to test the value of various cards before > buying them through a paid gaming service offered by the company the > brought the legal action. Apparently the company did not agree with > this logic. > > Arguments similar to those you are making about mingw enlarging the > Windows user base could be made for the incident I described in the > previous paragraph. My _guess_ is that the company did this to prevent > legal precedent in which their copyright was not protected. > > Anyway, my point is, it is not only beside the point to guess about > what legal action Microsoft might take against mingw, it is also > potentially ruinous. Hey, The last time I can recall a Microsoft employee writing in this list, he seemed favorable to open-source compilers using Windows SDK headers: <http://mingw-users.1079350.n2.nabble.com/gcc-forks-on-Windows-was-re-repository-for-Open-Source-Windows-tp5223054p5284095.html>. Has anything happened on that front? CoApp <http://coapp.org/index.html> still appears to be updated, though it never mentions MinGW. I do agree on erring on the side of caution for the moment. Zouzou

From: Zouzou <int...@12...> - 2014-05-08 22:15:55

On 06/05/2014 20:44, Kirk Joppy wrote: >> What would Microsoft gain if they would chase away mingw from Windows? > > If mingw has a policy to remain bullet-proof against possible legal > action then guessing the mind of the party which might bring that > action is missing the point. > >> The mingw organisation is not a multi-million dollar company. "You can't >> pluck a bald chicken" (Dutch saying). > > False. Innocuous, free, and small projects posing no significant > economic threat get taken down and their developers sued. The dollar > amount doesn't even matter: you are going to settle for a fee that's > so small it can't possibly matter to the company suing you. The real > problem problem for you is that you will have to pay a lawyer and > waste enormous amounts of time. > > Not too long ago the Cockatrice project (a small online card gaming > program) was taken down and its developer sued. Users of the program > argued that they used it to test the value of various cards before > buying them through a paid gaming service offered by the company the > brought the legal action. Apparently the company did not agree with > this logic. > > Arguments similar to those you are making about mingw enlarging the > Windows user base could be made for the incident I described in the > previous paragraph. My _guess_ is that the company did this to prevent > legal precedent in which their copyright was not protected. > > Anyway, my point is, it is not only beside the point to guess about > what legal action Microsoft might take against mingw, it is also > potentially ruinous. Hey, The last time I can recall a Microsoft employee writing in this list, he seemed favorable to open-source compilers using Windows SDK headers: <http://mingw-users.1079350.n2.nabble.com/gcc-forks-on-Windows-was-re-repository-for-Open-Source-Windows-tp5223054p5284095.html>. Has anything happened on that front? CoApp <http://coapp.org/index.html> still appears to be updated, though it never mentions MinGW. I do agree on erring on the side of caution for the moment. Zouzou

From: KHMan <kei...@gm...> - 2014-05-09 01:35:23
On 5/9/2014 5:48 AM, Zouzou wrote: > On 06/05/2014 20:44, Kirk Joppy wrote: >>> What would Microsoft gain if they would chase away mingw from Windows? >> >> If mingw has a policy to remain bullet-proof against possible legal >> action then guessing the mind of the party which might bring that >> action is missing the point. >> >>> The mingw organisation is not a multi-million dollar company. "You can't >>> pluck a bald chicken" (Dutch saying). >>[snip] >> Arguments similar to those you are making about mingw enlarging the >> Windows user base could be made for the incident I described in the >> previous paragraph. My _guess_ is that the company did this to prevent >> legal precedent in which their copyright was not protected. >> >> Anyway, my point is, it is not only beside the point to guess about >> what legal action Microsoft might take against mingw, it is also >> potentially ruinous. > > Hey, > > The last time I can recall a Microsoft employee writing in this list, he > seemed favorable to open-source compilers using Windows SDK headers: > <http://mingw-users.1079350.n2.nabble.com/gcc-forks-on-Windows-was-re-repository-for-Open-Source-Windows-tp5223054p5284095.html>. I think the only thing that can fly would be an iron-clad legal agreement, like what the Samba people did when Microsoft decided to cooperate and I guess have Samba as part of their ecosystem. Remember, all of the header files are copyrighted. Asking for complete publicly-available documents would be easier than asking their lawyers to sign off on opening up their API files. I still think someone on the Win32 open source API side should ping Satya Nadella or a visible personality on the compiler side like Herb Sutter. Poke the gorilla (aka Microsoft) and ask nicely, so to speak... ;-) > Has anything happened on that front? CoApp <http://coapp.org/index.html> > still appears to be updated, though it never mentions MinGW. > > I do agree on erring on the side of caution for the moment. -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia

From: KHMan <kei...@gm...> - 2014-05-09 01:35:23

On 5/9/2014 5:48 AM, Zouzou wrote: > On 06/05/2014 20:44, Kirk Joppy wrote: >>> What would Microsoft gain if they would chase away mingw from Windows? >> >> If mingw has a policy to remain bullet-proof against possible legal >> action then guessing the mind of the party which might bring that >> action is missing the point. >> >>> The mingw organisation is not a multi-million dollar company. "You can't >>> pluck a bald chicken" (Dutch saying). >>[snip] >> Arguments similar to those you are making about mingw enlarging the >> Windows user base could be made for the incident I described in the >> previous paragraph. My _guess_ is that the company did this to prevent >> legal precedent in which their copyright was not protected. >> >> Anyway, my point is, it is not only beside the point to guess about >> what legal action Microsoft might take against mingw, it is also >> potentially ruinous. > > Hey, > > The last time I can recall a Microsoft employee writing in this list, he > seemed favorable to open-source compilers using Windows SDK headers: > <http://mingw-users.1079350.n2.nabble.com/gcc-forks-on-Windows-was-re-repository-for-Open-Source-Windows-tp5223054p5284095.html>. I think the only thing that can fly would be an iron-clad legal agreement, like what the Samba people did when Microsoft decided to cooperate and I guess have Samba as part of their ecosystem. Remember, all of the header files are copyrighted. Asking for complete publicly-available documents would be easier than asking their lawyers to sign off on opening up their API files. I still think someone on the Win32 open source API side should ping Satya Nadella or a visible personality on the compiler side like Herb Sutter. Poke the gorilla (aka Microsoft) and ask nicely, so to speak... ;-) > Has anything happened on that front? CoApp <http://coapp.org/index.html> > still appears to be updated, though it never mentions MinGW. > > I do agree on erring on the side of caution for the moment. -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia

From: Earnie B. <ea...@us...> - 2014-05-24 19:45:34
If there was as much time spent on producing patches for MinGW.org as there is in speculative rumor and assumption the project would be further along with its own 64bit compliant headers. The fact is Kai did not produce a patch, he produced a replacement and we pushed back asking for patches. He decided to take it up with the company he works for and that company's lawyers blessed it; so Kai started a new project. I refuse to speculate one way or another as to infringement or not; I don't have the time to look but because his company's lawyers saw nothing and because Redhat's lawyers with Cygwin blessed it then my assumption would be that they are copesetic with regard to copyright goodness. I am not saying Kai was correct in his decision to fork but he had the right to do so and I will not throw mud or hold hostility toward him for it. Let us consider the subject closed and move MinGW.org toward a more complete product. Regards, Earnie

From: Earnie B. <ea...@us...> - 2014-05-24 19:45:34

If there was as much time spent on producing patches for MinGW.org as there is in speculative rumor and assumption the project would be further along with its own 64bit compliant headers. The fact is Kai did not produce a patch, he produced a replacement and we pushed back asking for patches. He decided to take it up with the company he works for and that company's lawyers blessed it; so Kai started a new project. I refuse to speculate one way or another as to infringement or not; I don't have the time to look but because his company's lawyers saw nothing and because Redhat's lawyers with Cygwin blessed it then my assumption would be that they are copesetic with regard to copyright goodness. I am not saying Kai was correct in his decision to fork but he had the right to do so and I will not throw mud or hold hostility toward him for it. Let us consider the subject closed and move MinGW.org toward a more complete product. Regards, Earnie

From: Erwin W. <wat...@xs...> - 2014-05-25 18:53:08
Op 24-5-2014 21:45 Earnie Boyd schreef: > If there was as much time spent on producing patches for MinGW.org as > there is in speculative rumor and assumption the project would be > further along with its own 64bit compliant headers. > > The fact is Kai did not produce a patch, he produced a replacement and > we pushed back asking for patches. He decided to take it up with the > company he works for and that company's lawyers blessed it; so Kai > started a new project. I refuse to speculate one way or another as to > infringement or not; I don't have the time to look but because his > company's lawyers saw nothing and because Redhat's lawyers with Cygwin > blessed it then my assumption would be that they are copesetic with > regard to copyright goodness. > > I am not saying Kai was correct in his decision to fork but he had the > right to do so and I will not throw mud or hold hostility toward him > for it. Let us consider the subject closed and move MinGW.org toward > a more complete product. > Isn't that one of the blessings of open source? That everybody can take the source and fork it. Only being f[ou][rc]ked doesn't feel so nice... regards, -- Erwin

From: Erwin W. <wat...@xs...> - 2014-05-25 18:53:08

Op 24-5-2014 21:45 Earnie Boyd schreef: > If there was as much time spent on producing patches for MinGW.org as > there is in speculative rumor and assumption the project would be > further along with its own 64bit compliant headers. > > The fact is Kai did not produce a patch, he produced a replacement and > we pushed back asking for patches. He decided to take it up with the > company he works for and that company's lawyers blessed it; so Kai > started a new project. I refuse to speculate one way or another as to > infringement or not; I don't have the time to look but because his > company's lawyers saw nothing and because Redhat's lawyers with Cygwin > blessed it then my assumption would be that they are copesetic with > regard to copyright goodness. > > I am not saying Kai was correct in his decision to fork but he had the > right to do so and I will not throw mud or hold hostility toward him > for it. Let us consider the subject closed and move MinGW.org toward > a more complete product. > Isn't that one of the blessings of open source? That everybody can take the source and fork it. Only being f[ou][rc]ked doesn't feel so nice... regards, -- Erwin

From: KHMan <kei...@gm...> - 2014-05-26 03:00:25
On 5/26/2014 2:53 AM, Erwin Waterlander wrote: > Op 24-5-2014 21:45 Earnie Boyd schreef: >> If there was as much time spent on producing patches for MinGW.org as >> there is in speculative rumor and assumption the project would be >> further along with its own 64bit compliant headers. >> >> The fact is Kai did not produce a patch, he produced a replacement and >> we pushed back asking for patches. He decided to take it up with the >> company he works for and that company's lawyers blessed it; so Kai >> started a new project. I refuse to speculate one way or another as to >> infringement or not; I don't have the time to look but because his >> company's lawyers saw nothing and because Redhat's lawyers with Cygwin >> blessed it then my assumption would be that they are copesetic with >> regard to copyright goodness. >> >> I am not saying Kai was correct in his decision to fork but he had the >> right to do so and I will not throw mud or hold hostility toward him >> for it. Let us consider the subject closed and move MinGW.org toward >> a more complete product. > > Isn't that one of the blessings of open source? That everybody can take > the source and fork it. > Only being f[ou][rc]ked doesn't feel so nice... Let's not continue with your "being forked doesn't feel so nice" theme. Until this latest thread, each project has been minding their own business peacefully for a long time. I thought this thread started more along the lines of the idea that every version of MinGW must run smoothly across all versions for all API calls some user needs, hence the source code sharing discussion. It's just that certain users need an adjustment. They can't expect Free Software/Open Source projects to run spiffily like actual products. I think most of the old timers on the list would not be so demanding with their opinion of how things should be done or how compilers should work. -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia

From: KHMan <kei...@gm...> - 2014-05-26 03:00:25

On 5/26/2014 2:53 AM, Erwin Waterlander wrote: > Op 24-5-2014 21:45 Earnie Boyd schreef: >> If there was as much time spent on producing patches for MinGW.org as >> there is in speculative rumor and assumption the project would be >> further along with its own 64bit compliant headers. >> >> The fact is Kai did not produce a patch, he produced a replacement and >> we pushed back asking for patches. He decided to take it up with the >> company he works for and that company's lawyers blessed it; so Kai >> started a new project. I refuse to speculate one way or another as to >> infringement or not; I don't have the time to look but because his >> company's lawyers saw nothing and because Redhat's lawyers with Cygwin >> blessed it then my assumption would be that they are copesetic with >> regard to copyright goodness. >> >> I am not saying Kai was correct in his decision to fork but he had the >> right to do so and I will not throw mud or hold hostility toward him >> for it. Let us consider the subject closed and move MinGW.org toward >> a more complete product. > > Isn't that one of the blessings of open source? That everybody can take > the source and fork it. > Only being f[ou][rc]ked doesn't feel so nice... Let's not continue with your "being forked doesn't feel so nice" theme. Until this latest thread, each project has been minding their own business peacefully for a long time. I thought this thread started more along the lines of the idea that every version of MinGW must run smoothly across all versions for all API calls some user needs, hence the source code sharing discussion. It's just that certain users need an adjustment. They can't expect Free Software/Open Source projects to run spiffily like actual products. I think most of the old timers on the list would not be so demanding with their opinion of how things should be done or how compilers should work. -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia

From: KHMan <kei...@gm...> - 2014-05-27 08:19:01
On 5/27/2014 1:13 AM, Alan W. Irwin wrote: > On 2014-05-26 09:22-0400 Pete McNeil wrote: > >> On 2014-05-25 23:00, KHMan wrote: >>> It's just that certain users need an adjustment. They can't expect >>> Free Software/Open Source projects to run spiffily like actual >>> products. >> >> I usually just lurk here unless I can help somebody. But this hit one of >> my buttons. >> >> There is no reason our expectations of free/open software should be any >> less than our expectations of "actual" products. [...] > > Well said. Heh heh, look, I guess I put it in too few words. I simply did not want to write long postings. I mean that users of FLOSS should not expect some kind of customer-supplier relationship. Well sure, many a time it works great when the community solves problems for people, but sometimes people begin to take that for granted. Resources is scarce, we are a community, we are not customers of the project to be pampered to some expectation of some kind of service level. Tell 'em to de newbies, we canna take the best produce from de farm and do nothing for de land. We gotta fertilize the land, care and nuture the soil. When you see them nice produce in the supermarkets, well it took effort to grow 'em nice for you. -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia

From: KHMan <kei...@gm...> - 2014-05-27 08:19:01

On 5/27/2014 1:13 AM, Alan W. Irwin wrote: > On 2014-05-26 09:22-0400 Pete McNeil wrote: > >> On 2014-05-25 23:00, KHMan wrote: >>> It's just that certain users need an adjustment. They can't expect >>> Free Software/Open Source projects to run spiffily like actual >>> products. >> >> I usually just lurk here unless I can help somebody. But this hit one of >> my buttons. >> >> There is no reason our expectations of free/open software should be any >> less than our expectations of "actual" products. [...] > > Well said. Heh heh, look, I guess I put it in too few words. I simply did not want to write long postings. I mean that users of FLOSS should not expect some kind of customer-supplier relationship. Well sure, many a time it works great when the community solves problems for people, but sometimes people begin to take that for granted. Resources is scarce, we are a community, we are not customers of the project to be pampered to some expectation of some kind of service level. Tell 'em to de newbies, we canna take the best produce from de farm and do nothing for de land. We gotta fertilize the land, care and nuture the soil. When you see them nice produce in the supermarkets, well it took effort to grow 'em nice for you. -- Cheers, Kein-Hong Man (esq.) Kuala Lumpur, Malaysia

From: Kyle K. <rem...@gm...> - 2014-06-08 12:54:01
On Sun, Jun 8, 2014 at 5:58 AM, Erdem Demir <ker...@ho...> wrote: > > gcc hello.c > /tmp/ccoiOZyQ.o:hello.c:(.text+0x5e): undefined reference to `_wcsncpy' > collect2: ld returned 1 exit status > > > Is there any way around for me ? Even I think this is a problem with MSYS > special gcc I downloaded all dev packages with mingw installiton manager > and also updated the existing ones. > > I need _wsnncpy because I need to compile python. Python nags about wide > char related functions like _wcsncpy. I need python badly because I need to > recompile gdb with python option on my windows machine with help of MSYS. > > Note: gcc options&version > $ gcc -v > Reading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specs > Configured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure > --prefix=/usr --s > ysconfdir=/etc --localstatedir=/var --infodir=/share/info > --mandir=/share/man -- > libexecdir=/lib --enable-languages=c,c++ --disable-nls > --enable-threads=posix -- > enable-sjlj-exceptions --enable-hash-synchronization > --enable-libstdcxx-debug -- > with-newlib > Thread model: posix > gcc version 3.4.4 (msys special) > The code above compiles with no issues for me, There seems to be something wrong your your configuration. Firstly, it looks like your using GCC 3.4.x, which IIRC does not support w strings. The current release of MinGW comes with GCC 4.4 (I believe) and should allow the above code to compile. You should re-download/install MinGW first. Place it in C:/MinGW and add C:/MinGW to your PATH variable. Then you can either download Msys with the install manager or get it from SF.

From: Kyle K. <rem...@gm...> - 2014-06-08 12:54:01

On Sun, Jun 8, 2014 at 5:58 AM, Erdem Demir <ker...@ho...> wrote: > > gcc hello.c > /tmp/ccoiOZyQ.o:hello.c:(.text+0x5e): undefined reference to `_wcsncpy' > collect2: ld returned 1 exit status > > > Is there any way around for me ? Even I think this is a problem with MSYS > special gcc I downloaded all dev packages with mingw installiton manager > and also updated the existing ones. > > I need _wsnncpy because I need to compile python. Python nags about wide > char related functions like _wcsncpy. I need python badly because I need to > recompile gdb with python option on my windows machine with help of MSYS. > > Note: gcc options&version > $ gcc -v > Reading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specs > Configured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure > --prefix=/usr --s > ysconfdir=/etc --localstatedir=/var --infodir=/share/info > --mandir=/share/man -- > libexecdir=/lib --enable-languages=c,c++ --disable-nls > --enable-threads=posix -- > enable-sjlj-exceptions --enable-hash-synchronization > --enable-libstdcxx-debug -- > with-newlib > Thread model: posix > gcc version 3.4.4 (msys special) > The code above compiles with no issues for me, There seems to be something wrong your your configuration. Firstly, it looks like your using GCC 3.4.x, which IIRC does not support w strings. The current release of MinGW comes with GCC 4.4 (I believe) and should allow the above code to compile. You should re-download/install MinGW first. Place it in C:/MinGW and add C:/MinGW to your PATH variable. Then you can either download Msys with the install manager or get it from SF.

From: Keith M. <kei...@us...> - 2014-06-08 13:45:15
This message, originating from Erdem Demir, was in reply to thread with subject "64-bit MinGW"; thus, that original thread has been hijacked. Please do not do this again, unless you do want to be banned from this list. (FTR, Erdem had previously asked me why he was barred from the defunct MinGW-MSYS list ... as everyone is). On 08/06/14 13:53, Kyle Ketterer wrote: > On Sun, Jun 8, 2014 at 5:58 AM, Erdem Demirwrote: >> >> gcc hello.c >> /tmp/ccoiOZyQ.o:hello.c:(.text+0x5e): undefined reference to `_wcsncpy' >> collect2: ld returned 1 exit status >> >> Is there any way around for me ? Even I think this is a problem with MSYS >> special gcc Unless you are developing MSYS itself, you really don't want to be using this; regular MinGW should be your compiler of choice. >> I downloaded all dev packages with mingw installiton manager >> and also updated the existing ones. >> >> I need _wsnncpy because I need to compile python. Python nags about wide >> char related functions like _wcsncpy. I need python badly because I need to >> recompile gdb with python option on my windows machine with help of MSYS. >> >> Note: gcc options&version >> $ gcc -v >> Reading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specs >> Configured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure Yes. See, this is the MSYS development compiler, which you don't want to be using. > The code above compiles with no issues for me, There seems to be something > wrong your your configuration. Firstly, it looks like your using GCC 3.4.x, > which IIRC does not support w strings. I don't know about that; it's been a long time since I used such an ancient GCC ... I don't develop MSYS. > The current release of MinGW comes with GCC 4.4 (I believe) and should > allow the above code to compile. This too is ancient history. The current release ... for around the last twelve months ... is GCC-4.8.1, and there is also GCC-4.8.2 in our distribution repository, although not yet integrated into the mingw-get delivery system. We could really do with a volunteer, dedicated to maintaining our GCC releases -- any takers? -- Regards, Keith.

From: Keith M. <kei...@us...> - 2014-06-08 13:45:15

This message, originating from Erdem Demir, was in reply to thread with subject "64-bit MinGW"; thus, that original thread has been hijacked. Please do not do this again, unless you do want to be banned from this list. (FTR, Erdem had previously asked me why he was barred from the defunct MinGW-MSYS list ... as everyone is). On 08/06/14 13:53, Kyle Ketterer wrote: > On Sun, Jun 8, 2014 at 5:58 AM, Erdem Demirwrote: >> >> gcc hello.c >> /tmp/ccoiOZyQ.o:hello.c:(.text+0x5e): undefined reference to `_wcsncpy' >> collect2: ld returned 1 exit status >> >> Is there any way around for me ? Even I think this is a problem with MSYS >> special gcc Unless you are developing MSYS itself, you really don't want to be using this; regular MinGW should be your compiler of choice. >> I downloaded all dev packages with mingw installiton manager >> and also updated the existing ones. >> >> I need _wsnncpy because I need to compile python. Python nags about wide >> char related functions like _wcsncpy. I need python badly because I need to >> recompile gdb with python option on my windows machine with help of MSYS. >> >> Note: gcc options&version >> $ gcc -v >> Reading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specs >> Configured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure Yes. See, this is the MSYS development compiler, which you don't want to be using. > The code above compiles with no issues for me, There seems to be something > wrong your your configuration. Firstly, it looks like your using GCC 3.4.x, > which IIRC does not support w strings. I don't know about that; it's been a long time since I used such an ancient GCC ... I don't develop MSYS. > The current release of MinGW comes with GCC 4.4 (I believe) and should > allow the above code to compile. This too is ancient history. The current release ... for around the last twelve months ... is GCC-4.8.1, and there is also GCC-4.8.2 in our distribution repository, although not yet integrated into the mingw-get delivery system. We could really do with a volunteer, dedicated to maintaining our GCC releases -- any takers? -- Regards, Keith.

From: Pete M. <mad...@mi...> - 2014-05-26 14:22:32
On 2014-05-25 23:00, KHMan wrote: > It's just that certain users need an adjustment. They can't expect > Free Software/Open Source projects to run spiffily like actual > products. I usually just lurk here unless I can help somebody. But this hit one of my buttons. There is no reason our expectations of free/open software should be any less than our expectations of "actual" products. I think exactly the opposite. Presuming by "actual" you mean profit driven commercial products, I think we should expect free/open software to drive toward the highest standards and achieve them. "Actual" products have a lot of axes to grind that have nothing whatever to do with a high quality user experience and high quality software engineering. Free/Open products don't have those obstacles. The financial resources available to "actual" products may be greater than those available to free/open software but the folks maintaining free/open software are doing it for better reasons and should be keen to achieve _better_ results. The financial resources available to free/open projects don't have to be less than those for "actual" products either -- there are ways around that too - especially if specific goals are desired by the community supporting them. Not only that, but without the distracting pressures and problems associated with building "actual" products the resources that are available to free/open projects can be more efficiently allocated and better targeted. So, _please_ don't suffer with the expectation that free/open software should somehow be weaker, shabbier, or less-than commercial or "actual" software... and by all means AVOID spreading that kind of FUD and self-defeating misinformation. There is no good reason to believe it and every reason we shouldn't settle for it. Take that energy and point it toward focusing on the solution... if there is something here that needs to be better (and there always is) then get to work on a solution and encourage those who do focus there to do their best work. _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 twitter/codedweller

From: Pete M. <mad...@mi...> - 2014-05-26 14:22:32

On 2014-05-25 23:00, KHMan wrote: > It's just that certain users need an adjustment. They can't expect > Free Software/Open Source projects to run spiffily like actual > products. I usually just lurk here unless I can help somebody. But this hit one of my buttons. There is no reason our expectations of free/open software should be any less than our expectations of "actual" products. I think exactly the opposite. Presuming by "actual" you mean profit driven commercial products, I think we should expect free/open software to drive toward the highest standards and achieve them. "Actual" products have a lot of axes to grind that have nothing whatever to do with a high quality user experience and high quality software engineering. Free/Open products don't have those obstacles. The financial resources available to "actual" products may be greater than those available to free/open software but the folks maintaining free/open software are doing it for better reasons and should be keen to achieve _better_ results. The financial resources available to free/open projects don't have to be less than those for "actual" products either -- there are ways around that too - especially if specific goals are desired by the community supporting them. Not only that, but without the distracting pressures and problems associated with building "actual" products the resources that are available to free/open projects can be more efficiently allocated and better targeted. So, _please_ don't suffer with the expectation that free/open software should somehow be weaker, shabbier, or less-than commercial or "actual" software... and by all means AVOID spreading that kind of FUD and self-defeating misinformation. There is no good reason to believe it and every reason we shouldn't settle for it. Take that energy and point it toward focusing on the solution... if there is something here that needs to be better (and there always is) then get to work on a solution and encourage those who do focus there to do their best work. _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 twitter/codedweller

From: Alan W. I. <ir...@be...> - 2014-05-26 17:14:06
On 2014-05-26 09:22-0400 Pete McNeil wrote: > On 2014-05-25 23:00, KHMan wrote: >> It's just that certain users need an adjustment. They can't expect >> Free Software/Open Source projects to run spiffily like actual >> products. > > I usually just lurk here unless I can help somebody. But this hit one of > my buttons. > > There is no reason our expectations of free/open software should be any > less than our expectations of "actual" products. [...] Well said. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________

From: Alan W. I. <ir...@be...> - 2014-05-26 17:14:06

On 2014-05-26 09:22-0400 Pete McNeil wrote: > On 2014-05-25 23:00, KHMan wrote: >> It's just that certain users need an adjustment. They can't expect >> Free Software/Open Source projects to run spiffily like actual >> products. > > I usually just lurk here unless I can help somebody. But this hit one of > my buttons. > > There is no reason our expectations of free/open software should be any > less than our expectations of "actual" products. [...] Well said. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________

From: Pete M. <mad...@mi...> - 2014-05-27 14:26:41
On 2014-05-27 04:18, KHMan wrote: > I mean that users of FLOSS should not expect some kind of > customer-supplier relationship. Well sure, many a time it works > great when the community solves problems for people, but sometimes > people begin to take that for granted. OK, I See that point _IF_ the project is not sufficiently organized to provide that relationship... but it seems like an opportunity rather than an obstacle: If resources are scarce and folks using the product want support then there is a natural opportunity for trade there... and as is done with many successful free/open projects, such a customer should be able to purchase a support subscription or per-ticket support to drive the project forward. It's a pretty successful model. Maybe it's time to put something like that together here. Reach up to a higher level of service instead of down to lower expectations. _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 twitter/codedweller

From: Pete M. <mad...@mi...> - 2014-05-27 14:26:41

On 2014-05-27 04:18, KHMan wrote: > I mean that users of FLOSS should not expect some kind of > customer-supplier relationship. Well sure, many a time it works > great when the community solves problems for people, but sometimes > people begin to take that for granted. OK, I See that point _IF_ the project is not sufficiently organized to provide that relationship... but it seems like an opportunity rather than an obstacle: If resources are scarce and folks using the product want support then there is a natural opportunity for trade there... and as is done with many successful free/open projects, such a customer should be able to purchase a support subscription or per-ticket support to drive the project forward. It's a pretty successful model. Maybe it's time to put something like that together here. Reach up to a higher level of service instead of down to lower expectations. _M -- Pete McNeil, President MicroNeil Research Corporation www.microneil.com 703.779.4909 x7010 twitter/codedweller

From: Kirk J. <kir...@gm...> - 2014-06-08 00:48:14
> If resources are scarce and folks using the product want support then > there is a natural opportunity for trade there... and as is done with > many successful free/open projects, such a customer should be able to > purchase a support subscription or per-ticket support to drive the >project forward. It's a pretty successful model. For what it's worth, the numpy project (de facto numerical processing from python) does not have a 64 bit release for windows precisely because there isn't a free, open source compiler that they know how to use. It's a big project, maybe worth talking to them to see if someone there has the time/means to help. On Tue, May 27, 2014 at 7:26 AM, Pete McNeil <mad...@mi...> wrote: > On 2014-05-27 04:18, KHMan wrote: >> I mean that users of FLOSS should not expect some kind of >> customer-supplier relationship. Well sure, many a time it works >> great when the community solves problems for people, but sometimes >> people begin to take that for granted. > > OK, I See that point _IF_ the project is not sufficiently organized to > provide that relationship... but it seems like an opportunity rather > than an obstacle: > > If resources are scarce and folks using the product want support then > there is a natural opportunity for trade there... and as is done with > many successful free/open projects, such a customer should be able to > purchase a support subscription or per-ticket support to drive the > project forward. It's a pretty successful model. > > Maybe it's time to put something like that together here. > > Reach up to a higher level of service instead of down to lower expectations. > > _M > > -- > Pete McNeil, President > MicroNeil Research Corporation > www.microneil.com > 703.779.4909 x7010 > twitter/codedweller > > > > ------------------------------------------------------------------------------ > The best possible search technologies are now affordable for all companies. > Download your FREE open source Enterprise Search Engine today! > Our experts will assist you in its installation for $59/mo, no commitment. > Test it for FREE on our Cloud platform anytime! > http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk > _______________________________________________ > 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: Kirk J. <kir...@gm...> - 2014-06-08 00:48:14

> If resources are scarce and folks using the product want support then > there is a natural opportunity for trade there... and as is done with > many successful free/open projects, such a customer should be able to > purchase a support subscription or per-ticket support to drive the >project forward. It's a pretty successful model. For what it's worth, the numpy project (de facto numerical processing from python) does not have a 64 bit release for windows precisely because there isn't a free, open source compiler that they know how to use. It's a big project, maybe worth talking to them to see if someone there has the time/means to help. On Tue, May 27, 2014 at 7:26 AM, Pete McNeil <mad...@mi...> wrote: > On 2014-05-27 04:18, KHMan wrote: >> I mean that users of FLOSS should not expect some kind of >> customer-supplier relationship. Well sure, many a time it works >> great when the community solves problems for people, but sometimes >> people begin to take that for granted. > > OK, I See that point _IF_ the project is not sufficiently organized to > provide that relationship... but it seems like an opportunity rather > than an obstacle: > > If resources are scarce and folks using the product want support then > there is a natural opportunity for trade there... and as is done with > many successful free/open projects, such a customer should be able to > purchase a support subscription or per-ticket support to drive the > project forward. It's a pretty successful model. > > Maybe it's time to put something like that together here. > > Reach up to a higher level of service instead of down to lower expectations. > > _M > > -- > Pete McNeil, President > MicroNeil Research Corporation > www.microneil.com > 703.779.4909 x7010 > twitter/codedweller > > > > ------------------------------------------------------------------------------ > The best possible search technologies are now affordable for all companies. > Download your FREE open source Enterprise Search Engine today! > Our experts will assist you in its installation for $59/mo, no commitment. > Test it for FREE on our Cloud platform anytime! > http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk > _______________________________________________ > 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: Alexpux <al...@gm...> - 2014-06-08 05:59:18
08 июня 2014 г., в 4:48, Kirk Joppy написал(а): >> If resources are scarce and folks using the product want support then >> there is a natural opportunity for trade there... and as is done with >> many successful free/open projects, such a customer should be able to >> purchase a support subscription or per-ticket support to drive the >> project forward. It's a pretty successful model. > > For what it's worth, the numpy project (de facto numerical processing > from python) does not have a 64 bit release for windows precisely > because there isn't a free, open source compiler that they know how to > use. It's a big project, maybe worth talking to them to see if someone > there has the time/means to help. > I’m successfully build numpy with 64-bit mingw-w64 GCC 4.8.x/4.9.x. https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python-numpy You can try use it. You need to install MSYS2 and then you be able get it with all dependencies via package manager. Regards, Alexey. > > > On Tue, May 27, 2014 at 7:26 AM, Pete McNeil wrote: >> On 2014-05-27 04:18, KHMan wrote: >>> I mean that users of FLOSS should not expect some kind of >>> customer-supplier relationship. Well sure, many a time it works >>> great when the community solves problems for people, but sometimes >>> people begin to take that for granted. >> >> OK, I See that point _IF_ the project is not sufficiently organized to >> provide that relationship... but it seems like an opportunity rather >> than an obstacle: >> >> If resources are scarce and folks using the product want support then >> there is a natural opportunity for trade there... and as is done with >> many successful free/open projects, such a customer should be able to >> purchase a support subscription or per-ticket support to drive the >> project forward. It's a pretty successful model. >> >> Maybe it's time to put something like that together here. >> >> Reach up to a higher level of service instead of down to lower expectations. >> >> _M >> >> -- >> Pete McNeil, President >> MicroNeil Research Corporation >> www.microneil.com >> 703.779.4909 x7010 >> twitter/codedweller >> >> >> >> ------------------------------------------------------------------------------ >> The best possible search technologies are now affordable for all companies. >> Download your FREE open source Enterprise Search Engine today! >> Our experts will assist you in its installation for $59/mo, no commitment. >> Test it for FREE on our Cloud platform anytime! >> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk >> _______________________________________________ >> 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 > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > 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: Alexpux <al...@gm...> - 2014-06-08 05:59:18

08 июня 2014 г., в 4:48, Kirk Joppy написал(а): >> If resources are scarce and folks using the product want support then >> there is a natural opportunity for trade there... and as is done with >> many successful free/open projects, such a customer should be able to >> purchase a support subscription or per-ticket support to drive the >> project forward. It's a pretty successful model. > > For what it's worth, the numpy project (de facto numerical processing > from python) does not have a 64 bit release for windows precisely > because there isn't a free, open source compiler that they know how to > use. It's a big project, maybe worth talking to them to see if someone > there has the time/means to help. > I’m successfully build numpy with 64-bit mingw-w64 GCC 4.8.x/4.9.x. https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python-numpy You can try use it. You need to install MSYS2 and then you be able get it with all dependencies via package manager. Regards, Alexey. > > > On Tue, May 27, 2014 at 7:26 AM, Pete McNeil wrote: >> On 2014-05-27 04:18, KHMan wrote: >>> I mean that users of FLOSS should not expect some kind of >>> customer-supplier relationship. Well sure, many a time it works >>> great when the community solves problems for people, but sometimes >>> people begin to take that for granted. >> >> OK, I See that point _IF_ the project is not sufficiently organized to >> provide that relationship... but it seems like an opportunity rather >> than an obstacle: >> >> If resources are scarce and folks using the product want support then >> there is a natural opportunity for trade there... and as is done with >> many successful free/open projects, such a customer should be able to >> purchase a support subscription or per-ticket support to drive the >> project forward. It's a pretty successful model. >> >> Maybe it's time to put something like that together here. >> >> Reach up to a higher level of service instead of down to lower expectations. >> >> _M >> >> -- >> Pete McNeil, President >> MicroNeil Research Corporation >> www.microneil.com >> 703.779.4909 x7010 >> twitter/codedweller >> >> >> >> ------------------------------------------------------------------------------ >> The best possible search technologies are now affordable for all companies. >> Download your FREE open source Enterprise Search Engine today! >> Our experts will assist you in its installation for $59/mo, no commitment. >> Test it for FREE on our Cloud platform anytime! >> http://pubads.g.doubleclick.net/gampad/clk?id=145328191&iu=/4140/ostg.clktrk >> _______________________________________________ >> 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 > > ------------------------------------------------------------------------------ > Learn Graph Databases - Download FREE O'Reilly Book > "Graph Databases" is the definitive new guide to graph databases and their > applications. Written by three acclaimed leaders in the field, > this first edition is now available. Download your free book today! > http://p.sf.net/sfu/NeoTech > _______________________________________________ > 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: Erdem D. <ker...@ho...> - 2014-06-08 09:58:57
The simple code below #include <wchar.h> int main (){ wchar_t wcs1[] = L"To be or not to be"; wchar_t wcs2[40]; wcsncpy ( wcs2, wcs1, 40 ); wprintf (L"%ls\n%ls\n",wcs1,wcs2); return 0;} gives link time error : gcc hello.c/tmp/ccoiOZyQ.o:hello.c:(.text+0x5e): undefined reference to `_wcsncpy'collect2: ld returned 1 exit status Is there any way around for me ? Even I think this is a problem with MSYS special gcc I downloaded all dev packages with mingw installiton manager and also updated the existing ones. I need _wsnncpy because I need to compile python. Python nags about wide char related functions like _wcsncpy. I need python badly because I need to recompile gdb with python option on my windows machine with help of MSYS. And advise or help will be appriciated . RegardsErdem Note: gcc options&version $ gcc -vReading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specsConfigured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --infodir=/share/info --mandir=/share/man --libexecdir=/lib --enable-languages=c,c++ --disable-nls --enable-threads=posix --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug --with-newlibThread model: posixgcc version 3.4.4 (msys special)

From: Erdem D. <ker...@ho...> - 2014-06-08 09:58:57

The simple code below #include <wchar.h> int main (){ wchar_t wcs1[] = L"To be or not to be"; wchar_t wcs2[40]; wcsncpy ( wcs2, wcs1, 40 ); wprintf (L"%ls\n%ls\n",wcs1,wcs2); return 0;} gives link time error : gcc hello.c/tmp/ccoiOZyQ.o:hello.c:(.text+0x5e): undefined reference to `_wcsncpy'collect2: ld returned 1 exit status Is there any way around for me ? Even I think this is a problem with MSYS special gcc I downloaded all dev packages with mingw installiton manager and also updated the existing ones. I need _wsnncpy because I need to compile python. Python nags about wide char related functions like _wcsncpy. I need python badly because I need to recompile gdb with python option on my windows machine with help of MSYS. And advise or help will be appriciated . RegardsErdem Note: gcc options&version $ gcc -vReading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specsConfigured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var --infodir=/share/info --mandir=/share/man --libexecdir=/lib --enable-languages=c,c++ --disable-nls --enable-threads=posix --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug --with-newlibThread model: posixgcc version 3.4.4 (msys special)

From: Erdem D. <ker...@ho...> - 2014-06-08 13:26:38
Thanks for patience and also for answers, I am not using MSYS by normally, I should have known I need to use ./configure CC=mingw32-g++ ./make CC=mingw32-g++ for building python. I thought Mingw install manager(which I updated every dev package including gcc&g++) will make recently downloaded gcc default for MSYS by overwriting the old one, silly but I imagined it that way. I am restarting the build as I wrote I hope everything will be fine this time. RegardsErdem Date: Sun, 8 Jun 2014 08:53:54 -0400 From: rem...@gm... To: min...@li... Subject: Re: [Mingw-users] Does MSYS-MinGW Supports WChars ? On Sun, Jun 8, 2014 at 5:58 AM, Erdem Demir <ker...@ho...> wrote: gcc hello.c/tmp/ccoiOZyQ.o:hello.c:(.text+0x5e): undefined reference to `_wcsncpy'collect2: ld returned 1 exit status Is there any way around for me ? Even I think this is a problem with MSYS special gcc I downloaded all dev packages with mingw installiton manager and also updated the existing ones. I need _wsnncpy because I need to compile python. Python nags about wide char related functions like _wcsncpy. I need python badly because I need to recompile gdb with python option on my windows machine with help of MSYS. Note: gcc options&version $ gcc -vReading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specsConfigured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure --prefix=/usr --s ysconfdir=/etc --localstatedir=/var --infodir=/share/info --mandir=/share/man --libexecdir=/lib --enable-languages=c,c++ --disable-nls --enable-threads=posix --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug -- with-newlibThread model: posixgcc version 3.4.4 (msys special) The code above compiles with no issues for me, There seems to be something wrong your your configuration. Firstly, it looks like your using GCC 3.4.x, which IIRC does not support w strings. The current release of MinGW comes with GCC 4.4 (I believe) and should allow the above code to compile. You should re-download/install MinGW first. Place it in C:/MinGW and add C:/MinGW to your PATH variable. Then you can either download Msys with the install manager or get it from SF. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ 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: Erdem D. <ker...@ho...> - 2014-06-08 13:26:38

Thanks for patience and also for answers, I am not using MSYS by normally, I should have known I need to use ./configure CC=mingw32-g++ ./make CC=mingw32-g++ for building python. I thought Mingw install manager(which I updated every dev package including gcc&g++) will make recently downloaded gcc default for MSYS by overwriting the old one, silly but I imagined it that way. I am restarting the build as I wrote I hope everything will be fine this time. RegardsErdem Date: Sun, 8 Jun 2014 08:53:54 -0400 From: rem...@gm... To: min...@li... Subject: Re: [Mingw-users] Does MSYS-MinGW Supports WChars ? On Sun, Jun 8, 2014 at 5:58 AM, Erdem Demir <ker...@ho...> wrote: gcc hello.c/tmp/ccoiOZyQ.o:hello.c:(.text+0x5e): undefined reference to `_wcsncpy'collect2: ld returned 1 exit status Is there any way around for me ? Even I think this is a problem with MSYS special gcc I downloaded all dev packages with mingw installiton manager and also updated the existing ones. I need _wsnncpy because I need to compile python. Python nags about wide char related functions like _wcsncpy. I need python badly because I need to recompile gdb with python option on my windows machine with help of MSYS. Note: gcc options&version $ gcc -vReading specs from /usr/lib/gcc/i686-pc-msys/3.4.4/specsConfigured with: /home/cstrauss/build/gcc3/gcc-3.4.4/configure --prefix=/usr --s ysconfdir=/etc --localstatedir=/var --infodir=/share/info --mandir=/share/man --libexecdir=/lib --enable-languages=c,c++ --disable-nls --enable-threads=posix --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug -- with-newlibThread model: posixgcc version 3.4.4 (msys special) The code above compiles with no issues for me, There seems to be something wrong your your configuration. Firstly, it looks like your using GCC 3.4.x, which IIRC does not support w strings. The current release of MinGW comes with GCC 4.4 (I believe) and should allow the above code to compile. You should re-download/install MinGW first. Place it in C:/MinGW and add C:/MinGW to your PATH variable. Then you can either download Msys with the install manager or get it from SF. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/NeoTech _______________________________________________ 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: Keith M. <kei...@us...> - 2014-06-08 14:02:28
On 08/06/14 14:26, Erdem Demir wrote: > I am not using MSYS by normally, I should have known I need to use > ./configure CC=mingw32-g++ If you need to do this, then you haven't set your PATH correctly; /mingw/bin should precede /bin, (or /usr/bin), so the MinGW compiler, and not the MSYS, should be identified as the default. > ./make CC=mingw32-g++ for building python. And you certainly shouldn't need to do this, once the correct compiler has been identified when you ran configure. -- Regards, Keith.

From: Keith M. <kei...@us...> - 2014-06-08 14:02:28

On 08/06/14 14:26, Erdem Demir wrote: > I am not using MSYS by normally, I should have known I need to use > ./configure CC=mingw32-g++ If you need to do this, then you haven't set your PATH correctly; /mingw/bin should precede /bin, (or /usr/bin), so the MinGW compiler, and not the MSYS, should be identified as the default. > ./make CC=mingw32-g++ for building python. And you certainly shouldn't need to do this, once the correct compiler has been identified when you ran configure. -- Regards, Keith.

Want the latest updates on software, tech news, and AI?

Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.

Thanks for helping keep SourceForge clean.