from:"Ray Donnelly"

Re: [Mingw-w64-public] static lib/Visual Studio problem

2017-06-07 Thread Ray Donnelly

On Jun 7, 2017 3:19 PM, "Brad Garton"  wrote:

I wish I could (go the total mingw-w64 route).  The libs I'm building are
for use in OpenFrameworks and Unity, and I don't think mingw-w64 projects
exist for them.


OpenFrameworks had good support for mingw-w64 via msys2 stuff last time I
checked. Unity is another question but it's likely possible to make
mingw-w64 import libraries for their DLLs.


brad


On Wed, Jun 7, 2017 at 10:08 AM, David Grayson 
wrote:

> I'd encourage you to try the mingw-w64 route.  If you use mingw-w64
> and GCC, you won't have to worry about the licensing restrictions
> Microsoft puts on Visual Studio, which have changed over the years.
> The mingw-w64 project provides a lot of the headers and functions that
> Visual Studio has, and they always accept patches to add missing
> headers or functions on this mailing list.  In fact, I've been able to
> compile two different pieces of pretty involved Microsoft sample code
> using mingw-w64 (usbview and devcon).
>
> --David
>
> On Wed, Jun 7, 2017 at 6:35 AM, Brad Garton  wrote:
> > Aha -- this was what I feared would be the case.  I'll start porting all
> > the code into VS and tracking down all the missing headers and
functions,
> > oh joy.
> >
> > Thanks for the help, everyone!
> >
> > brad
> >
> >
> > On Wed, Jun 7, 2017 at 6:50 AM, Mateusz Mikuła 
> wrote:
> >
> >> > However, once I try to use some more c++ features, I get the
> >> > following
> >> > error, and it seems to be associated with the compiled object files
> >> > themselves:
> >> >
> >> > "invalid or corrupt file: no symbol for COMDAT section ..." (and a
> >> > hex
> >> > address).
> >>
> >> It's not possible to mix static libstdc++ with Microsoft C++ runtime.
> >> In fact even mingw-w64 based Clang doesn't play nicely with static
> >> libstdc++ http://lists.llvm.org/pipermail/cfe-dev/2017-April/053530.htm
> >> l
> >> 
> >> --
> >> Check out the vibrant tech community on one of the world's most
> >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >> ___
> >> Mingw-w64-public mailing list
> >> Mingw-w64-public@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
> >>
> >>
> > 
> --
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
> 
> --
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH v5] Add include/iscygtty.c

2016-11-12 Thread Ray Donnelly

MSYS2 is a software distribution with both (extremely) Cygwin-like and also
native Windows software, all (usually) launched from mintty.

On Nov 12, 2016 3:41 PM, "Corinna Vinschen" <vinsc...@redhat.com> wrote:

> On Nov 12 14:52, Ray Donnelly wrote:
> > On Nov 12, 2016 1:30 PM, "Corinna Vinschen" <vinsc...@redhat.com> wrote:
> > >
> > > On Nov 12 12:27, JonY wrote:
> > > > On 11/12/2016 11:57, Mihail Konev wrote:
> > > > > Applications now could call iscygtty(STDIN_FILENO)
> > > > > in order to detect whether they are running from
> > > > > Cygwin/MSys terminal.
> > > > >
> > > > > Without that, they have no choice but to think that
> > > > > stdin is redirected from a named pipe.
> > > > >
> > > > > Signed-off-by: Mihail Konev <k@ya.ru>
> > > > > Moved-from: https://github.com/Alexpux/mingw-w64/pull/3
> > > >
> > > > I don't really have any big objections other than on style.
> > >
> > > 1. This should be *strictly* non-Cygwin/non-MSYS.  Only native Windows
> > >applications will have a problem to recognize Cygwin ptys, thus this
> > >functions makes no sense at all for applications linked against
> > >Cygwin or MSYS.
> > >
> > > 2. Why include a non-standard API?  Why not provide this as isatty
> > >function as a replacement for the system isatty?  I'd wager your
> > >boots on this function going mostly unused, otherwise.
> >
> > MSYS2 will use it extensively.
>
> If MSYS2 uses it there's something wrong.  MSYS2 is Cygwin, so it
> doesn't need this function at all;  It has everything already builtin.
>
> Again:  Only non-Cygwin applications will need this function.
>
>
> Corinna
>
> 
> --
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH v5] Add include/iscygtty.c

2016-11-12 Thread Ray Donnelly

On Nov 12, 2016 1:30 PM, "Corinna Vinschen"  wrote:
>
> On Nov 12 12:27, JonY wrote:
> > On 11/12/2016 11:57, Mihail Konev wrote:
> > > Applications now could call iscygtty(STDIN_FILENO)
> > > in order to detect whether they are running from
> > > Cygwin/MSys terminal.
> > >
> > > Without that, they have no choice but to think that
> > > stdin is redirected from a named pipe.
> > >
> > > Signed-off-by: Mihail Konev 
> > > Moved-from: https://github.com/Alexpux/mingw-w64/pull/3
> >
> > I don't really have any big objections other than on style.
>
> 1. This should be *strictly* non-Cygwin/non-MSYS.  Only native Windows
>applications will have a problem to recognize Cygwin ptys, thus this
>functions makes no sense at all for applications linked against
>Cygwin or MSYS.
>
> 2. Why include a non-standard API?  Why not provide this as isatty
>function as a replacement for the system isatty?  I'd wager your
>boots on this function going mostly unused, otherwise.

MSYS2 will use it extensively.

>
>
> Corinna
>
>
--
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today. http://sdm.link/xeonphi
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today. http://sdm.link/xeonphi
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mingw64 gcc-6.1.0 hangs when compiling

2016-08-16 Thread Ray Donnelly

Hi Mario,

On Mon, Aug 15, 2016 at 11:29 AM, Mario Emmenlauer  wrote:
>
> Dear All,
>
> I don't know how/where to report this or how to debug the issue,
> please let me know what I can do. I tried upgrading protobuf to the
> new 3.0.0 release in Alexpux/MINGW-packages. However gcc hangs when
> compiling the tests, in file:
> https://github.com/google/protobuf/blob/master/src/google/protobuf/util/internal/protostream_objectsource_test.cc
>
> I've reported the issue in protobuf already here:
> https://github.com/google/protobuf/issues/1940
>
> However there was just the suggestion to try a different compiler.
> Can you please help me where to report this, and how to make a
> useful bug report?

Please use the MSYS2 creduce package to make a minimal test-case. It
works pretty well for this sort of thing, though you will need to do
some tricky shell code to make the shell script terminate the GCC
program after a certain amount of time, since it's an infinite loop
rather than a mis-compilation or internal compiler error.

Most likely it's a bug in GCC, so it may be worth looking around on
the GCC bugzilla bug tracker for any references to this problem.

Alternatively, try compiling MSYS2's mingw-w64-gcc-git package from
source (you may need to edit it to use the 6 branch and update it too)
using `makepkg-mingw` and see if the problem goes away. If so, we
could bisect to see what commit fixed the problem and port that across
to mingw-w64-gcc.

>
> All the best,
>
> Mario Emmenlauer
>
>
> --
> BioDataAnalysis GmbH, Mario Emmenlauer  Tel. Buero: +49-89-74677203
> Balanstr. 43   mailto: memmenlauer * biodataanalysis.de
> D-81669 München  http://www.biodataanalysis.de/
>
> --
> What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
> patterns at an interface-level. Reveals which users, apps, and protocols are
> consuming the most bandwidth. Provides multi-vendor support for NetFlow,
> J-Flow, sFlow and other flows. Make informed decisions using capacity
> planning reports. http://sdm.link/zohodev2dev
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] sqrt: Fix NaN propagation for IEEE Std 754-2008

2016-04-05 Thread Ray Donnelly

The R language has some hacks specifically for mingw-w64 that
were caused by our handling of NaNs in sqrt(x). R uses a
special valued NaN to mean 'Not Available' and expects it to
be retained through various calculations. Our sqrt(x) doesn't
do this, instead it normalises such a NaN (retaining sign).

From:

http://wwwf.imperial.ac.uk/~drmii/M3SC_2016/IEEE_2008_4610935.pdf

"6.2.3 NaN propagation

An operation that propagates a NaN operand to its result and
has a single NaN as an input should produce a NaN with the
payload of the input NaN if representable in the destination
format."

There might even be a slight speed-up from this too.

Thanks to Duncan Murdoch for finding the reference.
---
 mingw-w64-crt/math/sqrt.def.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

diff --git a/mingw-w64-crt/math/sqrt.def.h b/mingw-w64-crt/math/sqrt.def.h
index 2c5ed99..8e502ec 100644
--- a/mingw-w64-crt/math/sqrt.def.h
+++ b/mingw-w64-crt/math/sqrt.def.h
@@ -73,9 +73,8 @@ __FLT_ABI (sqrt) (__FLT_TYPE x)
   if (x_class == FP_ZERO)
return __FLT_CST (-0.0);
 
-  res = (signbit (x) ? -__FLT_NAN : __FLT_NAN);
-  __FLT_RPT_DOMAIN ("sqrt", x, 0.0, res);
-  return res;
+  __FLT_RPT_DOMAIN ("sqrt", x, 0.0, x);
+  return x;
 }
   else if (x_class == FP_ZERO)
 return __FLT_CST (0.0);
-- 
2.8.0


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] sqrt: Fix NaN propagation for IEEE Std 754-2008

2016-04-05 Thread Ray Donnelly

Here's the sqrt(x) NaN propgation patch again, this
time with a reference to the IEEE standard and as
a git patch.

If it's ok to commit, can someone go ahead?

Ray Donnelly (1):
  sqrt: Fix NaN propagation for IEEE Std 754-2008

 mingw-w64-crt/math/sqrt.def.h | 5 ++---
 1 file changed, 2 insertions(+), 3 deletions(-)

-- 
2.8.0


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH] Make sqrt(x=NaN) return x instead of sign(x) ? NaN : -NaN

2016-04-04 Thread Ray Donnelly

I ran into this while working on the R language. They have some hacks
[1] specifically for Windows to work around the fact that we normalise
our NaNs coming out of sqrt when then input was a NaN whereas none of
the other systems that R runs on do this (so at least glibc and OS X
libc and I guess some BSDs too).

The problem happens because R uses a special NaN value to mean "Not
Available" and that gets lost by this normalisation process.

Instead, just return the input value.

OKed by Kai on IRC.

[1] https://github.com/wch/r-source/blob/trunk/src/main/eval.c#L3756-L3761

--

Best regards,

Ray.
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] compiling from linux for windows 7

2015-12-30 Thread Ray Donnelly

On 30 Dec 2015 15:39, "lh_mouse"  wrote:
>
> Here is a ported, standalone version of nano for Windows. (Special thanks
to mingwandroid.)

I only did a small amount of work ages ago, but thanks for the mention.

> https://github.com/lhmouse/nano-win
>
> You can clone that repository then run ./BUILD_IT.sh as it already has
ncurses and libgnurx cloned.
>
> That nano-win can be compiled statically, with some features (e.g. spell
checker and ^Z) removed.
> Either Alt key works as Meta key.
>
>
>
> --
> Best regards,
> lh_mouse
> 2015-12-30
>
> -
> 发件人：JonY 
> 发送日期：2015-12-30 23:23
> 收件人：mingw-w64-public
> 抄送：
> 主题：Re: [Mingw-w64-public] compiling from linux for windows 7
>
> On 12/30/2015 21:38, frank wrote:
> > Ubuntu 14.04, mingw-w64 is installed from the repository. The package
to cross
> > compile to windows 7 64bit is in this case nano-2.5.0.
> >
> > Commands used:
> >
> > ./configure --host=x86_64-w64-mingw32
> > make
> >
> > The configure command exits successfully accepting the host and
indicating
> > x86_64-linux-gnu as target.
> >
> > But then make stops in error:
> >
> > x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -I..
> > -DLOCALEDIR=\"/usr/local/share/locale\" -DSYSCONFDIR=\"/usr/local/etc\"
> > -I/usr/include/ncursesw -g -O2 -Wall -MT files.o -MD -MP -MF
.deps/files.Tpo -c
> > -o files.o files.c
> > files.c:33:17: fatal error: pwd.h: No such file or directory
> >   #include 
> >
> > Now this is a mistery because pwd.h is in /usr/include which is always
on make's
> > search path (as last in the queue).
> >
> > Any idea what is happening and how it could be fixed?
> >
>
> You are compiling nano for Windows, pwd.h in /usr/include belongs to
> Linux, you cannot use that.
>
> As far as I know nano doesn't compile for native Windows, but if you
> must use it on Windows, there is a Cygwin version.
>
>
>
--
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
>
>
--
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC on mingw-w64

2015-10-03 Thread Ray Donnelly

On Sat, Oct 3, 2015 at 11:46 PM, FX  wrote:
>> MSYS2 distributes the gcc fortran package based on mingw-w64 (see the
>> output of pacman -Ss fortran). You can inspect how it is built by
>> consulting its PKGBUILD recipe. It is here, along with the necessary
>> patches: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gcc
>
> Thanks for the pointer. It’s sad that mingw has regressed, when GCC trunk 
> used to build perfectly with no patch and configure options.
>
> I’m trying now to force the build triplet to x86_64-w64-mingw32, rather than 
> the detected value (x86_64-pc-mingw64).
> So I have another question: which is the expected/canonical build triplet?

x86_64-w64-mingw32 and i686-w64-mingw32 are the correct ones. "pc" is
for old mingw.org AFAIK.

>
> FX
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] ./configure - and mingw-w64 confusion

2015-08-09 Thread Ray Donnelly

On Sat, Aug 8, 2015 at 8:37 PM, Duane Ellis du...@duaneellis.com wrote:

 It's built from this project (and branch, be careful to not use
 master!) on github:
 https://github.com/Alexpux/mingw-builds/tree/develop but as I say, you
 want canadian cross, and well, I'll not repeat what I wrote before,
 I'd just encourage you to read it carefully.


 Actually Python just needs to be cross compiled in this case. It might
 work from mingw-builds, but likely not.



 That is _THE_ problem, python generally *blocks* all cross compilation the
 example is here:

 https://github.com/python/cpython/blob/master/configure.ac#L377

 Where the “configure” script specifically blocks this.

 yea, I could undo this - and let this pass - but they have or had a very
 specific reason to block this

 I don’t know what that reason is, could it be

  “it will not work - thus we block it

 Or
 “I don’t know if it will - so we block it”

 There is no indication behind the reasoning.


CPython can't be compiled to run on Windows using anything other than
MSVC without *major* changes. You could undo this first stumbling
block that you ran into but then you'd need to fix the 80-odd other
things that you'll run into after that which we've fixed up at:

https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python2
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3

 -Duane.


 --

 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] ./configure - and mingw-w64 confusion

2015-08-08 Thread Ray Donnelly

On Sat, Aug 8, 2015 at 6:22 PM, Duane Ellis du...@duaneellis.com wrote:
 HI,

 My ultimate goal is to build a number of “python enabled” instances of GDB 
 that run on Windows.
 (ie: ARM, MIPS, and a few other core types)

 I have a candian-cross setup on my linux box, it works great for everything 
 but the “python enablement” step.
 Reason:  Python is specifically not supported in a candian cross, the *only* 
 configuration is Linux and Cygwin Canadian crosses

It's worse than that: CPython can't be built to run on Windows using
any compilers other than MSVC and CPython don't seem to be very
interested in changing that, or accepting patches from people who are.


 That blocks me :-( pretty hard

 From what I see, Mingw-w64 has an instance of Python *AND* a Python Enabled 
 GDB

 And I think I can build what I need - however - I’m confused about what 
 mingw-64 is.

MinGW-w64 doesn't have an instance of Python or an instance of a
Python Enabled GDB since MinGW-w64 is a source-only project, more-or
less. I assume the builds you are talking about are the semi-official
mingw-builds ones, as they come with those things. That porting job
was something I initially did for the Google Android NDK (using
patches from Roumen Petrov as a base) and that Alexey Pavlov and I
worked on for mingw-builds. We continue to maintain the patches in the
MSYS2 project.


 My question is this:
 Where is the BASH shell for MingW-W64?

There isn't one. The closest you'll come is MSYS2, but that's for
Windows, not GNU/Linux. Wine-staging can run and build a fair amount
of MSYS2 now-a-days thanks to the dedicated efforts of Qian Hong and
other wine-staging developers.

 How do I do a “./configure” to setup GDB?


The Windows Google Android NDK is built cross-canadian on GNU/Linux.
If you download the NDK and look at the build scripts you should be
able to get something going. The version of Python in the NDK is a lot
older than the ones in mingw-builds and in MSYS2 (2.7.5 I think, it's
been ages since I looked at the NDK). We don't build MSYS2's
mingw-w64-python* packages cross-canadian either, but the patches have
a heritage going back to the NDK so there shouldn't be too many
problems in using our latest Python patches in that scenario. The
latest patches can be found at:

https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python2
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-python3

 Where can I get a bit more detail about this?


You can find me on #msys2 if you need any help with this.

 Thanks.




 --
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] ./configure - and mingw-w64 confusion

2015-08-08 Thread Ray Donnelly

On Sat, Aug 8, 2015 at 7:18 PM, Duane Ellis du...@duaneellis.com wrote:
 Thanks for the quick reply.

 MinGW-w64 doesn't have an instance of Python or an instance of a
 Python Enabled GDB since MinGW-w64 is a source-only project, more-or
 less. I assume the builds you are talking about are the semi-official
 mingw-builds ones, as they come with those things. That porting job
 was something I initially did for the Google Android NDK (using
 patches from Roumen Petrov as a base) and that Alexey Pavlov and I
 worked on for mingw-builds. We continue to maintain the patches in the
 MSYS2 project.


 Hmm - the main MingW-64 page pointed me to:

 This:
 http://www.mingw-w64.org/doku.php/download

 Picking the MingW-Builds:
 http://www.mingw-w64.org/doku.php/download/mingw-builds

 Which points to:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/


 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe/download

 That file was updated only a few days ago.

 This has Python, and a PY enabled version of GDB - what I am trying to do is
 reproduce that …  But with a number of “cross compilation” tools for arm,
 mips, aver, etc

It's built from this project (and branch, be careful to not use
master!) on github:
https://github.com/Alexpux/mingw-builds/tree/develop but as I say, you
want canadian cross, and well, I'll not repeat what I wrote before,
I'd just encourage you to read it carefully.


 How is that build created?

 -Duane.




 --

 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] ./configure - and mingw-w64 confusion

2015-08-08 Thread Ray Donnelly

On Sat, Aug 8, 2015 at 7:35 PM, Ray Donnelly mingw.andr...@gmail.com wrote:
 On Sat, Aug 8, 2015 at 7:18 PM, Duane Ellis du...@duaneellis.com wrote:
 Thanks for the quick reply.

 MinGW-w64 doesn't have an instance of Python or an instance of a
 Python Enabled GDB since MinGW-w64 is a source-only project, more-or
 less. I assume the builds you are talking about are the semi-official
 mingw-builds ones, as they come with those things. That porting job
 was something I initially did for the Google Android NDK (using
 patches from Roumen Petrov as a base) and that Alexey Pavlov and I
 worked on for mingw-builds. We continue to maintain the patches in the
 MSYS2 project.


 Hmm - the main MingW-64 page pointed me to:

 This:
 http://www.mingw-w64.org/doku.php/download

 Picking the MingW-Builds:
 http://www.mingw-w64.org/doku.php/download/mingw-builds

 Which points to:
 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/


 http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/installer/mingw-w64-install.exe/download

 That file was updated only a few days ago.

 This has Python, and a PY enabled version of GDB - what I am trying to do is
 reproduce that …  But with a number of “cross compilation” tools for arm,
 mips, aver, etc

 It's built from this project (and branch, be careful to not use
 master!) on github:
 https://github.com/Alexpux/mingw-builds/tree/develop but as I say, you
 want canadian cross, and well, I'll not repeat what I wrote before,
 I'd just encourage you to read it carefully.

Actually Python just needs to be cross compiled in this case. It might
work from mingw-builds, but likely not.



 How is that build created?

 -Duane.




 --

 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Universal CRT and Python support

2015-05-19 Thread Ray Donnelly

On Tue, May 19, 2015 at 9:27 AM, Alexpux alex...@gmail.com wrote:

 19 мая 2015 г., в 10:48, Ruben Van Boxem vanboxem.ru...@gmail.com
 написал(а):

 2015-05-19 9:22 GMT+02:00 Alexpux alex...@gmail.com:


 19 мая 2015 г., в 10:09, Ruben Van Boxem vanboxem.ru...@gmail.com
 написал(а):

 Additionally, there seem to be some misconceptions as to the number of
 different toolchains available, I'll offer to straighten that out with him,
 and point him to the official builds we offer here. As to that, is there any
 (significant/important) difference between the MSYS2 builds and the official
 installer builds?

 Hi, Ruben!

 I’m always backport patches for Python 2/3 from MSYS2 to mingw-builds
 toolchains.
 From my point of view our Python patches will work with most mingw-w64
 toolchains without changes.


 Hi Alexey!

 How applicable are these patches to upstream Python? Would they break MSVC
 compatibility or do you think these can be merged quite cleanly?


Hi all,

Our patches weren't written with any testing on MSVC, expect failure.
The patches should be reordered so that support for building modules
using GCC (and linking to the MSVC compiled CPython dll and modules)
come first, and we should attempt to upstream those bits first. You'd
need a mingw-w64 that links to the UCRT (somehow) before this will
work.

Ray.

 Need to check deeper but we try to not break MSVC support in Python when
 this patches are written.


 I've posted a quick write-up reply to his understanding of the GCC on
 Windows situation:
 http://bugs.python.org/issue4709?@template=item#msg243563

 Let's hope this boost of momentum can be maintained :)

 Ruben

 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [ANN] Website changes

2015-03-24 Thread Ray Donnelly

On 24 Mar 2015 07:06, Adrien Nader adr...@notk.org wrote:

 Hi,

 On Sat, Mar 21, 2015, Norbert Pfeiler wrote:
  Hi,
  it’s nice to see an update on the website, looks good.
  What I’d like to see though, is a mention of msys2 in the downloads
  section.

 The difficulty with an msys2 entry on the page for downloads has so
 far been that it's not really like other download entries. There could
 be a new tab for tools but it might be not very visible (I'm not 100%
 happy with the current tab stuff on the download page but I think it's
 good enough for /now/). I'm definitely after ideas on how to properly
 organize things while remaining focused on the user (probably 99.99% of
 people use mingw-w64 through IDEs unlike 99.99% of the people on this
 mailing-list; and they tend to not look very far on a website).

Have you actually used MSYS2? It is very similar in scope to win-builds.


 --
 Adrien Nader


--
 Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub
for all
 things parallel software development, from weekly thought leadership
blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch]: Update netio and windot11 API headers

2015-01-16 Thread Ray Donnelly

On Fri, Jan 16, 2015 at 12:35 PM, Jacek Caban ja...@codeweavers.com wrote:
 Hi Ray,

 I'm sorry for the delay.

 On 01/12/15 21:41, Ray Donnelly wrote:
 We simply typedef it to int.  */
  typedef int MIB_TCP_STATE;

 +#include tcpmib.h

 MIC_TCP_STATE should be declared in tcpmib.h. Please move it there and
 include tcpmib.h on top of iprtmib.h, like other headers. Other parts of
 the patch looks good to me.


This was committed already, so I will make the new changes now and
post the patch here for review.

Thanks,

Ray.

 Thanks,
 Jacek

 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch]: Update netio and windot11 API headers

2015-01-12 Thread Ray Donnelly

On Mon, Jan 12, 2015 at 6:44 PM, Ray Donnelly mingw.andr...@gmail.com wrote:
 On Thu, Jan 8, 2015 at 6:01 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Committed to master after review on IRC by Jacek.

 I removed _Field_size_part_ macro use, as noted by review of Jacek.

 Kai

 2015-01-08 17:33 GMT+01:00 Kai Tietz ktiet...@googlemail.com:
 Hi,

 Any comment on the attached changes? Ok for apply?


 We ran into some problems with this update.

 Please review the attached patch.


Updated (Jacek partially reviewed on IRC); replaces
https://sourceforge.net/p/mingw-w64/mailman/message/33227195/

Best regards,

Ray.

 Best regards,

 Ray.

 Regards,
 Kai

 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


0001-Fix-compilation-errors-since-Update-netioa-API.patch
Description: Binary data
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
www.gigenet.com___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [patch]: Update netio and windot11 API headers

2015-01-12 Thread Ray Donnelly

On Thu, Jan 8, 2015 at 6:01 PM, Kai Tietz ktiet...@googlemail.com wrote:
 Committed to master after review on IRC by Jacek.

 I removed _Field_size_part_ macro use, as noted by review of Jacek.

 Kai

 2015-01-08 17:33 GMT+01:00 Kai Tietz ktiet...@googlemail.com:
 Hi,

 Any comment on the attached changes? Ok for apply?


We ran into some problems with this update.

Please review the attached patch.

Best regards,

Ray.

 Regards,
 Kai

 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


0001-Fix-compilation-errors-since-Update-netioa-API.patch
Description: Binary data
--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
www.gigenet.com___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] asctime_r duplications

2015-01-07 Thread Ray Donnelly

On Wed, Jan 7, 2015 at 2:45 PM, Jon jon.for...@gmail.com wrote:
 Looks to be the issue behind my recent go build fail...

 $ pacman -Q | grep mingw
 mingw-w64-x86_64-binutils-git 2.25.r81689.f30b244-3
 mingw-w64-x86_64-bzip2 1.0.6-2
 mingw-w64-x86_64-cloog 0.18.1-3
 mingw-w64-x86_64-crt-git 4.0.0.4388.c7e4f8f-1
 mingw-w64-x86_64-gcc 4.9.2-2
 mingw-w64-x86_64-gcc-libs 4.9.2-2
 mingw-w64-x86_64-gmp 6.0.0-2
 mingw-w64-x86_64-headers-git 4.0.0.4388.c7e4f8f-1
 mingw-w64-x86_64-isl 0.13-1
 mingw-w64-x86_64-libiconv 1.14-2
 mingw-w64-x86_64-libwinpthread-git 4.0.0.4370.d008dc5-1
 mingw-w64-x86_64-mpc 1.0.2-2
 mingw-w64-x86_64-mpfr 3.1.2.p11-1
 mingw-w64-x86_64-winpthreads-git 4.0.0.4370.d008dc5-1
 mingw-w64-x86_64-zlib 1.2.8-5


 C:\Apps\go-git [go_1.4 +8 ~0 -0 !] .\buildall.ps1

 --- building for windows/amd64 platform

 # Building C bootstrap tool.
 cmd/dist

 # Building compilers and Go bootstrap tool.
 lib9
 libbio
 liblink
 cmd/cc
 cmd/gc
 cmd/6l
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\decodesym.o: In function 
 `asctime_r':
 C:/Apps/DevTools/msys32/mingw64/x86_64-w64-mingw32/include/time.h:238:
 multiple definition of
 `asctime_r'
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\data.o:C:/Apps/DevTools/msys32/mingw64/x86_64-w64-mingw32/include/time.h:238:
 first defined here
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\dwarf.o: In function `asctime_r':
 C:/Apps/DevTools/msys32/mingw64/x86_64-w64-mingw32/include/time.h:238:
 multiple definition of
 `asctime_r'
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\data.o:C:/Apps/DevTools/msys32/mingw64/x86_64-w64-mingw32/include/time.h:238:
 first defined here
 ...SNIP...
 collect2.exe: error: ld returned 1 exit status
 go tool dist: FAILED: gcc -Wall -Wstrict-prototypes -Wextra -Wunused
 -Wno-sign-compare -Wno-missing-braces -Wno-parentheses
 -Wno-unknown-pragmas -Wno-switch -Wno-comment
 -Wno-missing-field-initializers -Werror -fno-common -ggdb -pipe
 -Wuninitialized -O2 -fmessage-length=0 -o
 C:\Apps\go-git\pkg\tool\windows_amd64\6l.exe -m64
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\data.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\decodesym.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\dwarf.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\elf.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\go.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\ldelf.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\ldmacho.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\ldpe.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\lib.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\macho.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\pcln.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\pe.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\pobj.o
 C:\Users\Jon\AppData\Local\Temp\go9683.tmp\symtab.o C:\Us


You'll need to rebuild mingw-w64-headers from the PKGBUILD for now.

p.s. The MSYS2/MinGW-w64 go packages are AFAIK, under maintained, do
you think you could take a look at our PKGBUILD sometime to see if
it's correct / working well? I'm not asking you to adopt it, just to
kick the tyres once if you don't mind?

 On 1/7/15, Ray Donnelly mingw.andr...@gmail.com wrote:
 On Wed, Jan 7, 2015 at 11:45 AM, Dongsheng Song
 dongsheng.s...@gmail.com wrote:
 On Wed, Jan 7, 2015 at 7:33 PM, Jacek Caban ja...@codeweavers.com
 wrote:
 Hi Alexey,

 On 01/07/15 09:06, Alexey Pavlov wrote:
 Ladt changes to time functions lead to multiple definitions of
 asctime_r in some programs. For example,

 I just pushed a fixup:
 http://sourceforge.net/p/mingw-w64/mingw-w64/ci/9f52135b2fa1336d63cda12c502f1790797387fa

 I wonder why it didn't cause errors in my case...


 Thanks. It cause gcc build failure because more than one source file
 include time.h, then asctime_r got implemented more than once.

 Ditto, fixes problems on MSYS2. Alexey, can you re-package
 mingw-w64-headers as this problem will hit a lot of people very soon
 otherwise.


 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take
 a
 look and join the conversation now. http://goparallel.sourceforge.net
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is
 your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net

Re: [Mingw-w64-public] asctime_r duplications

2015-01-07 Thread Ray Donnelly

On Wed, Jan 7, 2015 at 11:45 AM, Dongsheng Song
dongsheng.s...@gmail.com wrote:
 On Wed, Jan 7, 2015 at 7:33 PM, Jacek Caban ja...@codeweavers.com wrote:
 Hi Alexey,

 On 01/07/15 09:06, Alexey Pavlov wrote:
 Ladt changes to time functions lead to multiple definitions of
 asctime_r in some programs. For example,

 I just pushed a fixup:
 http://sourceforge.net/p/mingw-w64/mingw-w64/ci/9f52135b2fa1336d63cda12c502f1790797387fa

 I wonder why it didn't cause errors in my case...


 Thanks. It cause gcc build failure because more than one source file
 include time.h, then asctime_r got implemented more than once.

Ditto, fixes problems on MSYS2. Alexey, can you re-package
mingw-w64-headers as this problem will hit a lot of people very soon
otherwise.


 --
 Dive into the World of Parallel Programming! The Go Parallel Website,
 sponsored by Intel and developed in partnership with Slashdot Media, is your
 hub for all things parallel software development, from weekly thought
 leadership blogs to news, videos, case studies, tutorials and more. Take a
 look and join the conversation now. http://goparallel.sourceforge.net
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Dive into the World of Parallel Programming! The Go Parallel Website,
sponsored by Intel and developed in partnership with Slashdot Media, is your
hub for all things parallel software development, from weekly thought
leadership blogs to news, videos, case studies, tutorials and more. Take a
look and join the conversation now. http://goparallel.sourceforge.net
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Remove the Macros of the time_r functions and replace them with actual functions

2014-11-11 Thread Ray Donnelly

On Tue, Nov 11, 2014 at 2:02 PM, Dongsheng Song
dongsheng.s...@gmail.com wrote:
 I think you need add 1 line like this:

 TODO: real thread safe implementation.


Why? msvcrt is thread safe already.

 On Tue, Nov 11, 2014 at 8:15 PM, Martell Malone martellmal...@gmail.com 
 wrote:
 Comments Suggestions and changes Welcome.

 Kind Regards
 Martell

 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] getpid issue

2014-11-07 Thread Ray Donnelly

On Fri, Nov 7, 2014 at 11:10 AM, Ozkan Sezer seze...@gmail.com wrote:
 On 11/7/14, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:
 2014-11-07 9:25 GMT+01:00 Ozkan Sezer seze...@gmail.com:

 On 11/7/14, Dongsheng Song dongsheng.s...@gmail.com wrote:
  If we define _POSIX_, then getpid (process.h) was hidden.
  Is it correct ?
 
  PS: MSVC 2012 is the last compiler which use _POSIX_, MSVC 2013 do not
  use _POSIX_ anymore.
  MSVC 2012/2013 guard getpid with !__STDC__.

 I believe (but not necessarily correct about iıt) that MSVC's _POSIX
 symbol is intended for diffrerent purposes, i.e. windows posix subsystem,
 and I believe that we are doing a wrong thing with having those _POSIX
 ifdefs in our headers..  Someone correct me if I'm wrong.


 I have no idea, but be aware at least one reference in GCC showed up:
 https://gcc.gnu.org/bugzilla/attachment.cgi?id=20034action=edit

 But maybe that's there exactly because _POSIX is in the MinGW-w64
 headers...

 I remember that they defined _POSIX only because mingw-w64 headers
 required it for certain declarations

Also, should we consider renaming _POSIX to _POSIX_SOURCE?


 --
 O.S.

 --
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

2014-11-03 Thread Ray Donnelly

On Mon, Nov 3, 2014 at 3:45 PM, Baruch Burstein bmburst...@gmail.com wrote:
 On Mon, Nov 3, 2014 at 2:37 PM, Ruben Van Boxem vanboxem.ru...@gmail.com
 wrote:

 2014-11-03 10:30 GMT+01:00 Baruch Burstein bmburst...@gmail.com:

 I am curious why only a few of the executables get prefixed versions? I
 just tried running a certain makefile with prefixed versions of the
 toolchain, and it failed looking for the prefixed versions of 'ar' and
 'windres'. Easily solvable (make a copy and prefix it), but I am still
 curious why some get it by default while others don't?


 Because this is a native toolchain. Native toolchains don't have
 everything prefixed. Your makefile shouldn't be using any prefixes, and just
 call the bare gcc etc. instead.


 a. Then why are some prefixed?
 b. Is there another way to determine in the makefile if compiling for x64 or
 x32 without using the compiler executable name?


To be pedantic, you'll never be running x32 on Windows:
http://en.wikipedia.org/wiki/X32_ABI


 --
 ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı

 --

 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mingw/msys configuration

2014-11-01 Thread Ray Donnelly

On Sun, Nov 2, 2014 at 1:19 AM, Greg Jung gvj...@gmail.com wrote:
 Hi guys,

 I am using mingw-w64 gcc v4.8.2 installed under the /mingw32 directory under
 mingw and I compile using msys/1.0 shell, or CMAKE from msys using MSYS
 Makefiles.
 I adopted this after installing from a recipe and found it worked more often
 than not in situations where plain mingw/msys (installed on same computer)
 failed.  So I've been pretty happy with things but as my projects get larger
 I need a better understanding of the general configuration and what gcc
 expects - especially the linker utilities.

 2 quick questions:
Is MSYS2 really neccessary to work with mingw-m64 compilers? I've managed
 OK with msys-1.0.

No, cmd.exe is enough to work with mingw-w64 compilers, or an IDE such
as QtCreator, CodeLite or Eclipse could be used. If you want a bash
command line, then MSYS2 is much better than MSYS.
Speaking for the core of MSYS2, it is forked from (and re-syncs
regularly with) current Cygwin which has ~15 years more bugfixes and
features applied to it than MSYS, it has 64bit support (so that dll
rebase issues practically vanish) and whereas make -jN (where N1)
fails often with MSYS1 it is reliable on MSYS2 (due to improvements to
the core of Cygwin).

With regard to the user-space programs, MSYS2 provides bleeding edge
versions of build tools such as bash, gnumake, perl, python, git, svn,
cmake, gyp etc.


   I tried to overlay the 4.9.1 gcc-tools distribution on a /mingw32 tree
 under my older mingw installation, but the failure of a configure (couldn't
 determine default exec file) indicates I may need to do something more:
 true? if so, what?

 -
   My current problem is from trying to make a shared library in
 graphicsMagick,
 this line is the first link attempt after compilation:
 bin/sh ./libtool  --tag=CC   --mode=link gcc -O2 -mtune=pentium3 \
  (more flags) \
  -L/local32/lib -o magick/libGraphicsMagick.la -rpath
 /build32/GM1.3.20share/lib \
   (long list of .lo files) \
   magick/magick_libGraphicsMagick_la-analyze.lo \
XXX..analyze.lo -lwebp -ltiff -lfreetype -ljpeg -lpng16 -lwmflite -lbz2
 -lxml2 -lz -lgdi32 -lm -lgomp -lpthread

 /bin/grep: /usr/local/lib/libpng16.la: No such file or directory
 /bin/sed: can't read /usr/local/lib/libpng16.la: No such file or directory
 libtool: link: `/usr/local/lib/libpng16.la' is not a valid libtool archive
 ---
   I'm guessing webp, freetype, jpeg and tiff were ready to load from the
 compiler tree, and png16 was the first library to get
 loaded from the library: -L/local32/lib=LDFLAGS  holds all of these but it
 went to search  in /usr/local/lib. ???.

You'll have to find someone with a better opinion of MSYS than I to
help you out with that, but you provide very much useful information
like the cmake command line or output log.

On MSYS2 you can benefit from prebuilt binaries for many programs,
tools and libraries, including most (if not all) of the ones you need.
As well as prebuilt binaries, the packaging system (a fork of
ArchLinux's Pacman) includes makepkg{,-mingw} which uses PKGBUILD
files to allow repeatable from-source builds. Without apologies for
attempting to speak for the other MSYS2 developers, we aim for MSYS2
to be to Windows what Homebrew is to OSX, roughly speaking.

We've got a few wrinkles to iron out concerning package updates, but
we are making progress on that. Even if you don't want to drink from
our precompiled kool-aid, using (and contributing to) the PKGBUILD
repositories will likely have good value for you.

Feel free to drop by #msys2 on oftc IRC, or ask questions on our
mailing list: https://sourceforge.net/p/msys2/mailman/msys2-users/

Best regards,

Ray.


 --

 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Mingw/msys configuration

2014-11-01 Thread Ray Donnelly

I'm tired, corrections inline:

On Sun, Nov 2, 2014 at 1:54 AM, Ray Donnelly mingw.andr...@gmail.com wrote:
 On Sun, Nov 2, 2014 at 1:19 AM, Greg Jung gvj...@gmail.com wrote:
 Hi guys,

 I am using mingw-w64 gcc v4.8.2 installed under the /mingw32 directory under
 mingw and I compile using msys/1.0 shell, or CMAKE from msys using MSYS
 Makefiles.
 I adopted this after installing from a recipe and found it worked more often
 than not in situations where plain mingw/msys (installed on same computer)
 failed.  So I've been pretty happy with things but as my projects get larger
 I need a better understanding of the general configuration and what gcc
 expects - especially the linker utilities.

 2 quick questions:
Is MSYS2 really neccessary to work with mingw-m64 compilers? I've managed
 OK with msys-1.0.

 No, cmd.exe is enough to work with mingw-w64 compilers, or an IDE such
 as QtCreator, CodeLite or Eclipse could be used. If you want a bash
 command line, then MSYS2 is much better than MSYS.
 Speaking for the core of MSYS2, it is forked from (and re-syncs
 regularly with) current Cygwin which has ~15 years more bugfixes and
 features applied to it than MSYS, it has 64bit support (so that dll
 rebase issues practically vanish) and whereas make -jN (where N1)
 fails often with MSYS1 it is reliable on MSYS2 (due to improvements to
 the core of Cygwin).

 With regard to the user-space programs, MSYS2 provides bleeding edge
 versions of build tools such as bash, gnumake, perl, python, git, svn,
 cmake, gyp etc.


   I tried to overlay the 4.9.1 gcc-tools distribution on a /mingw32 tree
 under my older mingw installation, but the failure of a configure (couldn't
 determine default exec file) indicates I may need to do something more:
 true? if so, what?

 -
   My current problem is from trying to make a shared library in
 graphicsMagick,
 this line is the first link attempt after compilation:
 bin/sh ./libtool  --tag=CC   --mode=link gcc -O2 -mtune=pentium3 \
  (more flags) \
  -L/local32/lib -o magick/libGraphicsMagick.la -rpath
 /build32/GM1.3.20share/lib \
   (long list of .lo files) \
   magick/magick_libGraphicsMagick_la-analyze.lo \
XXX..analyze.lo -lwebp -ltiff -lfreetype -ljpeg -lpng16 -lwmflite -lbz2
 -lxml2 -lz -lgdi32 -lm -lgomp -lpthread

 /bin/grep: /usr/local/lib/libpng16.la: No such file or directory
 /bin/sed: can't read /usr/local/lib/libpng16.la: No such file or directory
 libtool: link: `/usr/local/lib/libpng16.la' is not a valid libtool archive
 ---
   I'm guessing webp, freetype, jpeg and tiff were ready to load from the
 compiler tree, and png16 was the first library to get
 loaded from the library: -L/local32/lib=LDFLAGS  holds all of these but it
 went to search  in /usr/local/lib. ???.

 You'll have to find someone with a better opinion of MSYS than I to
 help you out with that, but you provide very much useful information
* but you didn't provide
 like the cmake command line or output log.

 On MSYS2 you can benefit from prebuilt binaries for many programs,
 tools and libraries, including most (if not all) of the ones you need.
 As well as prebuilt binaries, the packaging system (a fork of
 ArchLinux's Pacman) includes makepkg{,-mingw} which uses PKGBUILD
 files to allow repeatable from-source builds. Without apologies for
* With apologies
 attempting to speak for the other MSYS2 developers, we aim for MSYS2
 to be to Windows what Homebrew is to OSX, roughly speaking.

 We've got a few wrinkles to iron out concerning package updates, but
 we are making progress on that. Even if you don't want to drink from
 our precompiled kool-aid, using (and contributing to) the PKGBUILD
 repositories will likely have good value for you.

 Feel free to drop by #msys2 on oftc IRC, or ask questions on our
 mailing list: https://sourceforge.net/p/msys2/mailman/msys2-users/

 Best regards,

 Ray.


 --

 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] icons?

2014-10-27 Thread Ray Donnelly

On Mon, Oct 27, 2014 at 7:38 PM, Mark Cianfaglione
m.cianfagli...@valydate.com wrote:
 On Mon, 2014-10-27 at 19:18 +0300, LRN wrote:

  Is there some way to distribute the icons with the application and how
  is it done?
 
  Mark
 
  The thing you are searching is a resource file (.rc).  By it you are
  able to distribute in image-file icons, bitmaps, animations, etc.  So
  please take a closer look to the windres tool, which is a
  resource-file compiler.
 

 I have a nagging suspicion that Mark uses GTK+ ('icon theme',
 'image-adjective-something' and 'hicolor' are very difficult for me to
 interpret in any other way). If that is so, the question should be directed 
 to
 gtk-list at gnome dot org.

 I think this would be specific to the Windows application. What I want
 to do is have the compiled program and associated DLLs packaged with
 NSIS to make a single file installer on any 64 Bit Windows 7/8 box.

 What I need to know is how to get the icons (what used to be the STOCK
 icons) as part of that package so that when the end user fires up the
 application they'll see the appropriate graphical bits.


AFAIK, you are still talking about GTK+ applications built within
MSYS2 here, so mingw-w64-public is definitely not a good place to
discuss it as many subscribers to mingw-w64-public do not use MSYS2,
so for them it's just noise. You are better off sending MSYS2 specific
questions to http://sourceforge.net/p/msys2/mailman/msys2-users/ or
else going onto the #msys2 OFTC IRC channel and asking there.

 Thanks

 Mark



 --
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] cannot execute binary file: Exec format error

2014-10-25 Thread Ray Donnelly

On Sat, Oct 25, 2014 at 1:47 PM, Mark Cianfaglione
m.cianfagli...@valydate.com wrote:
 Hi

 I'm using MSYS2 and Mingw-w64 on a Windows 7 64 bit system and I've got
 a situation where I've compiles a program that uses GTK3 but I get a
 cannot execute binary file: Exec format error when I try to execute
 it.

 I thought perhaps that my makefile was borked so I made a simple hello
 world using gtk3 and compiled it with the makefile and it works.

 I have a couple of other libraries that I'm linking to (libxls, xlslib,
 mariadb) but the code compiles with no major issues (a few gtk
 deprecation warnings) but otherwise it compiles cleanly.

 No I do have several large arrays of structs that I've got as global
 variables but I've got the exact same code running on a Linux x86_64
 system without any issues.

 I'm compiling the code base (including the libxls and xlslib) on the
 same machine in the same manner. Only the mariadb dll is not. But I
 believe it's all in 64 bits. (is there a way of checking this?)


From the MSYS2 shell enter
file /path/to/mariadb.dll

Have you tried using our GTK3 and mariadb packages (and/or PKGBUILDs)?

pacman -S mingw-w64-{x86_64,i686}-gtk3 mingw-w64-{x86_64,i686}-libmariadbclient

 What can cause the above error?

I really recommend building everything using the same (i.e. the MSYS2
provided) version of GCC and also using our packages where available.
Seems we don't have libxls/xlslib and would appreciate a contribution
of those:

https://sourceforge.net/p/msys2/wiki/Contributing%20to%20MSYS2/


 Any help would be appreciated.

 Mark





 --
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 2/2] localtime_r guard to _POSIX or _POSIX_THREAD_SAFE_FUNCTIONS

2014-10-21 Thread Ray Donnelly

On Tue, Oct 21, 2014 at 10:57 AM, JonY jo...@users.sourceforge.net wrote:
 On 10/21/2014 17:50, JonY wrote:
 On 10/21/2014 03:58, Ray Donnelly wrote:
 Comments welcome.

 Hi,

 Do you mind writing better comments for the patch? A single line
 followed by a blank line and then a longer description.


 Ignore the C11 part and mingw-w64-crt, a better description for git
 should be fine.


Thanks Jon,

For my patch, Comments welcome. wasn't the commit message :-)

From the patch itself:

commit message
localtime_r guard to _POSIX or _POSIX_THREAD_SAFE_FUNCTIONS

From http://www.unix.org/whitepapers/reentrant.html

This is accomplished in the standard by associating the reentrancy
specifications with a separate option, {_POSIX_THREAD_SAFE_FUNCTIONS},
which is declared to be mandatory for implementations supporting the
threads option

In pthread_unistd.h we define:

_POSIX_THREAD_SAFE_FUNCTIONS 200112L
/commit message

.. for the previous patch by Martell, perhaps I should add the
following comment:

Remove localtime_r from pthread.h which was a legacy hack for
compatibility with pthreads-win32. time.h is a more correct place for
localtime*, both for _POSIX compliance (
http://pubs.opengroup.org/onlinepubs/009695399/functions/localtime.html
) and MS for compatibility (
http://msdn.microsoft.com/en-us/library/bf12f0hc(v=vs.80).aspx ) 

Let me know and I'll get on it.

Best regards,

Ray.




 --
 Comprehensive Server Monitoring with Site24x7.
 Monitor 10 servers for $9/Month.
 Get alerted through email, SMS, voice calls or mobile push notifications.
 Take corrective actions from your mobile device.
 http://p.sf.net/sfu/Zoho
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 1/2] winpthreads: removed legacy time functions from pthread.h

2014-10-20 Thread Ray Donnelly

Thanks to Martell Malone.


0001-winpthreads-removed-legacy-time-functions-from-pthre.patch
Description: Binary data
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 2/2] localtime_r guard to _POSIX or _POSIX_THREAD_SAFE_FUNCTIONS

2014-10-20 Thread Ray Donnelly

Comments welcome.


0001-localtime_r-guard-to-_POSIX-or-_POSIX_THREAD_SAFE_FU.patch
Description: Binary data
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MinGW-W64 installation fails with 'ERROR res'

2014-10-14 Thread Ray Donnelly

On Tue, Oct 14, 2014 at 2:26 PM, Jose Alf. jose...@rocketmail.com wrote:

I would like to help to build a new installer. I suggest we use InnoSetup or
NSIS. I like InnoSetup because it's easier to mantain, but NSIS generates
smaller installer files. I can try to understand what the current installer
does, but it will go faster if you give me a summary.

Would it be possible to go with something Open Source and
build-able/built with MinGW-w64 such as:

http://sourceforge.net/projects/msys2/files/REPOS/MINGW/i686/mingw-w64-i686-qt-installer-framework-git-r2283.0d529d9-1-any.pkg.tar.xz/download
http://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/mingw-w64-x86_64-qt-installer-framework-git-r2283.0d529d9-1-any.pkg.tar.xz/download

Documentation is at:
http://qt-project.org/wiki/Qt-Installer-Framework

Example shell script and metadata files (used to create MSYS2 installers):

https://github.com/Alexpux/MSYS2-packages/tree/master/msys2-installer

Cheers,

Ray.

On Tuesday, October 14, 2014 7:57 AM, niXman i.nix...@autistici.org wrote:

Ruben Van Boxem 2014-10-14 16:47:

Well, I honestly don't really care what installer you use as long as it
works (that's why I brought it up now ;-)), but should you leave the
project suddenly for whatever reason (sickness, death, work, etc.),
there
would be no installer anymore. It would be logical that any project
member
could build such a thing by only downloading some free tools.
Additionally:
if it were only an update to the installer software that was needed,
everyone on the project could have updated it. But now the fix takes
longer
because it depends on a single person's personal access to commercial
software.

Don't get me wrong: your installer is better than no installer (and
worked
well before this issue popped up out of nowhere), but it is still
suboptimal for an open source project run and maintained by various
people.

I agree.

I have no time now to create another installer. I will be grateful to
you if you do this for the project, not for me ;)

--
Regards, niXman
___
Dual-target(32 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/
___
Another online IDE: http://liveworkspace.org/

--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Trying to build mingw, gcc misses include path

2014-10-02 Thread Ray Donnelly

On Thu, Oct 2, 2014 at 10:59 PM, Yaron Keren yaron.ke...@gmail.com wrote:
 Well, something went wrong with MSYS2. I uninstalled MSYS2 and reinstalled,
 now libmangle compiles and build goes on. Odd. I did encounter a problem
 before with MSYS2 while doing pacman -Syu, there were errors and the upgrade
 wasn't complete. Maybe that's releated. This time I did not pacman -Syu.


There's a problem in MSYS2 that when it updates DLLs of core packages
that pacman (or subsequently called post-install scripts) itself
depends on, those post-install scripts can fail to execute. If you
make a list of which packages failed, you can usually exit all your
MSYS2 shells, launch another one, then do:

pacman -S list-of-failed-packages

Yeah, that's really horrible and we need to fix it somehow.




 2014-10-02 18:00 GMT+03:00 Yaron Keren yaron.ke...@gmail.com:

 Hi,

 I am trying to build mingw-w64. I followed all steps from the README and

 git clone https://github.com/niXman/mingw-builds/ --branch develop

 ./build --mode=gcc-4.9.1 --buildroot=/c/mingw491 --rt-version=v3 --rev=1
 --bootstrap --jobs=2 --threads=posix --exceptions=dwarf --arch=i686
 --bin-compress

 ( the arguments were copied from build-info.txt of
 i686-4.9.1-release-posix-dwarf-rt_v3-rev1.7z )

 after gcc is built, it fails to compile libmangle since it does not find
 stdio.h. Running
 /c/mingw491/i686-491-posix-dwarf-rt_v3-rev1/mingw32/bin/g++ -E -x c++ - -v
  /dev/null

 results in:
 ...
 ignoring duplicate directory
 C:/mingw491/i686-491-posix-dwarf-rt_v3-rev1/mingw32/lib/gcc/../../../mingw32/lib/gcc/i686-w64-mingw32/4.9.1/include
 ignoring nonexistent directory
 C:/mingw491/i686-491-posix-dwarf-rt_v3-rev1/mingw32/mingw32/lib/gcc/i686-w64-mingw32/4.9.1/../../../../include
 ignoring duplicate directory
 C:/mingw491/i686-491-posix-dwarf-rt_v3-rev1/mingw32/lib/gcc/../../../mingw32/lib/gcc/i686-w64-mingw32/4.9.1/include-fixed
 ignoring nonexistent directory /mingw32/i686-w64-mingw32/include
 ignoring nonexistent directory
 C:/mingw491/i686-491-posix-dwarf-rt_v3-rev1/mingw32/mingw/include
 #include ... search starts here:
 #include ... search starts here:

 C:/mingw491/i686-491-posix-dwarf-rt_v3-rev1/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.9.1/include

 C:/mingw491/i686-491-posix-dwarf-rt_v3-rev1/mingw32/bin/../lib/gcc/i686-w64-mingw32/4.9.1/include-fixed

 C:/mingw491/i686-491-posix-dwarf-rt_v3-rev1/mingw32/lib/gcc/../../../mingw32/i686-w64-mingw32/include/c++

 C:/mingw491/i686-491-posix-dwarf-rt_v3-rev1/mingw32/lib/gcc/../../../mingw32/i686-w64-mingw32/include/c++/i686-w64-mingw32

 C:/mingw491/i686-491-posix-dwarf-rt_v3-rev1/mingw32/lib/gcc/../../../mingw32/i686-w64-mingw32/include/c++/backward
 ...

 So
 /c/mingw491/i686-491-posix-dwarf-rt_v3-rev1/mingw32/i686-w64-mingw32/include
 does not appear in any of the include directories, unlike the
 i686-4.9.1-release-posix-dwarf-rt_v3-rev1.7z from SF in which it of course
 appears.

 So, what am I doing wrong??

 Yaron



 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] mingw32-w64 32bit access violation under 32bit OS and under wow64 it works

2014-08-22 Thread Ray Donnelly

On Fri, Aug 22, 2014 at 4:14 PM, Stefan Ruppert s...@myarm.com wrote:
 Hi all,

 I have the following problem. I managed to compile our software which
 uses Qt 4.8.6 with g++ mingw32-w64 (rubenvb-4.7.2-release) in 32bit mode
 on a 64bit Windows 7 machine. All parts of our software runs correctly
 in wow64 and in a 32bit Windows 7 native environment except all
 applications which uses Qt.

 Any application which uses Qt works fine in wow64, but not in a 32bit
 native windows 7 environment. QtCore4.dll crashes with a access
 violation directly after loaded into memory (checked with dependency
 walker).

 Any idea what could cause this strange behaviour? I have no idea whats
 going wrong in native 32bit env...

My guess is it's an SSE exception running on hardware that doesn't support SSE3.


 Regards,
 Stefan


 --
 Slashdot TV.
 Video for Nerds.  Stuff that matters.
 http://tv.slashdot.org/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Slashdot TV.  
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MinGW-w64 + MSYS: g++ can't include files with unix style prefix?

2014-08-07 Thread Ray Donnelly

On Thu, Aug 7, 2014 at 8:42 PM, Richard Shaw hobbes1...@gmail.com wrote:
 I'm working on documenting how to build a project natively in windows, which
 first means figuring out the quirks myself and I ran into an issue with g++
 not being able to find headers with unix style paths /usr/local/include.

 My environment:
 Windows 7 32bit
 mingw-w64 from win-builds.org
 MSYS from the MinGW-w64 sourceforge page


 The project requires wxWidgets which I have building and installing fine
 with no tweaks. In order to determine C/CXX flags, linker requirements, etc,
 wxWigets provides a script wx-config that provides them. My project is cmake
 based (if it matters) and I'm using the built-in FindWxWidgets/UseWxWidgets
 modules for library and inclide directory detection (which uses wx-config on
 *nix systems).

 The problem occurs when I try to build my project:

 cd /C/Tools/Projects/freedv/src  /C/Tools/msys/opt/windows_32/bin/g++.exe
 -D
 HAVE_CONFIG_H -DSVN_REVISION=\1786M\ -D_FILE_OFFSET_BITS=64
 -D_NO_AUTOTOOLS_ -
 D__WXMSW__ -Wall -mthreads -g @CMakeFiles/freedv.dir/includes_CXX.rsp   -o
 CMake
 Files/freedv.dir/dlg_about.cpp.obj -c
 /C/Tools/Projects/svn/freetel/fdmdv2/src/d
 lg_about.cpp
 c:/Tools/Projects/svn/freetel/fdmdv2/src/dlg_about.cpp:21:22: fatal error:
 wx/ff
 ile.h: No such file or directory
  #include wx/ffile.h
   ^
 compilation terminated.

 The contents of includes_CSS.rsp:
 -IC:/Tools/Projects/freedv -Ic:/Tools/msys/local/include -isystem
 /usr/local/lib/wx/include/msw-unicode-static-3.0 -isystem
 /usr/local/include/wx-3.0 -Ic:/Tools/msys/local/include/codec2
 -IC:/Tools/Projects/svn/freetel/fdmdv2/src

 As you can see, most of the includes use the windows path, C:/Tools/...
 except the two wxWidgets entries use the unix style /usr/local, however,
 msys doesn't seem to have a problem:
 $ file /usr/local/include/wx-3.0/wx/ffile.h
 /usr/local/include/wx-3.0/wx/ffile.h: ASCII C++ program text, with CRLF line
 terminators

 If I change the /usr/local to c;/Tools/msys/local/include/wx-3.0 (and the
 same for the other) then compilation completes without error.

 Am I missing something obvious here? Isn't the whole point of msys is so
 that you can use unix style paths?

Yes, you are missing something here, whether it's obvious or not
depends on how long you've spent working with MSYS* and MinGW-w64.

MSYS will convert paths when it gets a chance to and thinks it should,
for example when calling a native Windows program like GCC. At that
time it will look through the command line and environment variables
with knowledge of the mount points and convert things that appear to
be path-y. However, you're using CMake here and it's emitted MSYS
paths into @response files (the .rsp files) and then native GCC has
been told to process those files, so MSYS doesn't get another chance
to transform them. Emitting stuff to a file isn't a good place to
transform paths because it's not known what tool will process those
files and it'd be horribly slow and break in a million different ways
if transformations were applied to all file IO.

My recommendation is to dump MSYS and use MSYS2 as it's way better (if
you do that you can use a huge amount of prebuilt libraries) but
otherwise figure out how to stop whatever version of CMake you are
using from using response files.


 Thanks,
 Richard

 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the future.
 http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Infragistics Professional
Build stunning WinForms apps today!
Reboot your WinForms applications with our WinForms controls. 
Build a bridge from your legacy apps to the future.
http://pubads.g.doubleclick.net/gampad/clk?id=153845071iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] fork is an inbuilt function?

2014-07-23 Thread Ray Donnelly

Hi Ruben,

Please take this in the friendly/jokey manner it is intended.

This isn't the first time you corrected me on the return value from
main when I'm making a test-case to demonstrate a compiler issue; I
honestly couldn't care less and my goal is to use the minimum amount
of characters and so following the standards doesn't come into it, but
if you feel you must point this out each time, I'll just consider it a
quirk and ignore it.

You are right, we should file it with GCC, but maybe I'll just look
into it an patch it.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 issues

2014-07-22 Thread Ray Donnelly

No, you didn't find any bug in MSYS2.

If you want MSYS2 path translation to happen then use an MSYS2
program, i.e. MSYS2 make, not mingw32-make.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 issues

2014-07-22 Thread Ray Donnelly

Yes, the shell that is run is the bash shell for MSYS2 make and
cmd.exe for mingw32-make, and there are some other differences about
the handling of 'special' characters. By default you should use MSYS2
make, unless you have a compelling reason not to.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] fork is an inbuilt function?

2014-07-22 Thread Ray Donnelly

Hello,

While porting msysGit to MSYS2/MinGW-w64 we ran into this:

$ PATH=/mingw64/bin:$PATH gcc --version
gcc.exe (Rev1, Built by MSYS2 project) 4.9.1

$ cat test.c
#include unistd.h
static inline pid_t fork(void);
void main() {}

$ PATH=/mingw64/bin:$PATH gcc test.c
test.c:2:21: warning: conflicting types for built-in function 'fork'
 static inline pid_t fork(void);
 ^

Anyone got any ideas about this?

Best regards,

Ray.

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] freeimage

2014-07-08 Thread Ray Donnelly

For hints and patches for building many packages with MinGW-w64, you
can look at MSYS2's PKGBUILD scripts. For FreeImage that'd be:

https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-FreeImage

.. I guess their mingw makefiles mean the other mingw project, hence
Alexey's patches for them.

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] freeimage

2014-07-08 Thread Ray Donnelly

That's not how you use patch. Please check the PKGBUILD file:

  patch -p1 -i ${srcdir}/FreeImage-3.16.0_mingw-makefiles.patch
  patch -p1 -i ${srcdir}/FreeImage-3.16.0_unbundle.patch
  patch -p1 -i ${srcdir}/FreeImage-3.16.0_disable-some-plugins.patch

also notice that we delete all the prebuilt libraries and instead use
MSYS2-built ones. This is because the prebuilt ones are no use having
been compiled with the other mingw.

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] freeimage

2014-07-08 Thread Ray Donnelly

If you are a complete win32 guy, I would suggest Visual Studio
Express Edition instead; unless you are trying change your ways :-)
FWIW, I wasn't really suggesting that you install MSYS2, just giving a
reference for how we build it with MSYS2/MinGW-w64.

Anyway, if you want to continue down this road that is fine. Pacman is
our package manager (ported from Arch Linux) that installs and updates
prebuilt binaries. makepkg (or makepkg-mingw) are the scripts that
make these packages. If you want to build FreeImage the MSYS2-way from
source code then you must use the MSYS2-provided compilers:

1. Install the installer.
2. Update as-per the Wiki (
https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/ ) -
basically pacman -Syu
3. Install base-devel, MinGW-w64 compilers and MinGW-w64: pacman -S
base-devel mingw-w64-x86_64-toolchain mingw-w64-i686-toolchain
4. Clone MINGW-packages: git clone https://github.com/Alexpux/MINGW-packages
5. Go to the right directory: cd MINGW-packages/mingw-w64-FreeImage
6. Build it: makepkg-mingw -s -L (-s will install necessary build- and
run-time dependencies, -L will save a log in-case anything goes
wrong).
7. Install the packages you just built: pacman -U mingw-w64-*.xz

After this, you will have source code, object files, some packages and
logs around for reference.

FreeImage is a package that Alexey did quite a lot of changes to so
that it uses other shared dependencies instead of bundling and
building the source code of its dependencies, but we think that given
a good build and packaging system like MSYS2 has, using shared
dependencies is the preferred approach.

.. MSYS2 really shines when developer-users provide us with PKGBUILD
files that re-use our pre-built binaries, so if the thing you need
FreeImage for is Open Source, then forking MINGW-packages, adding a
PKGBUILD for it and submitting a pull request via GitHub would be
welcomed.

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Poll] Move to git

2014-05-09 Thread Ray Donnelly

[X] Yes, move to git
[ ] No, continue with SVN

--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Where is the latest msys(2) download?

2014-05-07 Thread Ray Donnelly

msys2_shell.bat them prepend the path to your mingw-w64 onto PATH
On May 7, 2014 9:01 PM, Baruch Burstein bmburst...@gmail.com wrote:

 If I am using a separate mingw installation, which shell would I use?


 On Wed, May 7, 2014 at 9:52 PM, Alexpux alex...@gmail.com wrote:


 07 мая 2014 г., в 22:45, Baruch Burstein bmburst...@gmail.com
 написал(а):

 What is the difference between msys2_shell, mingw32_shell, mingw64_shell?


 If you want to use mingw toolchains from my pacman repository then you
 can use mingw*_shell scripts that switch PATH and some other variables to
 use 32 or 64 bit MINGW toolchains.
 Script msys2_shell just start normal MSYS session.

 Regards,
 Alexey.

 On Wed, May 7, 2014 at 9:44 PM, Baruch Burstein bmburst...@gmail.comwrote:

 Thank you.


 On Wed, May 7, 2014 at 9:38 PM, Alexpux alex...@gmail.com wrote:


 07 мая 2014 г., в 22:31, Baruch Burstein bmburst...@gmail.com
 написал(а):

 32-bit:
 msys2-base-i686-20140507.tar.xzhttp://sourceforge.net/projects/msys2/files/Base/i686/msys2-base-i686-20140507.tar.xz/download

 64-bit:
 msys2-base-x86_64-20140507.tar.xzhttp://sourceforge.net/projects/msys2/files/Base/x86_64/msys2-base-x86_64-20140507.tar.xz/download

 Also you need read
 https://sourceforge.net/p/msys2/wiki/MSYS2%20installation/

 Regards,
 Alexey.



 --
 ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find
 out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now

 http://p.sf.net/sfu/perforce___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find
 out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı




 --
 ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı
 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find
 out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now

 http://p.sf.net/sfu/perforce___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find
 out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı


 --
 Is your legacy SCM system holding you back? Join Perforce May 7 to find
 out:
 #149; 3 signs your SCM is hindering your productivity
 #149; Requirements for releasing software faster
 #149; Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
#149; 3 signs your SCM is hindering your productivity
#149; Requirements for releasing software faster
#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Register your vote (was Re: mingw-w64 may move to git in the future)

2014-05-02 Thread Ray Donnelly

I would like to register to vote. My usage of mingw-w64 comes from my
interest in MSYS2, Qt, general cross-compilers (crosstool-ng) and some
involvement with the Android NDK. I will have to update some scripts
if mingw-w64 changes from using SVN to git.

On Fri, May 2, 2014 at 12:02 PM, JonY jo...@users.sourceforge.net wrote:
 Calling all regular mingw-w64 users, for the benefit of all, let's run a
 poll on user opinions on the move.

 In order to qualify to vote, please state how you are using mingw-w64
 and how this change may affect you (what's your stake in it?). You may
 discuss compromises and workarounds. Registration will be open for 1
 week until 9th of May. Please speak up!

 As for the mingw-w64 developers, you need only show your SF user IDs
 when voting. As long as you have write access and have made at least 1
 commit with that ID, you get a vote.

 Voting will start once registration is closed and will last until the 16th.



 --
 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-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
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-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] [PATCH 1/1] Corrected lib32/d3d9.def file (against directx_Jun2010_redist.exe)

2014-04-13 Thread Ray Donnelly

Seems 3 imports were listed as C++ functions when they are plain C functions.

The attached patch corrects this.

Qt Creator 3.1.0-rc1 built with Qt-5.3.0-beta1 using Angleproject
could not resolve dll imports without this change.

Best regards,

Ray.
Index: lib32/d3d9.def
===
--- lib32/d3d9.def  (revision 6565)
+++ lib32/d3d9.def  (working copy)
@@ -1,5 +1,13 @@
-LIBRARY d3d9.dll
+;
+; Definition file of d3d9.dll
+; Automatic generated by gendef
+; written by Kai Tietz 2008
+;
+LIBRARY d3d9.dll
 EXPORTS
+Direct3DShaderValidatorCreate9
+PSGPError ; Check!!! Couldn't determine function argument count. Function 
doesn't return.
+PSGPSampleTexture@20
 D3DPERF_BeginEvent@8
 D3DPERF_EndEvent@0
 D3DPERF_GetStatus@0
@@ -10,7 +18,4 @@
 DebugSetLevel
 DebugSetMute
 Direct3DCreate9@4
-Direct3DCreate9Ex@8
-_Z30Direct3DShaderValidatorCreate9v=Direct3DShaderValidatorCreate9
-_Z9PSGPErrorP21D3DFE_PROCESSVERTICES11PSGPERRORIDj@12=PSGPError
-_Z17PSGPSampleTextureP21D3DFE_PROCESSVERTICESjPA4_fjS2_@20=PSGPSampleTexture
+Direct3DCreate9Ex@8
\ No newline at end of file
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH 1/1] Corrected lib32/d3d9.def file (against directx_Jun2010_redist.exe)

2014-04-13 Thread Ray Donnelly

Can someone with commit rights take care of this for us please?

Best regards,

Ray.

On Sun, Apr 13, 2014 at 5:35 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2014-04-13 17:52 GMT+02:00 Ozkan Sezer seze...@gmail.com:
 On 4/13/14, Ray Donnelly mingw.andr...@gmail.com wrote:
 Seems 3 imports were listed as C++ functions when they are plain C
 functions.

 The attached patch corrects this.

 Qt Creator 3.1.0-rc1 built with Qt-5.3.0-beta1 using Angleproject
 could not resolve dll imports without this change.

 Best regards,

 Ray.


 According to wine (wine/dlls/d3d9/), Direct3DShaderValidatorCreate9
 must be a stdcall like Direct3DShaderValidatorCreate9@0. According to
 wine again, several other exports in the def file are wrong too, e.g.
 stdcall funcs DebugSetMute@0, D3DPERF_EndEvent@0, D3DPERF_GetStatus@0,
 D3DPERF_QueryRepeatFrame@0, some of whose prototypes are actually
 available so easy to confirm. However PSGPError, PSGPSampleTexture,
 and DebugSetLevel are unknown. Many of these are undocumented, btw.

 --
 O.S.

 Such .def file changes are preapproved. Please apply.

 Regards,
 Kai

 --
 Put Bad Developers to Shame
 Dominate Development with Jenkins Continuous Integration
 Continuously Automate Build, Test  Deployment
 Start a new project now. Try Jenkins in the cloud.
 http://p.sf.net/sfu/13600_Cloudbees
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Sbuild update 4.1.1

2014-03-23 Thread Ray Donnelly

On Sun, Mar 23, 2014 at 1:11 AM, LRN lrn1...@gmail.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 S[mart|tupid] build[1] got a minjor update

 = About =

 sbuild is a set of scripts that build various free software packages for
 Windows from the source, starting with a GCC toolchain (cross-compiled)
 and MSYS2 core (cross-compiled), and ending with various applications
 (msys2-git, msys2-subversion, mingw-gdb), libraries and frameworks
 (GTK+, GNUnet, GStreamer). All buildscripts are written in
 simple-to-understand-style of POSIX shell language, and a few small
 utilities are in Python.

 = Release Highlights =

 == Package Of The Day ==

 Today's Package Of The Day is GtkParasite[2] - a GTK+ plugin for
 messing with GTK+ applications at runtime. With the advent of GTK+-3.x
 it's now more important than ever to be able to try out theming CSS
 without restarting applications, and GtkParasite does the job. It also
 has ridiculously cute logo (which in no way influenced my decision to
 make GtkParasite the Package Of The Day).

 == MSYS2 ==

 Not much has happened in MSYS2 land. Actually, no, some things did
 happen in upstream MSYS2 (new path mangling), but they didn't make it
 into 4.1.1, because i'm lazy.

Just as well you are lazy. There's a few remaining problems with the
new path mangling that we need to get fixed.

Btw, do you ever run MSYS2 or Cygwin on Wine .. AFAIK it doesn't work,
but I wondered if you knew more details about the issues? For MSYS2,
building it all on Linux through Wine is something I we want to try.


 Anyway, MinGW/MSYS console is now set to use UTF-8 by default via
 LANG=en_US.UTF-8. This fixes some bugs with printing UTF8 text via
 printf that i've discovered a few months ago.

 I've finally had enough of CPAN and switched Perl-vendor download
 location to Fedora repositories. Hopefully, i won't need to update
 Perl-vendor as often as i did simply to keep up with CPAN dropping off
 old package versions.

 A gross bug in one of the custom libxslt patches i've been applying
 was fixed (the patch wasn't mine, by the way), this should
 dramatically reduce the number of xsltproc-related docbuilding failures.

 msys2-p11-kit and its direct dependencies are now built a bit earlier.

 == MinGW ==

 MinGW-W64 didn't get any noteworthy updates, but winpthreads did get a
 patch that added a new pthreads function.

 Of note are updates to GNUTLS and libpng that fix security bugs.
 GNUTLS is particularly messy, as caused rtmpdump to need rebuilding,
 which caused libcurl to need rebuilding, which cause CMake to need
 rebuilding.

 There was an update to my GCC builds, which enabled pthreads in GCC.
 This ended up with me tagging sbuild 4.1, but i neglected to announce
 the update. Hence the minjor update this time.

 I've successfully built webkitgtk and Pidgin. Packages for those
 didn't make it into sbuild (but are available upon request), since i
 judged them to be too specialized; also, webkit alone takes HOURS to
 build...), but some of their dependencies did. In particular, i was
 told that PyGObject (Py2GObject, in this case) is awesome to have, so
 now sbuild builds it, and you can use GTK+-3.x from Python-2.x.

 Another notable addition is DBus (it passes the testsuite, but i'm
 still not sure how its usage in applications is going to play out).

 Added a script for updating Python EasyInstall package list (since
 sbuild used to screw it up, and now doesn't even touch it). Feels
 hackish, but hopefully it'll keep the damage to your Python
 installation minimal.

 Glib/GTK+ got some attention, which resulted in updates to some
 libraries in the G stack, and some patches (admittedly, one GTK+-3.x
 patch is experimental, and may cause memory leaks; it's better than
 crashing though, which is what happens without it).

 Finally, a string of spelling-related packages (aspell, enchant,
 gtkspell) is now built. They all work (tested this on gtkspell example
 app), and there's an English dictionary for aspell built and installed
 by default.

 == Issues known to be fixed ==

 gnome-doc-utils might fail to build with a message along these lines:
 xsltApplyStylesheet: saving to C/name may not be possible. This was
 fixed.

 == Issues for which nothing is known ==

 On one occasion gnome-doc-utils buildscript was reported to act in a
 manner similar to a fork bomb (!?!?), repeatedly (on restarts of the
 build process). Unable to reproduce, re-running the build from scratch
 seemed to have helped.
 No new reports of this bug.

 gobject-introspection might fail to generate stuff (failure at
 shutil.rmtree() in gdumpparser.py), especially on slow machines. Re-run
 the build from the last step.
 No new insights into this bug.

 xsltproc.exe from msys-xsltproc might segfault. Re-run the build from
 the last step.
 No new insights into this bug.


 = List of new packages =

 mingw-dbus-1-1.8.0-1
 mingw-gsettings-desktop-schemas-3.0-3.11.91-1
 mingw-json-glib-1.0-0.99.2-1

Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler

2014-03-20 Thread Ray Donnelly

On Thu, Mar 20, 2014 at 8:33 AM, Jim Michaels jmich...@yahoo.com wrote:

  but I thought that it was said here that the win32 version does not work
 with sjlj in a stable way - yet?


You've resurrected a month old thread with an email that is 100%
non-sequitur. At no point in this this thread has anyone mentioned
sjlj. Also, you are talking about some object or product without any
indication of what it is, nor who it was here who said that
about it. Would it be possible for you to connect the dots please?



 
 From: Kai Tietz ktiet...@googlemail.com
 To: mingw-w64-public@lists.sourceforge.net
 mingw-w64-public@lists.sourceforge.net
 Sent: Thursday, February 20, 2014 1:14 AM
 Subject: Re: [Mingw-w64-public] Sigh! Back To Microsoft Compiler

 2014-02-20 1:16 GMT+01:00 Ciro Cornejo ciro.corn...@wdc.com:
 Seriously? !!!



 Come on guys, this makes the compiler unusable.

 What?



 ...but as long as you're making a toy compiler, would you consider making
 one that does not support pthreads and so avoids this problem?


 Why we should make a compiler which doesn't support pthreads? pthreads
 is a user-library and it is up to you to use it or not.


 Thanks.



 Hi! Sorry for the interruption, but you may want to take at least a few
 seconds

 to look into some recent license changes for the software you're about to

 install.

 What license-changes?  Yes, winpthread uses a more liberal license for
 developers as other win32 based pthread libraries do.  So yes, it is a
 BSD license, and therefore you might need to mention that you are
 using is it.  This is just fair.



 Parts of the winpthreads library will be compiled into every binary file
 (EXE

 That isn't true.  First this applies only to gcc-version built with
 posix-threading model. For it, either it is linked in as shared
 library, or if you request it as static library.
 If you don't want to rely on posix-threading-model, then simply don't
 use it and choose a toolchain buiild with win32-threading mode (by the
 way the default configuration).

 I would advice you to look in more detail to license issues.  MS
 compiler has them, and gcc  mingw(-w64) do so too.  You will be
 wondering what other licenses you are using for just building a simple
 hello-world-application with mingw(-w64).  For getting an idea you
 might to take a look to the COPYING.MinGW-w64-runtime license.

 You seem to mix here the term free software with free for nothing
 software, and copy other people's work without acknowledge it.

 or DLL) you create. It's a necessary evil that is currently required in
 order to

 provide support for threads and concurrency in programs compiled by GCC.



 The license for winpthreads requires you to reproduce its text in every
 copy
 or

 substantial portion of the winpthreads library that you distribute. This
 means

 that even if you just want to distribute a single small executable,
 created
 with

 TDM-GCC (or any winpthreads-based GCC release), you must include a copy of
 that

 license.


 INAL, but in general you might be right.  If you want to be fair, you
 should need to mention other derived work you are using in your
 application too.  We see this pretty liberal, nevertheless people like
 you are showing to us that we might should reconsider about that.


 Check the license out in the file COPYING.winpthreads.txt, which will be

 Where you see COPYING.winpthreads.txt file?  It isn't part of
 winpthread.  We have there a file named COPYING.  I assume you are
 referring to that.

 Regards,
 Kai


 --
 Managing the Performance of Cloud-Based Applications
 Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
 Read the Whitepaper.
 http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



 --
 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/13534_NeoTech
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
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/13534_NeoTech

Re: [Mingw-w64-public] Building LLVM with mingw-w64

2014-03-17 Thread Ray Donnelly

Here's a WIP patch for 'better' exception handling, but I've not had
time to finish it (nor will I for a good while - hoping the LLVM/Clang
developers fix it all properly first). It's mostly based on other
peoples' work too, as-per the commit message .. you may find more up
to date stuff if you follow the links.

https://github.com/diorcety/crosstool-ng/blob/master/patches/llvm/head/160-Add-Win64-exception-handling.patch

The stage I got to was that it was emitting a weird mix of dw2 and SEH.

Caveat emptor.

On Mon, Mar 17, 2014 at 12:40 PM, Etienne Sandré-Chardonnal
etienne.san...@m4x.org wrote:
Dear Alexey,

I have problems compiling LLVM 3.3, but LLVM 3.4 compiles fine.
The issue with 3.4 occurs when linking my project compiled llvm libs.

I tried with the pre build libs from your link, and I get the exact same
error from the linker such as:

error: undefined reference to `__imp_EnumerateLoadedModules64'
error: undefined reference to `__imp_SymSetOptions'
etc...

Is there specific options to pass to gcc when linking with these binaries?

Thanks,

Etienne

You can try to get precompiled LLVM from MSYS2/pacman repository via MSYS2.
Or download it here:
https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/
But you also need download all necessary dependencies by hand in this case.

How we build it is here:
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-clang

Regards,
Alexey.

2014-03-17 12:49 GMT+01:00 Etienne Sandré-Chardonnal
etienne.san...@m4x.org:

Dear Alexey,

Thanks for the information.

Do you build this using mingw-clang or mingw-gcc?
I believe I will have to build it myself as things such as exception
handling or thread support make linking rarely work between mingw versions.

Regards,

Etienne

You can try to get precompiled LLVM from MSYS2/pacman repository via
MSYS2.
Or download it here:
https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64/
But you also need download all necessary dependencies by hand in this
case.

How we build it is here:
https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-clang

Regards,
Alexey.

--
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/13534_NeoTech
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] current way to printf a size_type and size_t?

2014-03-15 Thread Ray Donnelly

On Sat, Mar 15, 2014 at 11:59 PM, LRN lrn1...@gmail.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 16.03.2014 2:26, Jim Michaels wrote:
 my understanding is gcc uses size_t for both. I think there used ot
 be a %I or something like that for size_type, but not sure what it
 is now, since I have forgotten, and %I by itself seems to require a
 number of bits like %I64u. my memory is fuzzy. thanks.
 'z' is the size of size_t. I.e. %zu - size_t, %zd - ssize_t

 Note that this requires a compatible printf implementation (i.e. not
 msvcrt).


to enable this, pass -D__USE_MINGW_ANSI_STDIO=1 to gcc/g++

--
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/13534_NeoTech
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Ruben's Clang builds

2014-01-16 Thread Ray Donnelly

As a side question, what does Clang development have to do with MinGW64?
Aren't these actually competing projects?

Only if you take a narrow or literal view of what MinGW-w64 is. I
guess the name dates back to when the only open source toolchain worth
using was GCC. Good technology is worth playing with; LLVM fits into
that category and Clang is getting there on Windows too. For me
MinGW-w64 is about being able to compile and run as much open source
software on Windows as possible, preferably avoiding closed source at
every turn.

IMHO the only bad toolchain is a closed source toolchain - like the
one you built Clang with ;-)

On Tue, Jan 14, 2014 at 6:23 PM, Baruch Burstein bmburst...@gmail.com wrote:
On Tue, Jan 14, 2014 at 3:46 PM, Ruben Van Boxem vanboxem.ru...@gmail.com
wrote:

2014/1/14 Baruch Burstein bmburst...@gmail.com

I am trying to use the Win64 toolchain. I assume I need to unpack the
Clang into the same directory as one of your GCC builds? I tried it with the
4.8.0 release (regular, not seh or std::thread, from here
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Personal%20Builds/rubenvb/gcc-4.8-release/
), but when I ran `clang` I got a crash message that it can't start because
libgcc_s_sjlj-1.dll is missing.
Ruben?

Oh, in that case, know that C++ support is nonexistent (at least as far as
exceptions or the standard library go).

That is fine. I only need C support.

After playing with this for a while, I found that the process to build
Clang+LLVM from source on windows is much easier then it used to be (grab a
couple of SVN repos, run CMake, Open in VS, compile. Easy) so that is what I
ended up doing, and it works fine for me.

Thanks anyway.

As a side question, what does Clang development have to do with MinGW64?
Aren't these actually competing projects?

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Ruben's Clang builds

2014-01-13 Thread Ray Donnelly

You should try Clang 3.4 in MSYS2.

On Mon, Jan 13, 2014 at 9:34 PM, Baruch Burstein bmburst...@gmail.com wrote:
 I am trying to use Ruben's clang builds (clang 3.2). I unpacked the zip and
 ran `clang64env.cmd`. When I tried compiling a trivial c program, I get the
 error:
 fatal error: 'stdio.h' file not found
 Anyone (Ruben or other) know what the problem is/how to solve this?

 P.S. The reason I tried using Ruben's older builds and not the current
 official 3.4 Windows build is that I got the exact same error after using
 the 3.4 installer. I thought it was because the installer version was only
 for compiling from within VS.

 --
 ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı

 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Encoding problem with FILE macro

2014-01-11 Thread Ray Donnelly

Putting source files in anything but ascii folders is asking for
trouble. Lots of trouble. Just don't.

On Sat, Jan 11, 2014 at 2:38 PM, lh_mouse lh_mo...@126.com wrote:
 The problem happens with the encoding of the source file's path, not the 
 file's contents.
 Anyway I agree with you that it is a good habit to code in plain English. But 
 it is inevitable to involve the file's path in specific situations e.g. when 
 you use the assert() macro.

 2014-01-11
 lh_mouse


 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Why is MSYS2 Git so slow?

2013-12-31 Thread Ray Donnelly

I think someone should take the time to look at optimizing the file io in
cygwin as I expect that's the real cause of slowness in msys2 git.
On Dec 31, 2013 2:52 PM, Óscar Fuentes o...@wanadoo.es wrote:

 Óscar Fuentes o...@wanadoo.es writes:

  I was hoping to replace my MSYSGit install with MSYS2 + Git, but the
  later is 4x slower than the former. Same Git version (1.8.4), same
  command (git status, for example.)
 
  Why this difference?

 Maybe this patch is worth considering for MSYS2:

 https://sourceforge.net/p/mingw/bugs/1823/



 --
 Rapidly troubleshoot problems before they affect your business. Most IT
 organizations don't have a clear picture of how application performance
 affects their revenue. With AppDynamics, you get 100% visibility into your
 Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics
 Pro!
 http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Rapidly troubleshoot problems before they affect your business. Most IT 
organizations don't have a clear picture of how application performance 
affects their revenue. With AppDynamics, you get 100% visibility into your 
Java,.NET,  PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

2013-12-10 Thread Ray Donnelly

Hi,

Would it be possible to point me to these patches you've got? I'd like
to take a look.

Ray.

On Tue, Dec 10, 2013 at 4:57 AM, asmwarrior asmwarr...@gmail.com wrote:
 On 2013-12-10 12:46, Alexpux wrote:
 We provide only static library for zlib and it named «libz.a». Try to search…

 So, I guess it was still removed from the tool-chain before the release?

 No. It present.

 Oh, I found libz.a was there:

 i686-4.8.2-release-posix-dwarf-rt_v3-rev1\mingw32\i686-w64-mingw32\lib

 I'm sorry about my mistake!

 Yuanhui Zhang

 --
 Sponsored by Intel(R) XDK
 Develop, test and display web and hybrid apps with a single code base.
 Download it for free now!
 http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Project News | New Builds]

2013-12-10 Thread Ray Donnelly

Yes, that's what I was after, many thanks.

On Tue, Dec 10, 2013 at 1:43 PM, asmwarrior asmwarr...@gmail.com wrote:
 On 2013-12-10 20:53, Ray Donnelly wrote:
 Hi,

 Would it be possible to point me to these patches you've got? I'd like
 to take a look.

 Ray.
 Hi, Ray, do you mean my local patches to GDB when I build it under Windows 
 32bit?

 There are many, currently the most important ones, I think are those two:
 1, https://sourceware.org/bugzilla/show_bug.cgi?id=15559
 The patch in comment 8 
 (https://sourceware.org/bugzilla/attachment.cgi?id=7227action=diff)
 With this patch, I can let GDB to simulate a correct inferior call if the 
 inferior(debugee) is built from MinGW GCC version7.0.

 2,https://sourceware.org/bugzilla/show_bug.cgi?id=12127
 I have a patch to fix this crash issue (see comment 6).
 But I think I don't need this patch because it was fixed in GDB GIT HEAD 
 about two weeks ago(see comment 7).
 If you are still building GDB 7.6.2(release two days ago), I think you need 
 to packport the fix to GDB 7.6.2.
 The fix can be view in this link
 https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=38e1f2a7d503d8abd788456782287383e0a0cfe8

 All other patches are quite minor, such as
 * workaround performance issue 
 http://sourceware.org/bugzilla/show_bug.cgi?id=15412 (patch in comment 3)
 * Pierre Muller's patches to fix display of tabulation character for mingw 
 hosts, see https://sourceware.org/ml/gdb-patches/2013-11/msg00224.html

 Yuanhui Zhang




 --
 Sponsored by Intel(R) XDK
 Develop, test and display web and hybrid apps with a single code base.
 Download it for free now!
 http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building linphone gtk with MinGW-w64

2013-12-06 Thread Ray Donnelly

I'm not sure why you started another thread for basically the same
issue (building linphone).

.. nor why you are ignoring jon_y's advice in that thread:

Don't do that, use configure --host=i686-w64-mingw32 instead.

 configuring with  (change c++ to cpp in the c++ executable name) Don't which 
 to use.

cpp is the C Pre-Processor, it does not stand for C++; that's always
suffixed with either ++ or xx.

On Fri, Dec 6, 2013 at 1:48 PM,  wynfi...@gmail.com wrote:

 I found http://www.gtk.org that has a ms windows library that I will use when 
 building Linphone.  I've installed it in a directory for ms win32 specific 
 dev named
  /cygdrive/c/win-dev

 I am trying to confiure as follows:

 $  ./configure CC=/usr/bin/i686-w64-mingw32-gcc 
 CXX=/usr/bin/i686-w64-mingw32-c++.exe 
 CPPFLAGS=-I/cygdrive/c/win-dev/include LDFLAGS=-L/cygdrive/c/win-dev/lib


 Thread model: win32
 gcc version 4.8.2 (GCC)
 configure:3678: $? = 0
 configure:3667: /usr/bin/i686-w64-mingw32-c++.exe -V 5
 i686-w64-mingw32-c++: error: unrecognized command line option '-V'
 i686-w64-mingw32-c++: fatal error: no input files
 compilation terminated.
 configure:3678: $? = 1
 configure:3667: /usr/bin/i686-w64-mingw32-c++.exe -qversion 5
 i686-w64-mingw32-c++: error: unrecognized command line option '-qversion'
 i686-w64-mingw32-c++: fatal error: no input files
 compilation terminated.
 configure:3678: $? = 1
 configure:3698: checking whether the C++ compiler works
 configure:3720: /usr/bin/i686-w64-mingw32-c++.exe  
 -I/cygdrive/c/win-dev/include -L/cygdrive/c/win-dev/lib conftest.cpp  5
 configure:3724: $? = 0
 configure:3772: result: yes
 configure:3775: checking for C++ compiler default output file name
 configure:3777: result: a.exe
 configure:3783: checking for suffix of executables
 configure:3790: /usr/bin/i686-w64-mingw32-c++.exe -o conftest.exe  
 -I/cygdrive/c/win-dev/include -L/cygdrive/c/win-dev/lib conftest.cpp  5
 configure:3794: $? = 0
 configure:3816: result: .exe
 configure:3838: checking whether we are cross compiling
 configure:3846: /usr/bin/i686-w64-mingw32-c++.exe -o conftest.exe  
 -I/cygdrive/c/win-dev/include -L/cygdrive/c/win-dev/lib conftest.cpp  5
 configure:3850: $? = 0
 configure:3857: ./conftest.exe
 ./configure: line 3859:  2260 Segmentation fault  ./conftest$ac_cv_exeext
 configure:3861: $? = 139
 configure:3868: error: in `/cygdrive/c/win-apps/linphone/src/linphone':
 configure:3870: error: cannot run C++ compiled programs.
 If you meant to cross compile, use `--host'.


 configuring with  (change c++ to cpp in the c++ executable name) Don't which 
 to use.

  $ ./configure CC=/usr/bin/i686-w64-mingw32-gcc 
 CXX=/usr/bin/i686-w64-mingw32-cpp.exe 
 CPPFLAGS=-I/cygdrive/c/win-dev/include LDFLAGS=-L/cygdrive/c/win-dev/lib

 configure:3667: /usr/bin/i686-w64-mingw32-cpp.exe -V 5
 i686-w64-mingw32-cpp: error: unrecognized command line option '-V'
 configure:3678: $? = 1
 configure:3667: /usr/bin/i686-w64-mingw32-cpp.exe -qversion 5
 i686-w64-mingw32-cpp: error: unrecognized command line option '-qversion'
 configure:3678: $? = 1
 configure:3698: checking whether the C++ compiler works
 configure:3720: /usr/bin/i686-w64-mingw32-cpp.exe  
 -I/cygdrive/c/win-dev/include -L/cygdrive/c/win-dev/lib conftest.cpp  5


 I vaguely remember hearing something about the -V option causing problems, 
 but might be mistaken.

 --
 Sponsored by Intel(R) XDK
 Develop, test and display web and hybrid apps with a single code base.
 Download it for free now!
 http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 correct HOME setup

2013-11-13 Thread Ray Donnelly

I unify my windows home with my MSYS2 homes using mklink /D so that
e.g. C:\msys32\home\ray is a symlink to C:\Users\ray .. I haven't run
into any problems with this recently. msysgit didn't used to like
cloning to a folder within a symlink folder, but MSYS2 git is fine
with it.

Of course you'd need to copy the skeleton files into your Windows User
folder before destroying the original MSYS2 $HOME folder.

If there's any good reason not to do this then please tell!

On Wed, Nov 13, 2013 at 9:00 PM, Alexpux alex...@gmail.com wrote:

 14 нояб. 2013 г., в 0:56, Jon jon.for...@gmail.com написал(а):



 Jon@Black ~
 $ cd ~

 Jon@Black /home/Jon
 $ pwd
 /home/Jon


 Sorry, the above is not correct in the default case. The correct version is:

 Jon@Black ~
 $ cd ~
 -bash: cd: /home/Jon: No such file or directory

 Jon@Black ~
 $ pwd
 /c/Users/Jon

 My earlier experiments with HOME in msys2_shell.bat had created /home/Jon
 and populated it from /etc/skel. The creation of /home/Jon and use of
 /etc/skel didn't happen when I first started (and restarted) MSYS2 with the
 default.

 Look into your Windows environment variables.
 MyComputer-Properties

 If you have HOME variable then try to remove it and run MSYS again

 --
 DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
 OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
 Free app hosting. Or install the open source package on any LAMP server.
 Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
 http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



 --
 DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
 OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
 Free app hosting. Or install the open source package on any LAMP server.
 Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
 http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 discussions OT for this list?

2013-11-09 Thread Ray Donnelly

Arch is also my Linux distro of choice, so this is something I am very
much looking forward to using too.

(More) good work Alexey!

On Sat, Nov 9, 2013 at 6:46 PM, Jon jon.for...@gmail.com wrote:

 On Sat, Nov 9, 2013 at 12:11 PM, Alexpux alex...@gmail.com wrote:


 09 нояб. 2013 г., в 8:45, Jon jon.for...@gmail.com написал(а):

 After reviewing sbuild's use of MSYS2 artifacts to provide toolchains and
 then some


 https://www.gitorious.org/sbuild/sbuild/source/a8f47daae77bb2390843250fbe6445fed784d866:buildall.py#L33-149

 I have MSYS2 related questions for LRN, Alexey, and others on this list
 who may be involved with MSYS2 and care to provide feedback.

 That said, this ML is targeted to mingw-w64 issues rather than general
 issues best addressed at places like stackoverflow.

 My questions relate to assembling of a development toolkit similar to what
 I did when I was contributing to this project:


 https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L30-L68

 https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingwbuilds.rb

 I plan to do something similar for my buildlets pet project

 https://github.com/jonforums/buildlets

 but base the automated toolchain builds upon assembling a minimal set of
 MSYS2 artifacts (smaller than sbuild's and Alexey's full-featured MSYS2
 project) with nixMan and Alexey's official mingw-w64 toolchains for windows.


 Just now I work on creating MSYS2 repository based on ported Arch Linux
 pacman (package manager). In a week, I think, I upload repository to site
 and you can get only what you want. In next MSYS2 release I plan to add
 packman as package manager for MSYS2. Then you can update, install and
 uninstall MSYS2 packages from MSYS2 console when you need.



 Alexey, you continue to amaze :)

 My primary non-windows OS is Arch followed by Ubuntu Server. Hearing about
 your plans for a pacman port is, well, spectactular. I'm a bit speechless,
 but grinning ear to ear.

 I can't wait to play with your pacman + MSYS2 repo and see how I can
 integrate it into my powershell based buildlet pet project.

 Dammit...another very cool siren song to distract and consume free time ;-



 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models. Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and
 register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Syber Terrorist, please help!!

2013-11-08 Thread Ray Donnelly

Please leave and take care that the door doesn't hit you on the way out.

On Fri, Nov 8, 2013 at 10:41 PM, Incongruous incongru...@outlook.com wrote:
 My oh my, you are one of them, aren't you. Wait, what about MinGW, is MinGW
 a tentacle of Google?


 -Original Message-
 From: Ozkan Sezer
 Sent: Friday, November 08, 2013 3:09 PM
 To: mingw-w64-public@lists.sourceforge.net
 Subject: Re: [Mingw-w64-public] Syber Terrorist, please help!!

 On 11/8/13, Incongruous incongru...@outlook.com wrote:
 Please help me, a terrorist group calling themselves Google has invaded my
 computer. Every time I run IE11 it displays the web page of this abusive
 organization. Is there a way that Microsoft could provide some sort of
 protection against this kind of threat? Is there a way to stop this
 organization's political power from terrorizing our work/home computers?

 Please Microsoft, you are our only hope.


 Can someone please ban this guy?

 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models. Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and
 register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


 --
 November Webinars for C, C++, Fortran Developers
 Accelerate application performance with scalable programming models. Explore
 techniques for threading, error checking, porting, and tuning. Get the most
 from the latest Intel processors and coprocessors. See abstracts and register
 http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
November Webinars for C, C++, Fortran Developers
Accelerate application performance with scalable programming models. Explore
techniques for threading, error checking, porting, and tuning. Get the most 
from the latest Intel processors and coprocessors. See abstracts and register
http://pubads.g.doubleclick.net/gampad/clk?id=60136231iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2

2013-10-23 Thread Ray Donnelly

To work around this problem you can use 7z GUI to extract and it when
it asks if you want to overwrite the Python include files with a 0
byte sized one, say No to all.

On Wed, Oct 23, 2013 at 11:49 AM, Rainer Emrich
sf.rai...@emrich-ebersheim.de wrote:
 Am 22.10.2013 17:00, schrieb Alexey Pavlov:
 Yesterday snapshots contain errors that may cause errors during uncompress.
 Today I upload new snapshots that fix this issue

 There's a new issue concerning the include/python* directories. Please check 
 the
 archives.

 With tar tvf I get:

 .
 .
 .
 -rw-r--r-- alexey/None  795 2013-09-06 21:24 etc/xml/docbook5-xml.xml
 drwxr-xr-x alexey/None0 2013-10-21 12:30 include/
 drwxr-xr-x alexey/None0 2013-07-28 20:19 include/python2.7/
 -rw-r--r-- alexey/None45015 2013-10-21 18:09 include/python2.7/abstract.h
 -rw-r--r-- alexey/None 1099 2013-10-21 18:09 include/python2.7/asdl.h
 -rw-r--r-- alexey/None  230 2013-10-21 18:09 include/python2.7/ast.h
 -rw-r--r-- alexey/None  792 2013-10-21 18:09 include/python2.7/bitset.h
 -rw-r--r-- alexey/None  912 2013-10-21 18:09 
 include/python2.7/boolobject.h
 -rw-r--r-- alexey/None  922 2013-10-21 18:09 
 include/python2.7/bufferobject.h
 -rw-r--r-- alexey/None 1941 2013-10-21 18:09 
 include/python2.7/bytearrayobject.h
 -rw-r--r-- alexey/None 1152 2013-10-21 18:09 
 include/python2.7/bytesobject.h
 -rw-r--r-- alexey/None 2804 2013-10-21 18:09 
 include/python2.7/bytes_methods.h
 .
 .
 .
 .
 -rw-r--r-- alexey/None  953 2013-10-21 19:34 include/python3.3m/warnings.h
 -rw-r--r-- alexey/None 3027 2013-10-21 19:34 
 include/python3.3m/weakrefobject.h
 drwxr-xr-x alexey/None0 2013-10-21 12:30 include/
 drwxr-xr-x alexey/None0 2013-07-28 20:19 include/python2.7/
 hrw-r--r-- alexey/None0 2013-10-21 18:09 include/python2.7/abstract.h
 link to include/python2.7/abstract.h
 hrw-r--r-- alexey/None0 2013-10-21 18:09 include/python2.7/asdl.h link
 to include/python2.7/asdl.h
 hrw-r--r-- alexey/None0 2013-10-21 18:09 include/python2.7/ast.h link 
 to
 include/python2.7/ast.h
 hrw-r--r-- alexey/None0 2013-10-21 18:09 include/python2.7/bitset.h 
 link
 to include/python2.7/bitset.h
 hrw-r--r-- alexey/None0 2013-10-21 18:09 
 include/python2.7/boolobject.h
 link to include/python2.7/boolobject.h
 .
 .
 .

 Rainer


 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2

2013-09-15 Thread Ray Donnelly

It is because git follows the busybox method of having one executable
and symlinks to it for the all the various sub-commands.

symlinks and Windows don't go together for various reasons, so they
are dereferenced instead.

On Sun, Sep 15, 2013 at 3:56 PM, asmwarrior asmwarr...@gmail.com wrote:
 On 2013-9-9 17:25, Alexey Pavlov wrote:
 New MSYS2 snapshots:

 32-bit:x32-msys2-beta2-20130909.tar.xz 
 http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-beta2-20130909.tar.xz/download

 64-bit:x64-msys2-beta2-20130909.tar.xz 
 http://sourceforge.net/projects/msys2/files/Alpha-versions/64-bit/x64-msys2-beta2-20130909.tar.xz/download

 *Changes*:

 Updates:
  - sync with Cygwin sources;
  - rewrite msys2_shell.bat and mingw_shell..bat to use mintty by default;
  - gettext-0.18.3.1;
  - subversion-1.8.3;
  - vim-7.4.016.

 New added:
  - docbook-xml (4.1-5.0);
  - posix-manpages;
  - unzip-6.0;
  - zip-3.0.

 Regards,
 Alexey.


 I see there are a lot of exe files under libexec\git-core have the same file 
 size, does that by design? I extract msys2 by 7zip
 such as:

 git-prune.exe
 git-push.exe

 Oh, I see the same issue under 
 PortableGit-1.8.3-preview20130601\libexec\git-core which is based on msys1

 Yuanhui Zhang


 --
 LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
 1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
 Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13.
 http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/22/13. 
http://pubads.g.doubleclick.net/gampad/clk?id=64545871iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] 2.0.8 doesn't build gcc 4.8.0?

2013-09-05 Thread Ray Donnelly

For most projects that use it, mingw-w64 is grabbed from svn and the
releases are largely ignored.

Whether that's a good thing or not is another matter of course.

On Thu, Sep 5, 2013 at 3:17 PM, Roger Pack rogerdpa...@gmail.com wrote:
 On 9/5/13, Adrien Nader adr...@notk.org wrote:
 On Wed, Sep 04, 2013, Roger Pack wrote:
 Hello.
 Despite my not understanding it, for some reason with 2.0.8 I'm unable
 to build gcc 4.8.0, I get this output:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55706

 however, that should have been fixed in r4357, which should have
 been included in 2.0.8, so I'm at a bit of a loss.  Any ideas?
 (My first thought is...maybe once the VARIANT stuff stabilizes a new
 release would be possible?)  It'd be nice to get off svn.
 Thank you all.
 -roger-
 Hi,

 You need CRT from trunk.

 Actually the mainpage states Version 3.0 In trunk, and nearing release,
 has some Large File Support. Note that GCC-4.8.x requires at least r5437
 from trunk to support C++11 std::to_string. Earlier versions will not
 work. 

 Ok looking forward to future releases then :)
 -roger-

 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58041391iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Qt problem

2013-08-28 Thread Ray Donnelly

I'm not sure where you got such out of date information from.

On Qt Project's own download page ( http://qt-project.org/downloads )
you will see:
Qt 5.1.1 for Windows 32-bit (MinGW 4.8, OpenGL, 666 MB) (Info)
.. they've shipped mingw-builds' GCC with versions greater than 4.7
since at least 5.0.1 (if my memory is correct)

There's also Alexey's Qt-builds project should you want 64-bit and the
ability to build it all yourself:
http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/Qt-Builds/
https://github.com/Alexpux/Qt-builds


On Wed, Aug 28, 2013 at 5:56 PM, Incongruous incongru...@outlook.com wrote:
 It is my understanding that Qt only works with a maximum of 4.6.x release of
 GCC-32, thus Qt does not do well with MinGW64. If I am mistaken, some
 enlighten will make me so much very happy; otherwise, I would appreciate if
 you can tell me of a web page to download the 4.6.x version of GCC-32bit.
 Thanks in advance

 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Qt problem

2013-08-28 Thread Ray Donnelly

No problem.

One thing, if you do go down the route of building Qt using Qt-builds,
you should use MSYS2 instead of MSYS. The docs need updating with that
information as someone recently ran into a problem attempting to use
MSYS.

MSYS2 is at:
http://sourceforge.net/projects/msys2/files/Alpha-versions/

On Wed, Aug 28, 2013 at 7:31 PM, Incongruous incongru...@outlook.com wrote:
 nO!, mY bAd.
 I got the link correctly now.


 Thanks!

 -Original Message-
 From: Ray Donnelly
 Sent: Wednesday, August 28, 2013 1:46 PM
 To: mingw-w64-public@lists.sourceforge.net
 Subject: Re: [Mingw-w64-public] Qt problem

 I'm not sure where you got such out of date information from.

 On Qt Project's own download page ( http://qt-project.org/downloads )
 you will see:
 Qt 5.1.1 for Windows 32-bit (MinGW 4.8, OpenGL, 666 MB) (Info)
 .. they've shipped mingw-builds' GCC with versions greater than 4.7
 since at least 5.0.1 (if my memory is correct)

 There's also Alexey's Qt-builds project should you want 64-bit and the
 ability to build it all yourself:
 http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/Qt-Builds/
 https://github.com/Alexpux/Qt-builds


 On Wed, Aug 28, 2013 at 5:56 PM, Incongruous incongru...@outlook.com
 wrote:
 It is my understanding that Qt only works with a maximum of 4.6.x release
 of
 GCC-32, thus Qt does not do well with MinGW64. If I am mistaken, some
 enlighten will make me so much very happy; otherwise, I would appreciate
 if
 you can tell me of a web page to download the 4.6.x version of GCC-32bit.
 Thanks in advance

 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft
 technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


 --
 Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
 Discover the easy way to master current and previous Microsoft technologies
 and advance your career. Get an incredible 1,500+ hours of step-by-step
 tutorial videos with LearnDevNow. Subscribe today and save!
 http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] End of rubenvb builds

2013-07-13 Thread Ray Donnelly

 - package gnustep which will help test the objc toolchain

Have you seen http://www.cocotron.org/ too?

On Sat, Jul 13, 2013 at 12:22 PM, Adrien Nader adr...@notk.org wrote:
 Hi,

 On Fri, Jul 12, 2013, Jon wrote:
 On Fri, 12 Jul 2013 19:43:04 +0200
 Kai Tietz ktiet...@googlemail.com wrote:
  a) yes, b) yes (we need people in charge for that and doing this
  reliable), c) yes, we are actual in discussion with mingw-builds
  venture to go together (and/or co-operate more closely).
 
   Or say The current situation is fine; mingw-w64 doesn't need an 
   official toolchain.
 
  No, we should provide Windows native pre-build toolchain

 Fantastic. These days I don't get to contribute to OSS as much as I'd like, 
 but if it would be
 useful, I'll carve out time to test/provide feedback on any toolchain build 
 tool you and the
 mingw-builds team come up with.

 I'm fixated by easy-to-use port-like build automation tools that do the 
 typical cycle of

   download - verify - patch - configure - build - stage - package

 and am continuously toying with one of my own little monsters for building 
 common libs
 with mingw-w64:

   https://github.com/jonforums/buildlets

 So, I'm curious on what you guys are building and would like to help, even 
 if it's just easy-of-use
 testing of the build tool.

 Allow me to mention yypkg again:
   http://yypkg.org/mingw-builds/

 There are almost 70 packages, the website infrastructure is up, the
 package management is working and its infrastructure is up, the
 source-control infrastructure is also up.
 Everything is open and reproducible except for the download sources
 part for which I have a proper solution only since wednesday. The user
 aspect is documented and the packager one is partly-documented.

 If this gives a better idea of the current state, my TODO for this
 week-end and the next few days is:
 - update software to what has gotten in slackware-current
 - finish packaging sdl
 - package dbus
 - package ffmpeg
 - package gnustep which will help test the objc toolchain
 - patch bsdtar/libarchive to handle symlinks in packages more gracefully
   (symlinks if running with admin rights, junctions for dirs and copy
   for files otherwise; or something like that)
 (I'm trying to get sdl, dbus, ffmpeg and gnustep fairly quickly because
 they've been requested by people)

 PS: despite being named mingw-builds, this has nothing to do with the
 project on sf.net; mingw-builds is not a very specific name and I
 derived it from SlackBuilds: slackware's build scripts. (I plan on
 trying to find another name though)

 --
 Adrien Nader

 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)

2013-07-03 Thread Ray Donnelly

Please do as much as you can to aid the debugging process.

Can you provide these traces?

Also, can you try to bisect down to the first GCC that breaks this for you?
There have been a lot of GCCs between 4.7.1 and 4.8.0 (can you try with
4.8.1 now?)



On Wed, Jul 3, 2013 at 1:33 PM, Haroogan haroo...@gmail.com wrote:

  This is known problem. See
  https://bugreports.qt-project.org/browse/QTBUG-29099. It for Qt5 but
  for Qt4 is the same. You can't now use -O3 with mingw toolchains based
  on gcc-4.7.3+.
 I think you got me wrong there.
 I have no problems building the whole Qt (including QtCore) with -O3 flag.
 It builds just fine, and cc1plus.exe is not crashing.
 I'm saying that rather applications based on the resulting QtCore.dll
 are crashing, and the trace shows that this is because of QtCore.dll
 itself.
 Once again, rebuilding QtCore.dll with -O2 solves the issue: it stops
 crashing.

 Regards,
 Haroogan



 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

2013-06-19 Thread Ray Donnelly

Usually it's because Cygwin is usually a lot slower than native for IO
heavy operations. Projects (such as the Android NDK) that supply
Cygwin-based compilers usually try to migrate to native ASAP, viewing the
Cygwin-based tools as a stop-gap measure.


On Wed, Jun 19, 2013 at 2:05 PM, Corinna Vinschen vinsc...@redhat.comwrote:

 On Jun 19 14:36, Corinna Vinschen wrote:
  On Jun 19 16:01, LRN wrote:
   Cygwin emulates untyped linking (ln -s) by checking the type of the
   target and creating the link of the right type. If the target doesn't
   exist, you're screwed.
 
  Not really screwed.  But if the target doesn't exist, you have the
  choice between creating a file symlink or a directory symlink, and you
  just don't know what the target will be.
 
  If you create a dir symlink,
  and the later created target turns out to be a file or vice versa,
  the *native* tools will be screwed since the path resolution mechanism
  requires the symlink type to reflect the target type.
 
  Cygwin ignores the symlink type and resolve the symlink just by path, so
  in Cygwin all symlinks will work.

 Btw., this is one reason why I don't understand the desire to use native
 tools.  If you can get a working POSIXy build environment for free, why
 do you want to use native tools which only generate problems you could
 easily do without weird tweaks to the Cygwin DLL?!?


 Corinna


 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

2013-06-12 Thread Ray Donnelly

Ok, We're back to asking for a plugin with a clearly defined interface for
env. var and path translation; despite LRNs reasonable objections I think
it might be the only acceptable solution?

.. that way we can continue to speculate (as MSYS always has) about what's
a path and what isn't and also use the cygwin.dll unmodified.

Otherwise we're at an impasse.


On Wed, Jun 12, 2013 at 3:00 PM, Corinna Vinschen vinsc...@redhat.comwrote:

 On Jun 12 15:50, Alexpux wrote:
  среда, 12 июня 2013 г. в 14:47, Corinna Vinschen написал:
   On Jun 11 21:10, Алексей Павлов wrote:
MSYS includes the following changes to Cygwin to support using
 native Win32
programs:
1. Automatic path mangling of command line arguments and environment
variables to Win32 form on the fly for Win32 applications inside
 bash.exe
   
  
  
   That's a bash change which does not affect the underlying Cygwin/MSYS
 DLL.
  
  This is changes in Cygwin dll not in bash. See changes in path.cc,
 spawn.cc and new files msys.cc and is msys.cc

 You wrote it's a bash change.  As a bash change I can understand it, as
 a Cygwin change not so much.  This is pure speculating on the DLL side
 again.  You simply don't know exactly if something is a path and in what
 form the argument is used by the called application.  If in doubt, use
 cygpath.

2. Ability to change OSNAME with an environment variable (MSYSTEM) to
change it between MSYS and MINGW32 (so people can add to or fix MSYS
programs should they need to).
   
  
  
   Ditto.
  Cygwin dll function uname changes

 Sigh.

3. Conversion of output of native Win32 application output from
 Windows
line endings to Posix line endings - removing trailing '\r' symbol -
 in
bash.exe so that e.g. bb=$(gcc --print-search-dirs) works as
 expected.
   
  
  
   Ditto.
  Yes it is bash changes and they also can be integrated in Cygwin bash I
 think
 man dos2unix

4. Replaced Cygwin symlinks with copying (we can investigate an
 option for
mklink symlinks on Vista and above but this is a topic for
 discussion -
MSYS compliant software tend to work around most ln-as-cp issues when
possible anyway).
   
  
  
   I said my share about what I think of copying files when the
 application
   expects to get a symlink. It's wrong. It's dangerous. You still have
   the CYGWIN=winsymlinks:lnk and CYGWIN=winsymlinks:native or
   CYGWIN=winsymlinks:nativestrict options available when using Cygwin
   unchanged (http://cygwin.com/cygwin-ug-net/using-cygwinenv.html)
  
  
 
  Yes it dangerous but native symlinks work need elevated shell and OS
 Vista+

 Again, if you need a copy, use cp, not ln -s.  It's plainly a bug in the
 scripts or tools you're using, if they use ln -s (or symlink(2)) when
 called in a Mingw environment.  Neither of them must rely on symlinks.

   I'm not negative. I'm just defending the integrity of the Cygwin DLL.
  
   Again, I'm perfectly happy if you provide an MSYS2 distro containing
   special tools, like a tweaked bash and an entire, Mingw-centric
   toolchain arrangement, as long as you keep the underlying Cygwin DLL
   intact as provided upstream. Also, don't change the name of the DLL and
   the target name of the toolchain ({i686/x86_64}-pc-cygwin).
  
   Everyone would have an advantage of this:
  
   - There would be only one source of the underlying POSIX-providing DLL.
   Central repository, only one source to care about, no merging and
   tweaking hassle.
  
   - The DLL name stays intact, thus every tool built in and for the MSYS2
   environment would run in a Cygwin distro environment as well.
   - The toolchain name stays intact. You can just grab the latest gcc and
   binutils sources and build them for the upstream supported
   ${arch}-pc-cygwin target and it would create files running in both
   environments.
  
   - While the normal Mingw/MSYS2 user would not have to look into the
   Cygwin distro since the MSYS2 distro provides what he or she needs,
   the more demanding user of MSYS2 would have free access to all tools
   provided by the Cygwin distro with thousands of tools and applications,
   not to mention a fully function X server with X clients.
  
   That's all I'm trying to say. I don't see a good reason to change the
   Cygwin DLL. Use it as is and build your Mingw-targeting environment
   around it. I'm here to help if something doesn't work out as you need
   it. Maybe we find another, working solution, without having to fork
   Cygwin.

 Corinna

 --
 Corinna Vinschen
 Cygwin Maintainer
 Red Hat


 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

2013-06-11 Thread Ray Donnelly

I for one am hugely appreciative of all the hard work that Corinna, Kai,
redhat, the mingw-w64 team and also Alexey has put into both Cygwin and
MSYS2.

Cygwin and MSYS2 exist for different, mutually exclusive goals. Anything we
can reasonably do on MSYS2 (credits, thanks printed at each login,
explanations of where MSYS2 comes from and links to Cygwin etc) to make the
fork-pill easier to swallow, I'm sure Alexey will be happy to do (though I
can't speak for him of course!)

MSYS itself was a fork of Cygwin ages ago, and it's really showing its age.
If you accept that there's any value in MSYS, then I hope you can see the
need we in the MSYS using section of the mingw-w64 community have for an
updated versoin. As an example, we can't build Qt with MSYS because MSYS
Perl is at version 5.8.8. MSYS itself was badly fragmented by the msysgit
project which uses an even earlier version of MSYS than the latest one
which is also missing important tools such as install.exe and something
has to be done to improve this situation. Our hope is that MSYS2 can be
adopted by that project and that MSYS never rots as badly as it has done.

If we can get down to a proper technical discussion on what's different and
why, then we can maybe think about some way of working together?

So many thanks everybody for the hard work and dedication.




On Tue, Jun 11, 2013 at 12:43 PM, LRN lrn1...@gmail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 11.06.2013 15:26, Corinna Vinschen wrote:
  Hi Алексей,
 
  On Jun  8 01:56, Алексей Павлов wrote:
  2013/6/7 Corinna Vinschen wrote:
  A final note:  I'm not opposing the fork.  Under the GPL it's your
  perfect right to do so, as long as you adhere to the license
  requirements.  But that doesn't mean I have to understand it.  If the
  DLL and the tools are exactly the same and only differ by name, then,
  what's the point?  Wouldn't it make more sense to work with us on the
  Cygwin project instead?
 
  Some times ago we discuss about adding MSYS2 code to Cygwin on mingw-w64
  IRC. It would be more right way I think but I think you don't
 interesting
  in it. I'm right? That is why I create fork of Cygwin. But if it
 possible
  to support MSYS2 mode in Cygwin sources I think all be happy to not
 create
  many forks an so on.
 
  The problem is this.  So far I'm wondering what MSYS2 is about.

 MSYS is about mixing W32 tools (mingw-gcc, binutils) headers and
 libraries with *nixy (or cygwinny, if you prefer) buildtools and
 scripts, with the aim of building W32 libraries and applications.

 In Cygwin (or when running a real GNU system) you have to use a
 cross-compiler to build W32 binaries.
 In MSYS you don't have to. That's it.

  Granted, right now MSYS2 adds code which is entirely unacceptable for
  Cygwin.  For instance the symlink(2) function *copying* files, even
  recursively if the target is a directory.  I don't grok the reason for
  this.
 
  So here's a user or script innocently calling
 
ln -s /cygdrive/c/Windows /
 
  which is something I do often to have easier access to the Windows
  directory for certain tasks.  But I definitely don't want a copy of the
  Windows directory.  If it's about compatibility with native tools, the
  change still doesn't makes sense.
 
  - Either it's Cygwin/MSYS2 tools needing the symlink, then a Cygwin
symlinks works fine,
 
  - or you need a copy of a certain subtree, then you should have called
cp, rather than ln -s,
 
  - or you need a Windows symlink, then you should have created a
native symlink using the new Cygwin capability to create native
symlinks using the CYGWIN=winsymlinks:native{strict} setting.
 
  The latter would be much more feasible as default setting, while on old
  pre-Vista systems, it would be much more feasible to fail gracefully, or
  to use Cygwin's method to create a Windows .lnk file instead.

 Now that you know what MSYS is about, it should be obvious that crude
 symlink-by-copying is necessary to satisfy W32 tools, which cannot use
 cygwin symlinks or Windows .lnk files.
 Windows symlinks (when using NT 6 and newer) are fine (well, they are
 not POSIXly, but they may turn out to be better than dumb copying (for
 the purpose of using them when building software), i'll try to test that
 later), MSYS1 had no way of creating them, and thus this was not an
 option. Now it is an option, and maybe a good default too.

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

 iQEcBAEBAgAGBQJRtw15AAoJEOs4Jb6SI2CwJbMIALMwC7zDIHRjRpKlFX/Zuk6k
 kt6s1/mstnSK6+WJdN5H2BxO2bXfxSBZDSiiwLXxe0UmTkdqFejQoO0JXiUiGwdM
 ne8KBy4EAdL4hxiEfhyiJhmAdZoEXktJMrlCX5AdFP22EueSc97D1hy12zM8EiMr
 rPHVe/0hL5sJ2Yk9LE0eAghMwEMIrnicAIWuyi9hpMG9U3IFAUf6GFLkV8ocT3Ga
 LO+rDDhuLclwpAIJ7p1FX4BwIgnzbCyYxZ9u8rlRB16cntIaJkzwNuxLmYKRjlra
 ZqiZKxayenMQBhiF/Q1OMjOOCBdi4DGoppsDffVgnGvLGA6fQG7ZDcIW5vCZqbI=
 =iQw0
 -END PGP SIGNATURE-

Re: [Mingw-w64-public] MSYS2 GPL infringement (was Re: MSYS2)

2013-06-11 Thread Ray Donnelly

On Tue, Jun 11, 2013 at 1:25 PM, LRN lrn1...@gmail.com wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 11.06.2013 15:58, Ray Donnelly wrote:
  MSYS itself was badly fragmented by the msysgit
  project which uses an even earlier version of MSYS than the latest one
  which is also missing important tools such as install.exe and something
  has to be done to improve this situation. Our hope is that MSYS2 can be
  adopted by that project and that MSYS never rots as badly as it has done.
 Just to make sure that facts (or my interpretation of them, anyway) are
 on the table:

 The so-called msysGit project is somewhat misnamed. The git that they
 build and distribute is actually a mingw-git (that is, a W32 git built
 with mingw-gcc and not linked to msys-1.dll), which is achieved by
 heaping lots of W32-specific patches on top of upstream git. With parts
 of MSYS1 bundled in.


Yes I think of it as msys-with-git rather than an MSYS git.


 I'm not sure why they initially bundled MSYS1 with that git. They
 probably figured that without a *nix'y shell git doesn't feel git'ty. Or
 maybe git has mandatory shell scripts somewhere, and they needed bash to
 run them.

 mingw-git didn't exist back then (and they didn't switch to it later,
 when it appeared), so they had to update that bundled MSYS1 manually,
 and it went stale quickly as a result.

 Anyway, bundling a copy of MSYS1 wasn't enough for them, they also
 forked MSYS1 a bit (added partial unicode support, altered MSYS mangling
 to fit the needs of git better, etc).

 So far i haven't seen any arguments in favor of git being a W32
 application rather than MSYS application. I was able to build msys-git
 (true msys-git, built with msys-gcc and msys headers, linked to
 msys-1.dll) recently, and it worked well enough for me.

 With MSYS2 that is not even a problem anymore, since MSYS2 inherits
 everything Cygwin has (including a well-maintained version of git).
 Therefore i hope that msysGit will simply die.


My main argument for git remaining a native program is that for programs
that do a lot of file IO (compilers, git), native is faster than Cygwin,
usually by a big margin. If mingw-git supported native symlinks and MSYS2
did too (as you say, via Cygwin) then IMHO that would be the best scenario.
I agree however, that the msysGit project should divorce itself into
mingw-git and a crappy broken MSYS (which should then die). I guess they
had some essential shell script glue (hopefully) in the past, most of which
is probably now done in Perl.


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

 iQEcBAEBAgAGBQJRtxcsAAoJEOs4Jb6SI2Cwmr8H/3umAgeku/ModbMrJ39o2CAf
 c9+AfYLvYi9BaBA2BVSpOvqw4DwH+lE1N7Sf/v2dM/x/ufuPz/jSNWEJLSAEVAmW
 Jr9wUZzTSiQENCd5OiJBpJD68wOcF8wYVvI2f089uuPxDo7r+88FXHkNB6xm15xF
 7+ZKxm/6185KMFkupTKVkYU1PvyZwYFcWbxvyuynahcLyLk/Szf4ydJWsNHGUF/r
 V8gF/Rt33hbsqhCySHWygdR8HkUIBIDvczRwDN9PfcaDu01VuVjSG04TjVBfttjk
 R21ySWOW/Qd0AopjSw9ndhWsWnx/nhDe/awumJ4o4NlceN3XjdXjODceLnabXoY=
 =7sz2
 -END PGP SIGNATURE-


 --
 This SF.net email is sponsored by Windows:

 Build for Windows Store.

 http://p.sf.net/sfu/windows-dev2dev
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Is there a way to control the output file format of windres directly during building wx?

2013-06-04 Thread Ray Donnelly

You can setup wrapper scripts to do this sort of thing. Many projects take
this approach. Personally I prefer doing this and being able to use
multilib toolchains, but each to their own!

Sample contents would be something like:

#!/bin/bash
exec /mingw/bin/windres -F pe-i386 ${@}



On Tue, Jun 4, 2013 at 9:08 AM, Ruben Van Boxem vanboxem.ru...@gmail.comwrote:

 2013/6/4 zhangxinghai zxh19750...@163.com

  hello
 I find  there is no way to control the output file format of windres
 directly when I build wx.
 If I use mingw32-make under cmd,I must manually modify makefile.gcc,add
 rcflags to
 every windres command.
 If I use msys,I also have no way to directly do that using configure,
  ../../configure  --host=i686-w64-mingw32 --enable-shared --disable-debug
 --disable-monolithic
 --enable-unicode CXXFLAGS=-pipe -m32 fno-keep-inline-dllexport -Os
 LDFLAGS=-m32 CFLAGS=-m32
 RCFLAGS=-F pe-i386
 the basedll_version_rc.o's format is pe-x86-64,I can not find any windres
 flag in that make file controlling
 file format.So I think I must manually modify makefile .
 It is strange that RCFLAGS is not the standard flag in gcc like
 CXXFLAGS,LDFLAGS,CFLAGS etc,why Wx omit this flag?
 Or may be another method to reach the same result
 Thanks


 This is one of the reasons I am against multilib GCC: build systems don't
 know how to handle every tiny detail.

 I would strongly suggest using two seperate toolchains for 32 and 64-bit,
 which removes the problem, as everything will do the correct thing. No need
 for -m32 added everywhere, or anything else like RCFLAGS.

 Ruben







 --
 How ServiceNow helps IT people transform IT departments:
 1. A cloud service to automate IT design, transition and operations
 2. Dashboards that offer high-level views of enterprise services
 3. A single system of record for all IT processes
 http://p.sf.net/sfu/servicenow-d2d-j
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public




 --
 How ServiceNow helps IT people transform IT departments:
 1. A cloud service to automate IT design, transition and operations
 2. Dashboards that offer high-level views of enterprise services
 3. A single system of record for all IT processes
 http://p.sf.net/sfu/servicenow-d2d-j
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GDB version information for ruben vb build

2013-06-03 Thread Ray Donnelly

Hi Abir,

Qt Project official releases are currently using mingw-builds toolchain
releases which includes Python with pretty-printers. Also, mingw-builds
project build their own (comprehensive) Qt releases.

The toolchain that's likely to be used in 5.1.0 is (I think):

http://heanet.dl.sourceforge.net/project/mingwbuilds/host-windows/releases/4.8.0/32-bit/threads-posix/dwarf/x32-4.8.0-release-posix-dwarf-rev2.7z
.

The URL for mingw-builds Qt-builds releases is:





On Mon, Jun 3, 2013 at 5:47 AM, Abir Basak abirba...@gmail.com wrote:

 I was using build by Ruben for Mingw W64 for long times with Qt Creator
 IDE. However from version 2.7 onward it fails to debug using the gdb
 shipped by it. The reason is most likely that it fails to parse the gdb
 version information like GNU gdb (rubenvb-4.7.2-release)
 7.5.50.20120920-cvs (Or rather wrongly parses the gdb version as 4.7.2 and
 disables most of gdb features like python support :( )
 My question is , is there any guidelines for what gdb version string
 should look like?

 Thanks
 abir


 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite
 It's a free troubleshooting tool designed for production
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap2
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GDB version information for ruben vb build

2013-06-03 Thread Ray Donnelly

Sorry, gmail fail (Enter Key caused a Send rather than a newline..)

The URL for mingw-builds Qt-builds releases is:

http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/Qt-Builds/


On Mon, Jun 3, 2013 at 8:11 AM, Ray Donnelly mingw.andr...@gmail.comwrote:

 Hi Abir,

 Qt Project official releases are currently using mingw-builds toolchain
 releases which includes Python with pretty-printers. Also, mingw-builds
 project build their own (comprehensive) Qt releases.

 The toolchain that's likely to be used in 5.1.0 is (I think):


 http://heanet.dl.sourceforge.net/project/mingwbuilds/host-windows/releases/4.8.0/32-bit/threads-posix/dwarf/x32-4.8.0-release-posix-dwarf-rev2.7z
 .

 The URL for mingw-builds Qt-builds releases is:





 On Mon, Jun 3, 2013 at 5:47 AM, Abir Basak abirba...@gmail.com wrote:

 I was using build by Ruben for Mingw W64 for long times with Qt Creator
 IDE. However from version 2.7 onward it fails to debug using the gdb
 shipped by it. The reason is most likely that it fails to parse the gdb
 version information like GNU gdb (rubenvb-4.7.2-release)
 7.5.50.20120920-cvs (Or rather wrongly parses the gdb version as 4.7.2 and
 disables most of gdb features like python support :( )
 My question is , is there any guidelines for what gdb version string
 should look like?

 Thanks
 abir


 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite
 It's a free troubleshooting tool designed for production
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap2
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] GDB version information for ruben vb build (Ruben Van Boxem)

2013-06-03 Thread Ray Donnelly

It seems clear to me that you should submit a patch that fixes this to Qt
Project, and also if possible file the boost unit_test issue with the
mingw-builds project.


On Mon, Jun 3, 2013 at 9:56 AM, Abir Basak abirba...@gmail.com wrote:



  I was using build by Ruben for Mingw W64 for long times with Qt Creator
  IDE. However from version 2.7 onward it fails to debug using the gdb
  shipped by it. The reason is most likely that it fails to parse the gdb
  version information like GNU gdb (rubenvb-4.7.2-release)
  7.5.50.20120920-cvs (Or rather wrongly parses the gdb version as 4.7.2
 and
  disables most of gdb features like python support :( )
  My question is , is there any guidelines for what gdb version string
  should look like?
 

 I have just tried with

 x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb
 Qt Creator 2.7.1
 CMake 2.8.11

 on a clean system, to create a small test app

 #include iostream


 using namespace std;


 int main()

 {

 int i=4;

 int j= i+4;

 i = j-4;

 cout  Hello World!  endl;

 return 0;

 }


 built with

 cmake -DCMAKE_BUILD_TYPE=Debug

 mingw32-make

 and set a break point in Qt Creator at the i=j-4 line, and execution
 stopped. I could see the values of i and j displayed.

 What exactly are you doing and what fails?

 Remember to set up gdb and your toolchain in Tools-Options-BuildRun
 both under Compilers and Kits (set your sysroot and click on
 auto-detect for the Debugger line).

 Hope this helps,

 Ruben


 I did the same, However debugging does not  work :(
 What does NOT work =
  locals and expressions or stack windows does NOT automatically
 load/update on stepping. i.e each time you need to manually click reload
 full stack to see the updated values.
  Breakpoint  stepping does work.

 It did work (and still works) with Qt Creator 2.6.2 last, and not any
 release after that (i.e QtC 2.7.0, 2.7.1  2.8.0 beta)

  All version of QtC also works with mingw builds gdb.
 I presently do NOT use mingw builds as sometimes I get strange problems
 with that dual target build (specifically when I use it with
 boost.unit_test). I do NOT use Qt, I use Qt Creator just for my c++
 projects with cmake or generic makefile project.

 In the debugger log window it shows UNSUPPORTED GDB VERSION GNU gdb
 (rubenvb-4.8.0) 7.5.91.20130322-cvs
 If you look at the code which detect gdb version (extractGdbVersion
 in debuggerprotocol.cpp ) , it returns wrong gdb version as 4.8.0 rather
 than 7.5.91 , i.e. wrongly takes the version from bracketed gcc build
 information). Though that may or may not be the cause of problem.

 I have tested it with
   x86_64-w64-mingw32-gcc-4.8.0-win64_rubenvb.7z (and also 4.7.2 and others)
   QtC 2.7.1 (Build on 8th May 2013) QtC 2.7.0 and QtC 2.8.0 beta official
 builds
   On Windows 7 and Windows 8



  Thanks
  abir
 




 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite
 It's a free troubleshooting tool designed for production
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap2
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Windows GNU Make patches

2013-06-02 Thread Ray Donnelly

Hi Ruben.

For mingw builds the develop branches are best to track. AFAIK, all patches
needed for make have been merged upstream. But Alexey will know better...
On 2 Jun 2013 13:09, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:

 Hi everyone,

 I'm cleaning up my build scripts and including automated application of
 patches etc.

 I previously had an old cvs checkout of GNU make with some patches that
 seemed necessary to apply to have it work for everything. I'd like to
 rebase this to vanilla 3.82 with only the necessary changes.

 Would anyone have the patches laying around? I checked mingw-builds, and
 found these:
 https://github.com/niXman/mingw-builds/tree/master/patches/make

 But I seem to have a couple more:
 https://github.com/rubenvb/MinGW-w64-build-scripts/tree/master/patches

 Although I am not sure which were applied (which is one of the reasons I
 am cleaning this mess up).

 I also could not find any GNU make related build or patch stuff in the TDM
 source packages, although mingw32-make is part of the binary package.

 Thanks for any help!

 Ruben


 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite
 It's a free troubleshooting tool designed for production
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap2
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Windows GNU Make patches

2013-06-02 Thread Ray Donnelly

See I told you he'd know better!
On 2 Jun 2013 16:03, Алексей Павлов alex...@gmail.com wrote:




 2013/6/2 Ruben Van Boxem vanboxem.ru...@gmail.com

 Hi everyone,

 Hi, Ruben!


 I'm cleaning up my build scripts and including automated application of
 patches etc.

 I previously had an old cvs checkout of GNU make with some patches that
 seemed necessary to apply to have it work for everything. I'd like to
 rebase this to vanilla 3.82 with only the necessary changes.

 Would anyone have the patches laying around? I checked mingw-builds, and
 found these:
 https://github.com/niXman/mingw-builds/tree/master/patches/make



 But I seem to have a couple more:
 https://github.com/rubenvb/MinGW-w64-build-scripts/tree/master/patches

 Although I am not sure which were applied (which is one of the reasons I
 am cleaning this mess up).

 I also could not find any GNU make related build or patch stuff in the
 TDM source packages, although mingw32-make is part of the binary package.

 Thanks for any help!

 Ruben


 Some times ago GNU Make developers switch to git repository:
 http://git.savannah.gnu.org/cgit/make.git.
 For now MAKE cannot be build with configure script for MinGW because
 developers do many changes in last two months and fix configure scripts.
 Only batch file ca be used now for properly build MAKE with MinGW toolchain
 now.
 Our (mingw-builds project) last builds of GCC-4.8.1 contain latest MAKE
 from git. We apply on top of sources only two patches:
   -   make-linebuf-mingw.patch
   -   make-getopt.patch

 Regards,
 Alexey.


 --
 Get 100% visibility into Java/.NET code with AppDynamics Lite
 It's a free troubleshooting tool designed for production
 Get down to code-level detail for bottlenecks, with 2% overhead.
 Download for free and get started troubleshooting in minutes.
 http://p.sf.net/sfu/appdyn_d2d_ap2
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Get 100% visibility into Java/.NET code with AppDynamics Lite
It's a free troubleshooting tool designed for production
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://p.sf.net/sfu/appdyn_d2d_ap2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Python on x64

2013-04-18 Thread Ray Donnelly

Hi Felix,

I believe Ruben re-package the official Python releases at present (correct
me if I'm wrong)

Mingw-builds however build from source (heavily patched):

https://github.com/niXman/mingw-builds/tree/master/patches/Python-2.7.3

The source of those patches is my project at:

https://github.com/mingwandroid/crucifixion-freedom

...but this is usually more of a work area that feeds into other projects
(i.e. it's often broken - for example, since last night, it's setup to
build 2.7.4 but the patches for 2.7.4 are still in development - i.e.
broken).

Cheers,

Ray.

On Thu, Apr 18, 2013 at 1:09 PM, Felix Lelchuk felix.lelc...@gmx.de wrote:

 Hi,

 I need to build Python 2.7 for 64-bit Windows but I'm having a hard time
 compiling it.
 'configure' generates a Makefile unsuitable for Windows (maybe Cygwin?).
 I patched the Makefile and several other files, still new problems arise...

 However, there is a Python DLL shipped with Ruben's toolchain so maybe
 you know a recipe or maybe you've got some patches?
 What I need is the Python EXE, too and working distutils so I can
 compile and use NumPy/SciPy and other libraries.

 Best regards

 Felix Lelchuk


 --
 Precog is a next-generation analytics platform capable of advanced
 analytics on semi-structured data. The platform includes APIs for building
 apps and a phenomenal toolset for data science. Developers can use
 our toolset for easy data analysis  visualization. Get a free account!
 http://www2.precog.com/precogplatform/slashdotnewsletter
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Using Python and Mingw64

2013-03-23 Thread Ray Donnelly

Me neither, but it's fairly high on my priorities list to try to get
more of these patches merged.

On Sat, Mar 23, 2013 at 6:14 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 Op 23 mrt. 2013 19:11 schreef NightStrike nightstr...@gmail.com het
 volgende:



 On Thu, Mar 14, 2013 at 9:37 PM, Ray Donnelly mingw.andr...@gmail.com
 wrote:
  Hi Ruben.
 
  It would be great to have recruit you to the cause to get these merged.
  My
  experience in that regard has been a bit frustrating. I think the
  patches
  are split up reasonably, except for the huge ones from Roumen Petrov.
  Due to
  Alexey's mingwbuilds efforts, Qt 5.0.1 use this Python for their gdb.
 
  On bugs.python.org, the relevant numbers - last time I looked - were
  3754
  3871 16235 16291 and 16292. Roumen said he would split his patches up
  and
  resubmit but I've been too busy to track this recently. If you want
  commit
  access to my github project let me know:
 
  https://github.com/mingwandroid/crucifixion-freedom

 Have you guys been able to get python upstream to accept the patches?

 Sorry about the lack of stuff, but I must admit I can't find the time to
 hack on Python.

 Ruben



 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_mar
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_mar
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Using Python and Mingw64

2013-03-15 Thread Ray Donnelly

Hi Ruben.

It would be great to have recruit you to the cause to get these merged. My
experience in that regard has been a bit frustrating. I think the patches
are split up reasonably, except for the huge ones from Roumen Petrov. Due
to Alexey's mingwbuilds efforts, Qt 5.0.1 use this Python for their gdb.

On bugs.python.org, the relevant numbers - last time I looked - were 3754
3871 16235 16291 and 16292. Roumen said he would split his patches up and
resubmit but I've been too busy to track this recently. If you want commit
access to my github project let me know:

https://github.com/mingwandroid/crucifixion-freedom
 On 14 Mar 2013 15:28, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:

 Never mind, I found these:

 https://github.com/niXman/mingw-builds/tree/master/patches/Python-3.3.0

 I'll see if I can get these sorted out and stir the Python devs :)

 Ruben


 2013/3/14 Ruben Van Boxem vanboxem.ru...@gmail.com

 2013/3/13 Ray Donnelly mingw.andr...@gmail.com

 You could use my Python if you want:

 https://mingw-and-ndk.googlecode.com/files/python-2.7.3-win64.7z
 https://mingw-and-ndk.googlecode.com/files/python-2.7.3-win32.7z

 They were compiled using MinGW-w64 compilers. The mingwbuilds project
 also includes Python binaries built from the same patches.


 Have you considered pushing these upstream to the Python devs? Reading
 the build python with mingw bug report (
 http://bugs.python.org/issue3871) I see the devs willing to accept the
 changes, if split up properly.

 Now that I have switched to Python for my scientific stuff, it may be
 interesting to be able to compile Python myself. Could you give me a link
 to the patches used to build Python? Are there Python 3.x patches as well?

 Thanks,

 Ruben



 On Wed, Mar 13, 2013 at 12:15 PM, Theuns Heydenrych
 theunsheydenr...@gmail.com wrote:
  I feel that i am very near the point that it will work, but don't know
 what
  else to do.
 
  Any other suggestions?
 
 
  On Wed, Mar 13, 2013 at 9:52 AM, Václav Šmilauer e...@doxos.eu wrote:
 
  On 13/03/13 07:17, Theuns Heydenrych wrote:
   Hi, I know this is not a Python mailing list, but i am desperate.
   Someone in StackOverflow
   I am compiling Sip and PyQt from source using Mingw64 and Python
 2.7.3
   64bit.
   Python binaries is installed via downloaded installer, and is build
   with MSVC.
   I went through the exercise of making a libpython27.a file.
  
   Sip build successfully and work when used in a python console when
   using the following script
from sip import *
  
   and PyQt build successfully , but fails with a Python stop working
   Windows7 dialog , when the following script is used in the python
   console.
from PyQt4.Qt import *
  
   How do i debug this?
   Is it because Python is build with MSVC?
  
   Is it ok, to build things like Sip and PyQt with Mingw and gcc and
 it
   link against a MSVC Python27.dll?
  Hi,
 
  this is a recurrent topic unfortunately. You can built extensions to
  MSVC-compiled python with mingw, but the problem is the MSVC runtime
 you
  link to - msvcrt or msvcr90 etc. See my post
  http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/6306 (and
 the
  rest of that thread) for solution: change the MSVC dll disutils link
 to.
  I did build sip and pyqt4 (among others) successfully, it works
  flawlessly. (Building SIP was tricky with msys shell a bit.) You might
  want to check
  http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/6511 -
 there
  are build scripts and patches in the attachment which I used.
  http://bugs.python.org/issue16472 is upstream bug for this.
 
  HTH, Vaclav
 
 
 
 
 --
  Everyone hates slow websites. So do we.
  Make your web apps faster with AppDynamics
  Download AppDynamics Lite for free today:
  http://p.sf.net/sfu/appdyn_d2d_mar
  ___
  Mingw-w64-public mailing list
  Mingw-w64-public@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
 
 
 
 
 --
  Everyone hates slow websites. So do we.
  Make your web apps faster with AppDynamics
  Download AppDynamics Lite for free today:
  http://p.sf.net/sfu/appdyn_d2d_mar
  ___
  Mingw-w64-public mailing list
  Mingw-w64-public@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
 


 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_mar
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Using Python and Mingw64

2013-03-13 Thread Ray Donnelly

You could use my Python if you want:

https://mingw-and-ndk.googlecode.com/files/python-2.7.3-win64.7z
https://mingw-and-ndk.googlecode.com/files/python-2.7.3-win32.7z

They were compiled using MinGW-w64 compilers. The mingwbuilds project
also includes Python binaries built from the same patches.

On Wed, Mar 13, 2013 at 12:15 PM, Theuns Heydenrych
theunsheydenr...@gmail.com wrote:
 I feel that i am very near the point that it will work, but don't know what
 else to do.

 Any other suggestions?


 On Wed, Mar 13, 2013 at 9:52 AM, Václav Šmilauer e...@doxos.eu wrote:

 On 13/03/13 07:17, Theuns Heydenrych wrote:
  Hi, I know this is not a Python mailing list, but i am desperate.
  Someone in StackOverflow
  I am compiling Sip and PyQt from source using Mingw64 and Python 2.7.3
  64bit.
  Python binaries is installed via downloaded installer, and is build
  with MSVC.
  I went through the exercise of making a libpython27.a file.
 
  Sip build successfully and work when used in a python console when
  using the following script
   from sip import *
 
  and PyQt build successfully , but fails with a Python stop working
  Windows7 dialog , when the following script is used in the python
  console.
   from PyQt4.Qt import *
 
  How do i debug this?
  Is it because Python is build with MSVC?
 
  Is it ok, to build things like Sip and PyQt with Mingw and gcc and it
  link against a MSVC Python27.dll?
 Hi,

 this is a recurrent topic unfortunately. You can built extensions to
 MSVC-compiled python with mingw, but the problem is the MSVC runtime you
 link to - msvcrt or msvcr90 etc. See my post
 http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/6306 (and the
 rest of that thread) for solution: change the MSVC dll disutils link to.
 I did build sip and pyqt4 (among others) successfully, it works
 flawlessly. (Building SIP was tricky with msys shell a bit.) You might
 want to check
 http://permalink.gmane.org/gmane.comp.gnu.mingw.w64.general/6511 - there
 are build scripts and patches in the attachment which I used.
 http://bugs.python.org/issue16472 is upstream bug for this.

 HTH, Vaclav



 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_mar
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_mar
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Using Python and Mingw64

2013-03-13 Thread Ray Donnelly

Your cflags are wrong. Please run bin/python-config.sh --cflags (or
bin/python-config). You'll need to adjust the include paths.

In this instance, you are missing __USE_MINGW_ANSI_STDIO.

On Wed, Mar 13, 2013 at 1:03 PM, Theuns Heydenrych
theunsheydenr...@gmail.com wrote:
 Ray, Thanks for the downloads.
 When Compiling Sip i get the following error.

 C:\dev\sip-4.14.3mingw32-make
 mingw32-make[1]: Entering directory 'C:/dev/sip-4.14.3/sipgen'
 makefile:29: warning: overriding recipe for target '.c.o'
 makefile:26: warning: ignoring old recipe for target '.c.o'
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o main.o main.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o transform.o
 transform.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o gencode.o
 gencode.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o extracts.o
 extracts.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o export.o
 export.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o heap.o heap.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o parser.o
 parser.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I. -o lexer.o
 lexer.c
 g++ -mthreads -Wl,-enable-stdcall-fixup -Wl,-enable-auto-import
 -Wl,-enable-runtime-pseudo-reloc -Wl,-subsystem,console -Wl,-s -o sip.exe
 main.o transform.o gencode.o extracts.o export.o heap.o parser.o lexer.o

 mingw32-make[1]: Leaving directory 'C:/dev/sip-4.14.3/sipgen'
 mingw32-make[1]: Entering directory 'C:/dev/sip-4.14.3/siplib'
 makefile:29: warning: overriding recipe for target '.c.o'
 makefile:26: warning: ignoring old recipe for target '.c.o'
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
 -IC:\Python27\include\python2.7 -o siplib.o siplib.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
 -IC:\Python27\include\python2.7 -o apiversions.o apiversions.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
 -IC:\Python27\include\python2.7 -o descriptors.o descriptors.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
 -IC:\Python27\include\python2.7 -o qtlib.o qtlib.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
 -IC:\Python27\include\python2.7 -o threads.o threads.c
 gcc -c -O2 -w -DNDEBUG -DUNICODE -DQT_LARGEFILE_SUPPORT -I.
 -IC:\Python27\include\python2.7 -o objmap.o objmap.c
 In file included from C:\Python27\include\python2.7/Python.h:58:0,
  from sip.h:32,
  from objmap.c:23:
 C:\Python27\include\python2.7/pyport.h:232:9: error: #error This platform's
 pyconfig.h needs to define PY_FORMAT_SIZE_T
 makefile:29: recipe for target 'objmap.o' failed
 mingw32-make[1]: *** [objmap.o] Error 1
 mingw32-make[1]: Leaving directory 'C:/dev/sip-4.14.3/siplib'
 makefile:3: recipe for target 'all' failed
 mingw32-make: *** [all] Error 2


 On Wed, Mar 13, 2013 at 2:33 PM, Ray Donnelly mingw.andr...@gmail.com
 wrote:

 You could use my Python if you want:

 https://mingw-and-ndk.googlecode.com/files/python-2.7.3-win64.7z
 https://mingw-and-ndk.googlecode.com/files/python-2.7.3-win32.7z

 They were compiled using MinGW-w64 compilers. The mingwbuilds project
 also includes Python binaries built from the same patches.

 On Wed, Mar 13, 2013 at 12:15 PM, Theuns Heydenrych
 theunsheydenr...@gmail.com wrote:
  I feel that i am very near the point that it will work, but don't know
  what
  else to do.
 
  Any other suggestions?
 
 
  On Wed, Mar 13, 2013 at 9:52 AM, Václav Šmilauer e...@doxos.eu wrote:
 
  On 13/03/13 07:17, Theuns Heydenrych wrote:
   Hi, I know this is not a Python mailing list, but i am desperate.
   Someone in StackOverflow
   I am compiling Sip and PyQt from source using Mingw64 and Python
   2.7.3
   64bit.
   Python binaries is installed via downloaded installer, and is build
   with MSVC.
   I went through the exercise of making a libpython27.a file.
  
   Sip build successfully and work when used in a python console when
   using the following script
from sip import *
  
   and PyQt build successfully , but fails with a Python stop working
   Windows7 dialog , when the following script is used in the python
   console.
from PyQt4.Qt import *
  
   How do i debug this?
   Is it because Python is build with MSVC?
  
   Is it ok, to build things like Sip and PyQt with Mingw and gcc and it
   link against a MSVC Python27.dll?
  Hi,
 
  this is a recurrent topic unfortunately. You can built extensions to
  MSVC-compiled python with mingw, but the problem is the MSVC runtime
  you
  link to - msvcrt or msvcr90 etc. See my post
  http://article.gmane.org/gmane.comp.gnu.mingw.w64.general/6306 (and the
  rest of that thread) for solution: change the MSVC dll disutils link
  to.
  I did build sip and pyqt4 (among others) successfully, it works
  flawlessly. (Building SIP was tricky with msys shell a bit.) You might
  want to check
  http://permalink.gmane.org/gmane.comp.gnu.mingw.w64

Re: [Mingw-w64-public] 64bit Python bindings for libftdi1-1.0 with MinGW-w64

2013-02-19 Thread Ray Donnelly

There are mingw pythons around if you want to try that route?
On 19 Feb 2013 13:45, Xiaofan Chen xiaof...@gmail.com wrote:

 On Tue, Feb 19, 2013 at 5:22 PM, JonY jo...@users.sourceforge.net wrote:
  On 2/19/2013 08:12, Xiaofan Chen wrote:
  On Tue, Feb 19, 2013 at 6:12 AM, JonY jo...@users.sourceforge.net
 wrote:
  On 2/18/2013 22:56, Xiaofan Chen wrote:
  Ref:
 http://developer.intra2net.com/mailarchive/html/libftdi/2013/msg00137.html
 
  I am trying to build the 64bit Python (2.7.3 and 3.3) bindings for
  libftdi1-1.0 (
 http://www.intra2net.com/en/developer/libftdi/download.php )
  with MinGW-w64 (Ruben personal build 4.7.2 release).
  But somehow it does not work.
 
  I am trying using the instructions here.
 
 http://stackoverflow.com/questions/11182765/how-can-i-build-my-c-extensions-with-mingw-w64-in-python
 
  For 64bit Python 2.7.3, I did the following.
  1) gendef.exe python27.dll
  2) dlltool.exe --dllname python27.dll --def python27.def --output-lib
  libpython27.a
  3) Copy libpython27.a to C:\Python27\libs
 
  Strangely, gendef has already used Py_InitModule4_64 but I need
  to rename it back to Py_InitModule4 to get the Python binding build
  successfully.
 
  But the resultant Python bindings do not work. Just FYI,
  32bit Python binding works very well but I do not need
  to use gendef and dlltool there since the default 32bit
  Python windows binaries already provide the import
  library libpython27.a.
 
  That is because your def don't match the DLL, you just
  messed with it.
 
  The problem is that if I do not change the def file, I will
  have the following compile error.
 
 
  That is because you just made up your own symbol, there was no such
  symbol in the DLL. Changing the def file by hand is one way to cause
  programs to fail when linked to the import library.
 
  You should ask a python specific list for help on the Python programming
  language or Swig for help on Swig.
 
  I don't think this is mingw-w64 related anymore.

 Fair enough. For now I will try to patch libftdi1 to build under
 MSVC 2012 and see if I can get the 64bit Python binding build
 under VS2012.



 --
 Xiaofan


 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_feb
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Patch for widl Makefile rule bug when builddir!=srcdir

2013-02-12 Thread Ray Donnelly

Hi Jacek,

I hope this is ok now?

Best regards,

Ray.

On Mon, Feb 11, 2013 at 12:27 PM, Ray Donnelly mingw.andr...@gmail.com wrote:
 I think I took it as an opportunity to learn a tiny bit of automake
 having avoided it so far!

 Ho hum... an update is in progress.

 On Mon, Feb 11, 2013 at 10:58 AM, Jacek Caban ja...@codeweavers.com wrote:
 Hi Ray,

 Sorry for my response time too... Why don't you put the warning in
 configure.ac instead of Makefile? Also the warning could say something like
 --with-widl used in out of the tree compilation. Existing generated files
 won't be modified.

 Cheers,
 Jacek


 On 02/03/13 19:44, Ray Donnelly wrote:

 Hi Jacek,

 Sorry for the long response time.

 Please find attached a new version of the patch that adds the warning
 you mentioned.

 I also named it as .a txt file and removed all auto generated files.

 Best regards,

 Ray.

 On Mon, Jan 14, 2013 at 12:40 PM, Jacek Caban ja...@codeweavers.com wrote:

 Hi Ray,

 .idl.h: crt/_mingw.h
 -   $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include
 -I$(srcdir)/direct-x/include -Icrt -I$(srcdir)/crt -h -o $(srcdir)/$@ $
 +   $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include
 -I$(srcdir)/direct-x/include -Icrt -I$(srcdir)/crt -h -o $@ $


 The current code is indeed a hack, but it's intentional. Compiling with
 --with-widl is a maintainer-like mode and is supposed to change files in
 source directories.

 That said, --with-widl works best if ran in config where
 srcdir=builddir, because widl-generated comments look better then. We
 could change the way it works like you propose (so that if someone
 really wants widl-maintainer more, he is expected to build from srcdir),
 but for that I think we'd need a warning in configure when someone uses
 --with-widl and srcdir!=builddir.

 Thanks,
 Jacek

 --
 Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
 MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
 with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
 MVPs and experts. SALE $99.99 this month only -- learn more at:
 http://p.sf.net/sfu/learnmore_122412
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_jan



 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



 --
 Free Next-Gen Firewall Hardware Offer
 Buy your Sophos next-gen firewall before the end March 2013
 and get the hardware for free! Learn more.
 http://p.sf.net/sfu/sophos-d2d-feb
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Index: mingw-w64-headers/configure.ac
===
--- mingw-w64-headers/configure.ac  (revision 5586)
+++ mingw-w64-headers/configure.ac  (working copy)
@@ -34,6 +34,10 @@
 
 AM_CONDITIONAL([HAVE_WIDL],[AS_VAR_TEST_SET([WIDL])])
 
+if test ! $with_widl = no -a ! $srcdir = .; then
+AC_MSG_WARN([--with-widl used in out of the tree compilation. Existing 
generated files won't be modified.])
+fi
+
 # Checks for libraries.
 
 # Checks for header files.
Index: mingw-w64-headers/Makefile.am
===
--- mingw-w64-headers/Makefile.am   (revision 5586)
+++ mingw-w64-headers/Makefile.am   (working copy)
@@ -118,7 +118,7 @@
 BUILT_SOURCES = $(IDL_SRCS:.idl=.h)
 
 .idl.h: crt/_mingw.h
-   $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include -I$(srcdir)/direct-x/include 
-Icrt -I$(srcdir)/crt -h -o $(srcdir)/$@ $
+   $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include -I$(srcdir)/direct-x/include 
-Icrt -I$(srcdir)/crt -h -o $@ $
 
 endif
 
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Patch for widl Makefile rule bug when builddir!=srcdir

2013-02-11 Thread Ray Donnelly

I think I took it as an opportunity to learn a tiny bit of automake
having avoided it so far!

Ho hum... an update is in progress.

On Mon, Feb 11, 2013 at 10:58 AM, Jacek Caban ja...@codeweavers.com wrote:
 Hi Ray,

 Sorry for my response time too... Why don't you put the warning in
 configure.ac instead of Makefile? Also the warning could say something like
 --with-widl used in out of the tree compilation. Existing generated files
 won't be modified.

 Cheers,
 Jacek


 On 02/03/13 19:44, Ray Donnelly wrote:

 Hi Jacek,

 Sorry for the long response time.

 Please find attached a new version of the patch that adds the warning
 you mentioned.

 I also named it as .a txt file and removed all auto generated files.

 Best regards,

 Ray.

 On Mon, Jan 14, 2013 at 12:40 PM, Jacek Caban ja...@codeweavers.com wrote:

 Hi Ray,

 .idl.h: crt/_mingw.h
 -   $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include
 -I$(srcdir)/direct-x/include -Icrt -I$(srcdir)/crt -h -o $(srcdir)/$@ $
 +   $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include
 -I$(srcdir)/direct-x/include -Icrt -I$(srcdir)/crt -h -o $@ $


 The current code is indeed a hack, but it's intentional. Compiling with
 --with-widl is a maintainer-like mode and is supposed to change files in
 source directories.

 That said, --with-widl works best if ran in config where
 srcdir=builddir, because widl-generated comments look better then. We
 could change the way it works like you propose (so that if someone
 really wants widl-maintainer more, he is expected to build from srcdir),
 but for that I think we'd need a warning in configure when someone uses
 --with-widl and srcdir!=builddir.

 Thanks,
 Jacek

 --
 Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
 MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
 with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
 MVPs and experts. SALE $99.99 this month only -- learn more at:
 http://p.sf.net/sfu/learnmore_122412
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_jan



 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



 --
 Free Next-Gen Firewall Hardware Offer
 Buy your Sophos next-gen firewall before the end March 2013
 and get the hardware for free! Learn more.
 http://p.sf.net/sfu/sophos-d2d-feb
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Patch for widl Makefile rule bug when builddir!=srcdir

2013-02-03 Thread Ray Donnelly

Hi Jacek,

Sorry for the long response time.

Please find attached a new version of the patch that adds the warning
you mentioned.

I also named it as .a txt file and removed all auto generated files.

Best regards,

Ray.

On Mon, Jan 14, 2013 at 12:40 PM, Jacek Caban ja...@codeweavers.com wrote:
 Hi Ray,

 .idl.h: crt/_mingw.h
 -   $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include 
 -I$(srcdir)/direct-x/include -Icrt -I$(srcdir)/crt -h -o $(srcdir)/$@ $
 +   $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include 
 -I$(srcdir)/direct-x/include -Icrt -I$(srcdir)/crt -h -o $@ $


 The current code is indeed a hack, but it's intentional. Compiling with
 --with-widl is a maintainer-like mode and is supposed to change files in
 source directories.

 That said, --with-widl works best if ran in config where
 srcdir=builddir, because widl-generated comments look better then. We
 could change the way it works like you propose (so that if someone
 really wants widl-maintainer more, he is expected to build from srcdir),
 but for that I think we'd need a warning in configure when someone uses
 --with-widl and srcdir!=builddir.

 Thanks,
 Jacek

 --
 Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
 MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
 with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
 MVPs and experts. SALE $99.99 this month only -- learn more at:
 http://p.sf.net/sfu/learnmore_122412
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Index: mingw-w64-headers/Makefile.am
===
--- mingw-w64-headers/Makefile.am   (revision 5578)
+++ mingw-w64-headers/Makefile.am   (working copy)
@@ -118,10 +118,14 @@
 BUILT_SOURCES = $(IDL_SRCS:.idl=.h)
 
 .idl.h: crt/_mingw.h
-   $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include -I$(srcdir)/direct-x/include 
-Icrt -I$(srcdir)/crt -h -o $(srcdir)/$@ $
+   $(WIDL) -DBOOL=WINBOOL -I$(srcdir)/include -I$(srcdir)/direct-x/include 
-Icrt -I$(srcdir)/crt -h -o $@ $
 
+if SRCDIR_NEQ_BUILDDIR
+$(warning srcdir != builddir, debugging comments in idl files will be 
sub-optimal)
 endif
 
+endif
+
 _mingw_directx.h: $(srcdir)/crt/sdks/_mingw_directx.h.in
$(SED) s/MINGW_HAS_DX$$/@MINGW_HAS_DX@/ $  $@
 
Index: mingw-w64-headers/configure.ac
===
--- mingw-w64-headers/configure.ac  (revision 5578)
+++ mingw-w64-headers/configure.ac  (working copy)
@@ -10,6 +10,9 @@
 AM_INIT_AUTOMAKE([foreign])
 AM_MAINTAINER_MODE
 
+# Check so we can warn about this.
+AM_CONDITIONAL([SRCDIR_NEQ_BUILDDIR],[test ! $srcdir = $builddir])
+
 AC_CANONICAL_HOST
 
 # Checks for programs.
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingwbuilds-users] Qt 5.0.1 binary packages with MinGW-builds toolchain

2013-01-31 Thread Ray Donnelly

See:

http://dwarfstd.org/doc/DWARF4.pdf

APPENDIX E--DWARF COMPRESSION  DUPLICATE ELIMINATION (INFORMATIVE)

I've no idea what state they're in for GCC/GDB for Windows.

On Thu, Jan 31, 2013 at 2:31 PM, niXman i.nix...@gmail.com wrote:
 2013/1/31 Koehne Kai:
 the difference is actually in the debugging info: E.g. Qt5Guid.dll for MinGW 
 is a 131 MB big, while MSVC Qt5Guid.dll + Qt5Guid.pdb is just 24 MB.
 Wow оО

 Don't know whether the size of debugging info can  be reduced somehow?
 No, I don't know ..


 --
 Regards,
 niXman
 ___
 Dual-target(32  64-bit) MinGW compilers for 32 and 64-bit Windows:
 http://sourceforge.net/projects/mingwbuilds/
 ___
 Another online IDE: http://liveworkspace.org/

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_d2d_jan
 ___
 Mingwbuilds-users mailing list
 mingwbuilds-us...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingwbuilds-users

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_jan
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] msxml with mingw-w64 (for QuickFIX) (was: libxml2 with mingw-w64?)

2013-01-10 Thread Ray Donnelly

Just fix MSYS Autotooling for the whole thing and use libxml2!

;-)

On Thu, Jan 10, 2013 at 12:09 PM, pavel pa...@pamsoft.cz wrote:
 Hi Frank,

 I think you should definitively use msxml2.h. I use msxml quite often in
 my applications, but I have my own generated include file, which
 contains the CLSIDs, IIDs and interface definitions. If I look at
 msxml2.h, I can see that CLSID_DOMDocument is declared as extern and I
 have no idea where the ID is actually stored. I suppose it must be in
 some lib, but could not figure out which one it is. (Perhaps it is in
 one of the system libraries which is always linked.)

 The difference between msxml and msxml2 is that msxml2 has richer
 interfaces. So QuickFIX probably will not work with the older
 interfaces. But this should be cleared out at the compilation time.

 The other two msxml headers only contains some defines, they are
 probably included by the other headers.

 Pavel

 On Thu, 2013-01-10 at 06:12 -0500, K. Frank wrote:
 Hi Pavel!

 Thanks for your help.

 On Thu, Jan 10, 2013 at 3:56 AM, pavel pa...@pamsoft.cz wrote:
  Hi Frank,
 
  I went again through your posts and if I understand well, you are trying
  to adapt some code written for MS VC++ to MinGW, is that correct?

 Yes, precisely.

  In this case, you would probably need to rewrite a small portion of the
  code, unless you will get for libxml2 in the end.

 That is indeed what I am hoping.  (I think it is a reasonable hope,
 but you never know.)

  I know nothing about QuickFIX but from the code bellow I deduce that the
  only you need is the initialized m_pDoc pointer. You can use the code
  bellow, however you should avoid using stdafx.h, it is a header
  generated by MS VS for each VC project.

 Yes, I understand how stdafx.h works, and how to get rid of it.

  The atl* headers are headers for
  MS Active Template Library, this is a support stuff for COM. I cannot
  see these headers in my MinGW installation and I suggest you to also
  drop these includes.

 Okay.  Hopefully they aren't used (or aren't used in any essential
 way) by the QuickFIX code.

  So what you basically need is to check whether CLSID_DOMDocument (or
  something like this) is declared in some of the msxml header files
  delivered with MinGW.

 I don't have it in front of me, but I believe it is.

  I suppose it is, so you will include this header

 As mentioned in the other thread, there are four different msxml
 headers provided with mingw-w64.  Would you have any guess
 which I should be suing?  How might I go about figuring it out?

  and use the CLSID constant declared there to create the m_pDoc instance
  through the CoCreateInstance call. I suppose the MSXML_DOMDocument class
  is only a cosmetic wrapper around m_pDoc, more precisely about
  IXMLDOMDocument interface declared in MinGW's msxml.h or msxml2.h.

 Yes, MSXML_DOMDocument is basically just a wrapper.  It has
 a sibling LIBXML_DOMDocument class to abstract away the
 msxml / libxml2 differences from the rest of the  code.

  So, I am not sure whether my explanation is clear enough. My conclusion
  is that if you decide to go for msxml, you would need to manually update
  the code a bit, however, it should not be difficult with the headers
  provided by MinGW.

 Your explanation has been very helpful.  As mentioned in the other
 thread, I do indeed need to update the code.  So far it's been mostly
 straightforward donkey work (deciding which occurrences of _MSC_VER
 to replace with _WIN32).

 Any last thoughts on how to figure out which of the mingw-w64
 msxml I need to include would be helpful.

  Pavel

 Thanks again for your thoughts.


 K. Frank


  On Wed, 2013-01-09 at 19:13 -0500, K. Frank wrote:
  Hi Pavel (and List)!
 
  (Since my follow-up to Pavel's comments are about msxml, I am starting
  a new thread here to separate the discussion from that about libxml2.)
 
  On Wed, Jan 9, 2013 at 8:48 AM, pavel ... wrote:
   Frank, see my comments bellow.
  
   On Wed, 2013-01-09 at 08:04 -0500, K. Frank wrote:
   I am hoping that all I need to do is translate the above code
   fragment, e.g.:
  
  #import msxml3.dll raw_interfaces_only named_guids
  
   into the mingw-w64 world (without learning DCOM).
  
   Any suggestions or even educated guesses would be helpful.
   Should I just #include all four msxml headers?  Include only
   one master header file?  Something else?  Might I have to
   manually add some msxml library to the link command?
  
   I'm speculating that the microsoft #import command is reading
   through the .dll to find and extract the function-prototype information
   that in the mingw-w64 world is in the #include header files.  But
   that's just a guess, so any help would be appreciated.
  
   Again, I'm not asking how to use msxml.  I just need to know how
   to make msxml available to code that presumably already uses it
   correctly by finding the mingw-w64 equivalent of the #import line.
  
   MS #import command does not

Re: [Mingw-w64-public] MinWG64 on Windows, for Windows?

2012-11-19 Thread Ray Donnelly

On Mon, Nov 19, 2012 at 1:32 PM, Earnie Boyd
ear...@users.sourceforge.net wrote:
 On Sun, Nov 18, 2012 at 1:25 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:
 2012/11/5 Yves yves.per...@modusfx.com

 Hi Ruben,

 All the while I tried all packages, since I`m still oscillating between 32
 bit and 64 bit, TDM seemed to be the way to go, at least to compile to
 compile on Windows for Windows.

 As far as I can tell, none of the packages you suggested allow cross
 compiling.

 With this in mind,  which package should I use to compile on Windows for
 Linux?


 Virtualbox+your favorite distro


 You mean if Yves wants a Linux emulator executing on Windows.  I
 understand Yves to want a compiler on Windows targeting Linux.  What
 Yves would need to do is to create a cross compiler to do that.


 You probably see it coming… which package should I use to compile on
 Windows for MacOSX?


 Impossible.

 No, not impossible.  You will need to create a cross compiler targeting 
 MacOSX.

Or use mine. It's a *lot* of work, ./configure  make  make
install won't cut it.





 In another words, what solution is there to cross compile on Windows, for
 Windows, Linux and MacOSX?


 No.

 You may need to build it yourself using the GCC sources.  I need to
 create a document for doing this so I can just point to it.

Even better, you could encode your knowledge into patches and fixes
for crosstool-ng?



 Ruben

 PS: Your font is huge.

 The huge font can be mitigated by converting to text mode.

 --
 Earnie
 -- https://sites.google.com/site/earnieboyd

 --
 Monitor your physical, virtual and cloud infrastructure from a single
 web console. Get in-depth insight into apps, servers, databases, vmware,
 SAP, cloud infrastructure, etc. Download 30-day Free Trial.
 Pricing starts from $795 for 25 servers or applications!
 http://p.sf.net/sfu/zoho_dev2dev_nov
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MinWG64 on Windows, for Windows?

2012-11-19 Thread Ray Donnelly

ng=next generation in this case.

I mention it because they've recently added minGW-w64 as a target, and
are looking for new people to help out. I'm hoping to add my darwin
cross compilers to it and after that look at running it on MSYS.

On Mon, Nov 19, 2012 at 5:05 PM, Earnie Boyd
ear...@users.sourceforge.net wrote:
 On Mon, Nov 19, 2012 at 8:37 AM, Ray Donnelly wrote:
 On Mon, Nov 19, 2012 at 1:32 PM, Earnie Boyd

 You may need to build it yourself using the GCC sources.  I need to
 create a document for doing this so I can just point to it.

 Even better, you could encode your knowledge into patches and fixes
 for crosstool-ng?


 Until I write down what it is I think I know then it is only an
 obscure abstract that lives only with me.  And being able to point
 someone to a here's what's needed document specific to the Windows
 environment then it remains a mystery to those wanting to learn.  I
 didn't know about crosstool-NG until your post, what does the NG part
 stand for; it isn't obvious from the page on the net?

 --
 Earnie
 -- https://sites.google.com/site/earnieboyd

 --
 Monitor your physical, virtual and cloud infrastructure from a single
 web console. Get in-depth insight into apps, servers, databases, vmware,
 SAP, cloud infrastructure, etc. Download 30-day Free Trial.
 Pricing starts from $795 for 25 servers or applications!
 http://p.sf.net/sfu/zoho_dev2dev_nov
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MinWG64 on Windows, for Windows?

2012-11-18 Thread Ray Donnelly

On Nov 18, 2012 6:25 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:

2012/11/5 Yves yves.per...@modusfx.com

Hi Ruben,

All the while I tried all packages, since I`m still oscillating between
32 bit and 64 bit, TDM seemed to be the way to go, at least to compile to
compile on Windows for Windows.

As far as I can tell, none of the packages you suggested allow cross
compiling.

With this in mind, which package should I use to compile on Windows for
Linux?

Virtualbox+your favorite distro

You probably see it coming… which package should I use to compile on
Windows for MacOSX?

Impossible.

https://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Windows-120614.7z...
But you need to get your hands on a MacOSX SDK too.

In another words, what solution is there to cross compile on Windows,
for Windows, Linux and MacOSX?

No.

Ruben

PS: Your font is huge.

Sent from my iPhone

On Nov 2, 2012, at 18:11, Yves yves.per...@modusfx.com wrote:

Very well, I'll chew on this over the weekend. Your wisdom is
appreciated indeed. Thank you very much Ruben.

Sent from my iPhone

On Nov 2, 2012, at 15:55, Ruben Van Boxem vanboxem.ru...@gmail.com
wrote:

2012/11/2 Yves Perron yves.per...@modusfx.com

Greetings everyone,

Its been a wild ride for me in the cross-platform compilation world.
After several weeks pulling my hair, I figured it might be a good thing to
ask for help before I go completely bald.

To resume, I do have a fairly complex C++ Visual Studio 10 Win64
project that needs to be maintained on windows and port to Linux and
MacOSX. For simplicity sake, let's forget I just said that and let's get
down to basics. Here is my setup:

Windows 7
CMake 2.8.9
Intel Processor 64 bit

I already have my CMake setup running using the Visual Studio 10
Win64 compiler and it works beautifully. Now, to get things rolling, I'd
like to compile the same project with MinWG64 on Windows, for Windows.

Hi Yves,

Before I go any further, I'd like to know:
Which MinGW64 binary package should I get from
http://sourceforge.net/projects/mingw-w64?**

There are several you can choose from:
- my Personal builds: I provide native and cross compilers which are
nicely up to date. Choose the 4.7.2 package if you want to have the latest
stable stuff.
- mingwbuilds: another person who reads this list and builds
compilers. He often has very specialized features enabled which I reserve
for my experimental builds.
- TDM GCC: a MinGW classic, providing a 32-bit Windows to 64-bit
Windows multilib compiler (which can compile for both 32 and 64-bit)

All of these are either install+ add mingw*/bin to PATH or run the
included envsetup script which does that for you (like with mine). It goes
without saying I recommend my toolchain builds ;-)

What would be the best compiler to use to get my code compliant for
the other platforms?

You should use as much compilers as possible, which in this case
means: Visual Studio (which will be the limiting factor in any case), GCC
(see above) and Clang (see
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/rubenvb/clang-3.1-release/for
more details, read carefully). Clang may not be usable for what you
are
doing, as it misses certain features required for normal Windows code (like
dllexporting classes). It works fine in cases not using that though, but
only for 32-bit Windows.
To force GCC's strict mode, which is very useful, use the following
compiler flags when building:
-Wextra -pedantic -std=c++11
Some optional extra flags are:
-Wconversion -Wuninitialized -Winit-self -Wmissing-include-dirs
-Wstrict-aliasing
These options will not ensure your code will work on different OSes,
but it will make sure it is standards conformant as much as possible.
Note that MinGW inherently uses msvcrt, which means certain C
functions may not behave like you would expect. See MSDN in Visual C++ 2003
mode to see the documentation for the functions MinGW exposes. If you're
using fancy C++11 library features (which include but are not limited to
thread, std::to_string, and regex) you will find GCC's libstdc++
unfortunately lacking. Everything else is usually implemented better than
on MSVC though, including tuple.

To use CMake, just be sure g++ is in PATH, and run
cmake path/to/source -GMinGW Makefiles

Hope this helps,

Ruben

** I say binary hoping I could avoid compiling compilers because
this idea upsets me some how.

Thank you very much for reading this.

--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command
center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d

Re: [Mingw-w64-public] incorrect syntax while building QT 4.8.3

2012-11-02 Thread Ray Donnelly

Yeah, that's usually down to the way MSYS bash implements fork-like
behaviour... It's in intermittent thing, I usually wrap my calls to
make up with a loop to retry a few times! Horrible I know...

The other (better) fix is to use a make.exe that doesn't use sh.exe
all the time.

On Fri, Nov 2, 2012 at 1:14 PM, CanisMajorWuff canismajorw...@gmail.com wrote:
 Ok, thx, I overcome this problem, but now I have another:


 g++ -c -Wall -Wextra -Wreturn-type -fno-strict-aliasing -Wcast-align
 -Wchar-subscripts -Wformat-security -Wreturn
 -type -Wno-unused-parameter -Wno-sign-compare -Wno-switch
 -Wno-switch-enum -Wundef -Wmissing-noreturn -Winit-self
   -O2 -frtti -fexceptions -mthreads -DUNICODE -DQT_LARGEFILE_SUPPORT
 -DNDEBUG -DBUILDING_QT__=1 -DNDEBUG -DQT_ASCI
 I_CAST_WARNINGS -DENABLE_XSLT=0 -DENABLE_WEB_TIMING=0
 -DENABLE_JAVASCRIPT_DEBUGGER=1 -DENABLE_DATABASE=1 -DENABLE
 _EVENTSOURCE=1 -DENABLE_OFFLINE_WEB_APPLICATIONS=1
 -DENABLE_DOM_STORAGE=1 -DENABLE_ICONDATABASE=1 -DENABLE_CHANNE
 L_MESSAGING=1 -DENABLE_DIRECTORY_UPLOAD=0 -DENABLE_FILE_SYSTEM=0
 -DENABLE_QUOTA=0 -DENABLE_SQLITE=1 -DENABLE_DASH
 BOARD_SUPPORT=0 -DENABLE_FILTERS=1 -DENABLE_XPATH=1 -DENABLE_WCSS=0
 -DENABLE_SHARED_WORKERS=1 -DENABLE_WORKERS=1
 -DENABLE_XHTMLMP=0 -DENABLE_DETAILS=1 -DENABLE_METER_TAG=1
 -DENABLE_PROGRESS_TAG=1 -DENABLE_BLOB=1 -DENABLE_NOTIF
 ICATIONS=1 -DENABLE_INPUT_SPEECH=0 -DENABLE_INSPECTOR=1
 -DENABLE_3D_RENDERING=1 -DENABLE_WEB_AUDIO=0 -DENABLE_WEB
 GL=0 -DENABLE_MEDIA_STATISTICS=0 -DENABLE_VIDEO_TRACK=0
 -DENABLE_TOUCH_ICON_LOADING=0 -DENABLE_ANIMATION_API=0 -D
 ENABLE_SVG=1 -DENABLE_SVG_FONTS=1 -DENABLE_SVG_FOREIGN_OBJECT=1
 -DENABLE_SVG_ANIMATION=1 -DENABLE_SVG_AS_IMAGE=1
 -DENABLE_SVG_USE=1 -DENABLE_DATALIST=1 -DENABLE_TILED_BACKING_STORE=1
 -DENABLE_NETSCAPE_PLUGIN_API=1 -DENABLE_WEB
 _SOCKETS=1 -DWTF_USE_QT_BEARER=1 -DENABLE_TOUCH_EVENTS=1
 -DENABLE_VIDEO=0 -DSQLITE_CORE -DSQLITE_OMIT_LOAD_EXTENS
 ION -DSQLITE_OMIT_COMPLETE -D_HAS_TR1=0 -DBUILDING_JavaScriptCore
 -DBUILDING_WTF -DBUILDING_WEBKIT -DQT_MAKEDLL -
 DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_HAVE_MMX
 -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MM
 XEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT
 -I'../../../../../include/QtCore' -I'../../../../../include/QtNetwork' -I
 '../../../../../include/QtGui' -I'../../../../../include'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScrip
 tCore' -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/ThirdParty' -
 I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/assembler'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Sou
 rce/JavaScriptCore/bytecode'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/bytecompiler'
 -I'd:/qt/
 4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/heap'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScrip
 tCore/dfg'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/debugger'
 -I'd:/qt/4.8.3/src/src/3rdparty
 /webkit/Source/JavaScriptCore/interpreter'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/jit' -I'd
 :/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/parser'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/Ja
 vaScriptCore/profiler'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/runtime'
 -I'd:/qt/4.8.3/src/s
 rc/3rdparty/webkit/Source/JavaScriptCore/wtf'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/wtf/go
 bject'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/wtf/symbian' 
 -I'd:/qt/4.8.3/src/src/3rdparty/
 webkit/Source/JavaScriptCore/wtf/unicode'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/yarr' -I'd
 :/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/API'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaS
 criptCore/ForwardingHeaders'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/generated'
 -I'd:/qt/4.8
 .3/src/src/3rdparty/webkit/Source/WebCore/bridge/qt'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebCore/page/q
 t'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebCore/platform/graphics/qt'
 -I'd:/qt/4.8.3/src/src/3rdparty/we
 bkit/Source/WebCore/platform/network/qt'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebCore/platform/qt' -I'd:
 /qt/4.8.3/src/src/3rdparty/webkit/Source/WebKit/qt/Api'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebKit/qt/W
 ebCoreSupport' -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebCore'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Sour
 ce/WebCore/accessibility'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebCore/bindings'
 -I'd:/qt/4.8.3/src/src/
 3rdparty/webkit/Source/WebCore/bindings/generic'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebCore/bridge' -I
 'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebCore/css'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebCore/do
 m' -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebCore/dom/default'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Sour
 ce/WebCore/editing'

Re: [Mingw-w64-public] incorrect syntax while building QT 4.8.3

2012-11-02 Thread Ray Donnelly

Well, I've got my own that I use:

https://mingw-and-ndk.googlecode.com/files/make.exe

It goes through sh.exe a lot less (but also isn't an MSYS program so
doesn't do the MSYS path transformations), however it may work fine
for your needs (I've used it to build Android Qt and MinGW Qt
variants). One trick I use to get around the lack of MSYS path
transformations is to use mklink /D to make the transformations
unnecessary.

Or as Ruben says, use jom, it's great. I've also got a build of that:

https://mingw-and-ndk.googlecode.com/files/jom.7z

Cheers,

Ray.

On Fri, Nov 2, 2012 at 1:24 PM, CanisMajorWuff canismajorw...@gmail.com wrote:
 I am using make from.  Do you mean to use another make?

 On 11/2/2012 2:19 PM, Ray Donnelly wrote:
 Yeah, that's usually down to the way MSYS bash implements fork-like
 behaviour... It's in intermittent thing, I usually wrap my calls to
 make up with a loop to retry a few times! Horrible I know...

 The other (better) fix is to use a make.exe that doesn't use sh.exe
 all the time.

 On Fri, Nov 2, 2012 at 1:14 PM, CanisMajorWuff canismajorw...@gmail.com 
 wrote:
 Ok, thx, I overcome this problem, but now I have another:


 g++ -c -Wall -Wextra -Wreturn-type -fno-strict-aliasing -Wcast-align
 -Wchar-subscripts -Wformat-security -Wreturn
 -type -Wno-unused-parameter -Wno-sign-compare -Wno-switch
 -Wno-switch-enum -Wundef -Wmissing-noreturn -Winit-self
-O2 -frtti -fexceptions -mthreads -DUNICODE -DQT_LARGEFILE_SUPPORT
 -DNDEBUG -DBUILDING_QT__=1 -DNDEBUG -DQT_ASCI
 I_CAST_WARNINGS -DENABLE_XSLT=0 -DENABLE_WEB_TIMING=0
 -DENABLE_JAVASCRIPT_DEBUGGER=1 -DENABLE_DATABASE=1 -DENABLE
 _EVENTSOURCE=1 -DENABLE_OFFLINE_WEB_APPLICATIONS=1
 -DENABLE_DOM_STORAGE=1 -DENABLE_ICONDATABASE=1 -DENABLE_CHANNE
 L_MESSAGING=1 -DENABLE_DIRECTORY_UPLOAD=0 -DENABLE_FILE_SYSTEM=0
 -DENABLE_QUOTA=0 -DENABLE_SQLITE=1 -DENABLE_DASH
 BOARD_SUPPORT=0 -DENABLE_FILTERS=1 -DENABLE_XPATH=1 -DENABLE_WCSS=0
 -DENABLE_SHARED_WORKERS=1 -DENABLE_WORKERS=1
 -DENABLE_XHTMLMP=0 -DENABLE_DETAILS=1 -DENABLE_METER_TAG=1
 -DENABLE_PROGRESS_TAG=1 -DENABLE_BLOB=1 -DENABLE_NOTIF
 ICATIONS=1 -DENABLE_INPUT_SPEECH=0 -DENABLE_INSPECTOR=1
 -DENABLE_3D_RENDERING=1 -DENABLE_WEB_AUDIO=0 -DENABLE_WEB
 GL=0 -DENABLE_MEDIA_STATISTICS=0 -DENABLE_VIDEO_TRACK=0
 -DENABLE_TOUCH_ICON_LOADING=0 -DENABLE_ANIMATION_API=0 -D
 ENABLE_SVG=1 -DENABLE_SVG_FONTS=1 -DENABLE_SVG_FOREIGN_OBJECT=1
 -DENABLE_SVG_ANIMATION=1 -DENABLE_SVG_AS_IMAGE=1
 -DENABLE_SVG_USE=1 -DENABLE_DATALIST=1 -DENABLE_TILED_BACKING_STORE=1
 -DENABLE_NETSCAPE_PLUGIN_API=1 -DENABLE_WEB
 _SOCKETS=1 -DWTF_USE_QT_BEARER=1 -DENABLE_TOUCH_EVENTS=1
 -DENABLE_VIDEO=0 -DSQLITE_CORE -DSQLITE_OMIT_LOAD_EXTENS
 ION -DSQLITE_OMIT_COMPLETE -D_HAS_TR1=0 -DBUILDING_JavaScriptCore
 -DBUILDING_WTF -DBUILDING_WEBKIT -DQT_MAKEDLL -
 DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_HAVE_MMX
 -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MM
 XEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT
 -I'../../../../../include/QtCore' -I'../../../../../include/QtNetwork' -I
 '../../../../../include/QtGui' -I'../../../../../include'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScrip
 tCore' -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/ThirdParty' -
 I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/assembler'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Sou
 rce/JavaScriptCore/bytecode'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/bytecompiler'
 -I'd:/qt/
 4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/heap'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScrip
 tCore/dfg'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/debugger'
 -I'd:/qt/4.8.3/src/src/3rdparty
 /webkit/Source/JavaScriptCore/interpreter'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/jit' -I'd
 :/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/parser'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/Ja
 vaScriptCore/profiler'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/runtime'
 -I'd:/qt/4.8.3/src/s
 rc/3rdparty/webkit/Source/JavaScriptCore/wtf'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/wtf/go
 bject'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/wtf/symbian' 
 -I'd:/qt/4.8.3/src/src/3rdparty/
 webkit/Source/JavaScriptCore/wtf/unicode'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/yarr' -I'd
 :/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/API'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaS
 criptCore/ForwardingHeaders'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/generated'
 -I'd:/qt/4.8
 .3/src/src/3rdparty/webkit/Source/WebCore/bridge/qt'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebCore/page/q
 t'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebCore/platform/graphics/qt'
 -I'd:/qt/4.8.3/src/src/3rdparty/we
 bkit/Source/WebCore/platform/network/qt'
 -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/WebCore/platform

Re: [Mingw-w64-public] incorrect syntax while building QT 4.8.3

2012-11-02 Thread Ray Donnelly

IMHO, it's MSYS that should've called it's make program msys-make.exe
and mingw32-make.exe should've been called make.exe, seeing as it's
the strictly native one here, but I understand that I'm bucking the
trend. When this make.exe is supplied with Necessitas for Windows,
I've renamed it to ma-make.exe specifically to avoid more confusion.

I intend my make.exe to (one day) be able to also work from MSYS (by
hand parsing fstab), cmd.exe and whatever else I can throw it at.

On Fri, Nov 2, 2012 at 1:34 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
 2012/11/2 Ray Donnelly mingw.andr...@gmail.com

 Well, I've got my own that I use:

 https://mingw-and-ndk.googlecode.com/files/make.exe

 It goes through sh.exe a lot less (but also isn't an MSYS program so
 doesn't do the MSYS path transformations), however it may work fine
 for your needs (I've used it to build Android Qt and MinGW Qt
 variants). One trick I use to get around the lack of MSYS path
 transformations is to use mklink /D to make the transformations
 unnecessary.


 You shouldn't name a mingw32-make make.exe. There's a huge difference,
 and naming them the same will confuse users who don't know about the
 difference.

 That being said, you should choose either cmd.exe or MSYS (or Cygwin) as
 your shell. The former uses mingw32-make (or jom as an almost full
 replacement), the latter two use a make built for their environment. I
 suggest building Qt from cmd.exe. It's bound to be the fastest (especially
 with jom).

 Ruben



 Or as Ruben says, use jom, it's great. I've also got a build of that:

 https://mingw-and-ndk.googlecode.com/files/jom.7z

 Cheers,

 Ray.

 On Fri, Nov 2, 2012 at 1:24 PM, CanisMajorWuff canismajorw...@gmail.com
 wrote:
  I am using make from.  Do you mean to use another make?
 
  On 11/2/2012 2:19 PM, Ray Donnelly wrote:
  Yeah, that's usually down to the way MSYS bash implements fork-like
  behaviour... It's in intermittent thing, I usually wrap my calls to
  make up with a loop to retry a few times! Horrible I know...
 
  The other (better) fix is to use a make.exe that doesn't use sh.exe
  all the time.
 
  On Fri, Nov 2, 2012 at 1:14 PM, CanisMajorWuff
  canismajorw...@gmail.com wrote:
  Ok, thx, I overcome this problem, but now I have another:
 
 
  g++ -c -Wall -Wextra -Wreturn-type -fno-strict-aliasing -Wcast-align
  -Wchar-subscripts -Wformat-security -Wreturn
  -type -Wno-unused-parameter -Wno-sign-compare -Wno-switch
  -Wno-switch-enum -Wundef -Wmissing-noreturn -Winit-self
 -O2 -frtti -fexceptions -mthreads -DUNICODE -DQT_LARGEFILE_SUPPORT
  -DNDEBUG -DBUILDING_QT__=1 -DNDEBUG -DQT_ASCI
  I_CAST_WARNINGS -DENABLE_XSLT=0 -DENABLE_WEB_TIMING=0
  -DENABLE_JAVASCRIPT_DEBUGGER=1 -DENABLE_DATABASE=1 -DENABLE
  _EVENTSOURCE=1 -DENABLE_OFFLINE_WEB_APPLICATIONS=1
  -DENABLE_DOM_STORAGE=1 -DENABLE_ICONDATABASE=1 -DENABLE_CHANNE
  L_MESSAGING=1 -DENABLE_DIRECTORY_UPLOAD=0 -DENABLE_FILE_SYSTEM=0
  -DENABLE_QUOTA=0 -DENABLE_SQLITE=1 -DENABLE_DASH
  BOARD_SUPPORT=0 -DENABLE_FILTERS=1 -DENABLE_XPATH=1 -DENABLE_WCSS=0
  -DENABLE_SHARED_WORKERS=1 -DENABLE_WORKERS=1
  -DENABLE_XHTMLMP=0 -DENABLE_DETAILS=1 -DENABLE_METER_TAG=1
  -DENABLE_PROGRESS_TAG=1 -DENABLE_BLOB=1 -DENABLE_NOTIF
  ICATIONS=1 -DENABLE_INPUT_SPEECH=0 -DENABLE_INSPECTOR=1
  -DENABLE_3D_RENDERING=1 -DENABLE_WEB_AUDIO=0 -DENABLE_WEB
  GL=0 -DENABLE_MEDIA_STATISTICS=0 -DENABLE_VIDEO_TRACK=0
  -DENABLE_TOUCH_ICON_LOADING=0 -DENABLE_ANIMATION_API=0 -D
  ENABLE_SVG=1 -DENABLE_SVG_FONTS=1 -DENABLE_SVG_FOREIGN_OBJECT=1
  -DENABLE_SVG_ANIMATION=1 -DENABLE_SVG_AS_IMAGE=1
  -DENABLE_SVG_USE=1 -DENABLE_DATALIST=1 -DENABLE_TILED_BACKING_STORE=1
  -DENABLE_NETSCAPE_PLUGIN_API=1 -DENABLE_WEB
  _SOCKETS=1 -DWTF_USE_QT_BEARER=1 -DENABLE_TOUCH_EVENTS=1
  -DENABLE_VIDEO=0 -DSQLITE_CORE -DSQLITE_OMIT_LOAD_EXTENS
  ION -DSQLITE_OMIT_COMPLETE -D_HAS_TR1=0 -DBUILDING_JavaScriptCore
  -DBUILDING_WTF -DBUILDING_WEBKIT -DQT_MAKEDLL -
  DQT_NO_DEBUG -DQT_GUI_LIB -DQT_NETWORK_LIB -DQT_CORE_LIB -DQT_HAVE_MMX
  -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MM
  XEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT
  -I'../../../../../include/QtCore' -I'../../../../../include/QtNetwork'
  -I
  '../../../../../include/QtGui' -I'../../../../../include'
  -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScrip
  tCore' -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source'
  -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/ThirdParty' -
  I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/assembler'
  -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Sou
  rce/JavaScriptCore/bytecode'
 
  -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/bytecompiler'
  -I'd:/qt/
  4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/heap'
  -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScrip
  tCore/dfg'
  -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/debugger'
  -I'd:/qt/4.8.3/src/src/3rdparty
  /webkit/Source/JavaScriptCore/interpreter'
  -I'd:/qt/4.8.3/src/src/3rdparty/webkit/Source/JavaScriptCore/jit

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

2012-10-26 Thread Ray Donnelly

I've never seen any precedent of anyone ever doing this anywhere.

Are you saying we are all in violation here? If so, 'we' includes a
huge amount of developers and applications (every Windows C++
application built with GCC!)

On Fri, Oct 26, 2012 at 4:00 PM, Corinna Vinschen vinsc...@redhat.com wrote:
 On Oct 26 15:04, Ruben Van Boxem wrote:
 And that Section 6 clearly states you can point to e.g. the GCC website for
 the source code:
 http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites

 No, you're misinterpreting that.  Read again.  *You* can provide the
 sources of the GPLed stuff you're providing in binary form on another
 site.  That does not imply that you can burden *somebody else*, aka the
 GCC website, with the resposibility to provide the source code for you.


 Corinna

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_sfd2d_oct
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_sfd2d_oct
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

2012-10-26 Thread Ray Donnelly

On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen vinsc...@redhat.com wrote:
 On Oct 26 16:10, Ray Donnelly wrote:
 I've never seen any precedent of anyone ever doing this anywhere.

 Are you saying we are all in violation here? If so, 'we' includes a
 huge amount of developers and applications (every Windows C++
 application built with GCC!)

 No, that's not the case.  This is the kind of FUD which is spread
 way too often, unfortunately.  There's an important difference here.

 Assuming you create a Linux application which is linked against glibc,
 then you can provide binaries of your application, as well as sources if
 it's an open source project, at your sole discretion.  There's no reason
 to provide glibc together with your application since you can be pretty
 sure that glibc exists on any target computer.

 But what if you *do* provide glibc together with your application?  In
 that case you provide a binary of a (L)GPLed product.  Now that you
 provide this binary, you're also required to provide the sources for
 that binary since your user has the right to get the sources as well.

 Keep in mind that the GPL is a user-centric license.  In a way, you as
 developer are not the beneficiary of this license, but the user of the
 product is, by making sure that the user retains the right to see the
 sources of the product, whoever distributes that product.

 Does that make the situation clearer?


No, less clear, you've said that I've just spread some FUD, then
appear to repeat exactly what I said.

In your response, s/glibc/libstdc++.dll/ to see what I mean!

I build a Qt application (Necessitas Qt Creator) for Windows and we
distribute it with libstdc++-6.dll, so from what I'm gathering, we
should also be providing the sources for this?

Many thanks for increasing the U factor in FUD!


 Corinna


 On Fri, Oct 26, 2012 at 4:00 PM, Corinna Vinschen vinsc...@redhat.com 
 wrote:
  On Oct 26 15:04, Ruben Van Boxem wrote:
  And that Section 6 clearly states you can point to e.g. the GCC website 
  for
  the source code:
  http://www.gnu.org/licenses/gpl-faq.html#SourceAndBinaryOnDifferentSites
 
  No, you're misinterpreting that.  Read again.  *You* can provide the
  sources of the GPLed stuff you're providing in binary form on another
  site.  That does not imply that you can burden *somebody else*, aka the
  GCC website, with the resposibility to provide the source code for you.
 
 
  Corinna
 
  --
  Everyone hates slow websites. So do we.
  Make your web apps faster with AppDynamics
  Download AppDynamics Lite for free today:
  http://p.sf.net/sfu/appdyn_sfd2d_oct
  ___
  Mingw-w64-public mailing list
  Mingw-w64-public@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://p.sf.net/sfu/appdyn_sfd2d_oct
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

 --
 The Windows 8 Center
 In partnership with Sourceforge
 Your idea - your app - 30 days. Get started!
 http://windows8center.sourceforge.net/
 what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

2012-10-26 Thread Ray Donnelly

Ok, if this is all true, then IMHO, ideally the necessary sources
would be included with every build (even binary) of mingw gcc, with a
big README explaining these legal requirements.

On Fri, Oct 26, 2012 at 5:05 PM, Earnie Boyd
ear...@users.sourceforge.net wrote:
 On Fri, Oct 26, 2012 at 11:54 AM, Ray Donnelly wrote:
 On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen wrote:
 On Oct 26 16:10, Ray Donnelly wrote:
 I've never seen any precedent of anyone ever doing this anywhere.

 Are you saying we are all in violation here? If so, 'we' includes a
 huge amount of developers and applications (every Windows C++
 application built with GCC!)

 No, that's not the case.  This is the kind of FUD which is spread
 way too often, unfortunately.  There's an important difference here.

 Assuming you create a Linux application which is linked against glibc,
 then you can provide binaries of your application, as well as sources if
 it's an open source project, at your sole discretion.  There's no reason
 to provide glibc together with your application since you can be pretty
 sure that glibc exists on any target computer.

 But what if you *do* provide glibc together with your application?  In
 that case you provide a binary of a (L)GPLed product.  Now that you
 provide this binary, you're also required to provide the sources for
 that binary since your user has the right to get the sources as well.

 Keep in mind that the GPL is a user-centric license.  In a way, you as
 developer are not the beneficiary of this license, but the user of the
 product is, by making sure that the user retains the right to see the
 sources of the product, whoever distributes that product.

 Does that make the situation clearer?


 No, less clear, you've said that I've just spread some FUD, then
 appear to repeat exactly what I said.

 In your response, s/glibc/libstdc++.dll/ to see what I mean!

 I build a Qt application (Necessitas Qt Creator) for Windows and we
 distribute it with libstdc++-6.dll, so from what I'm gathering, we
 should also be providing the sources for this?

 Many thanks for increasing the U factor in FUD!

 I understood Corinna to mean This is the kind of FUD relative to the
 you don't need to distribute source, just point somewhere else FUD
 and the reason I butted in.  If you distribute libstc++-6.dll then yes
 you need to distribute the source that created it.

 --
 Earnie
 -- https://sites.google.com/site/earnieboyd

 --
 The Windows 8 Center
 In partnership with Sourceforge
 Your idea - your app - 30 days. Get started!
 http://windows8center.sourceforge.net/
 what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

2012-10-26 Thread Ray Donnelly

 Also, can someone clarify that you only need to be able to provider the 
 source when asked for it vs providing it in some public place, which might 
 not even be reachable everywhere in the world?

I think it'd be best if you provided the correct sources with your
builds of GCC, so that the end user can simply take the archive you've
provided pass that archive on (and COPYING*) with their built
applications.

As for LLVM vs GCC, well that's a whole other matter, and giving the
users choice of both is best!

On Fri, Oct 26, 2012 at 5:35 PM, Earnie Boyd
ear...@users.sourceforge.net wrote:
 On Fri, Oct 26, 2012 at 12:27 PM, Ruben Van Boxem
 vanboxem.ru...@gmail.com wrote:

 Also, can someone clarify that you only need to be able to provider the
 source when asked for it vs providing it in some public place, which might
 not even be reachable everywhere in the world?

 AIUI, at least for v2 of the license, you need to be able to provide
 the source for the exact version the user has in possession via the
 same media that the binary was delivered when asked for it.  It is
 easier if you just deliver the source and the same time you deliver
 the binary since you can tell the user he already has the source.

 --
 Earnie
 -- https://sites.google.com/site/earnieboyd

 --
 The Windows 8 Center
 In partnership with Sourceforge
 Your idea - your app - 30 days. Get started!
 http://windows8center.sourceforge.net/
 what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
The Windows 8 Center 
In partnership with Sourceforge
Your idea - your app - 30 days. Get started!
http://windows8center.sourceforge.net/
what-html-developers-need-to-know-about-coding-windows-8-metro-style-apps/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] UpdateLayeredWindowIndirect missing in lib32/user32.def

2012-09-20 Thread Ray Donnelly

Hi guys,

Is there any chance this minor fix could be put into the branches?

http://sourceforge.net/tracker/?func=detailaid=3533362group_id=202880atid=983356

Cheers,

Ray.

On Thu, Sep 20, 2012 at 9:17 PM, Ozkan Sezer seze...@gmail.com wrote:
 On 9/20/12, Kai Tietz ktiet...@googlemail.com wrote:
 Hi,

 thanks for the information.  Missing import is present on trunk at
 revision 5409,  Maybe Ozkan wants to add it to 2.x branch too.

 Thanks,
 Kai


 Added to both v1.x and v2.x.  Thanks.

 --
 O.S.

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://ad.doubleclick.net/clk;258768047;13503038;j?
 http://info.appdynamics.com/FreeJavaPerformanceDownload.html
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] UpdateLayeredWindowIndirect missing in lib32/user32.def

2012-09-20 Thread Ray Donnelly

Many thanks!

On Thu, Sep 20, 2012 at 9:58 PM, Ozkan Sezer seze...@gmail.com wrote:
 On 9/20/12, Kai Tietz ktiet...@googlemail.com wrote:
 Hi Ray,

 2012/9/20 Ray Donnelly mingw.andr...@gmail.com:
 Hi guys,

 Is there any chance this minor fix could be put into the branches?

 http://sourceforge.net/tracker/?func=detailaid=3533362group_id=202880atid=983356

 Cheers,

 Ray.

 Well, I have no objections about this patch.  I think it was a mistake
 to close such a patch it after applying instead of keeping as pending.

 Ozkan, what's your opinion?

 Kai

 Added to both stable branches: v1.x@5413, v1.x@5414

 --
 O.S.

 --
 Everyone hates slow websites. So do we.
 Make your web apps faster with AppDynamics
 Download AppDynamics Lite for free today:
 http://ad.doubleclick.net/clk;258768047;13503038;j?
 http://info.appdynamics.com/FreeJavaPerformanceDownload.html
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://ad.doubleclick.net/clk;258768047;13503038;j?
http://info.appdynamics.com/FreeJavaPerformanceDownload.html
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

1 2 >

1 - 100 of 120 matches

Mail list logo