[Mingw-w64-public] [PATCH] Move asprintf and vasprintf into libmingwex.a instead of being inline funcions in stdio.h

[Ray Donnelly]

Hi guys,

I've attached a fairly simple patch as requested by Kai on IRC which
allows GDB to be compiled successfully.

Without the patch, configure for libiberty fails to find the functions
and tries to build its own versions which then leads to multiply
defined symbols due to the inclusion of stdio.h

Since Windows doesn't provide either of these two functions it should
be safe to move them from being inlined functions into the lib.

Best regards,

Ray Donnelly.


mingw-w64-asprintf-not-inlined.patch
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Move asprintf and vasprintf into libmingwex.a instead of being inline funcions in stdio.h

[Ray Donnelly]

Hi,

No, I don't address either snprintf or vsnprintf with this patch.

Seems we're working on very similar things, just from slightly
different angles. I'm building GDB with Python using the following
cross compilation, MinGW and Darwin patches:

http://mingw-and-ndk.googlecode.com/files/python-273-and-330b1-patches-WIP.7z

There's a build script in there that's got some hard coded paths in
it, and it's a bit untidy (I will be swapping the build scripts out
for ones from the Android NDK which is the final goal of my work).

I can provide my WIP NDK patch if you're interested.

These patches (the first two by Roumen Petrov anyway) are being
merged/considered by Matthias Klose at present, so hopefully in time
we'll be able to build our own Pythons for GDB from the CPython
mainline sources:

http://bugs.python.org/issue3754

Best regards,

Ray.

On Sat, Jun 30, 2012 at 4:04 PM, asmwarrior  wrote:
> On 2012-6-30 23:01, asmwarrior wrote:
>> Good. I see this kind of build error several months ago when building GDB 
>> under MSYS. For me, I have a workaround, I just disable the nls support by 
>> passing the option "--disable-nls" to the configure, otherwise, I will see 
>> build errors.
>
> BTW, the build error of GDB I see is described in the wiki page:
> http://code.google.com/p/qp-gcc/wiki/build_gdb_msys_en
>
>> gcc -s -static -mtune=i686 -D__USE_MINGW_ACCESS   -I. -I../../gdb/gdb 
>> -I../../gdb/gdb/common -I../../gdb/gdb/config 
>> -DLOCALEDIR="\"/E/test/installnew/share/locale\"" -DHAVE_CONFIG_H 
>> -I../../gdb/gdb/../include/opcode -I../../gdb/gdb/../opcodes/.. 
>> -I../../gdb/gdb/../readline/.. -I../bfd -I../../gdb/gdb/../bfd 
>> -I../../gdb/gdb/../include -I../libdecnumber -I../../gdb/gdb/../libdecnumber 
>>  -I../../gdb/gdb/gnulib -Ignulib-IF:/cb/python272/include 
>> -IF:/cb/python272/include -Wall -Wdeclaration-after-statement 
>> -Wpointer-arith -Wformat-nonliteral -Wno-pointer-sign -Wno-unused 
>> -Wunused-value -Wunused-function -Wno-switch -Wno-char-subscripts 
>> -Wno-format -Werror -c -o python.o -MT python.o -MMD -MP -MF 
>> .deps/python.Tpo -fno-strict-aliasing -DNDEBUG -fwrapv 
>> ../../gdb/gdb/python/python.c
>> cc1.exe: warnings being treated as errors
>> In file included from F:/cb/python272/include/Python.h:121:0,
>>  from ../../gdb/gdb/python/python-internal.h:50,
>>  from ../../gdb/gdb/python/python.c:48:
>> F:/cb/python272/include/pyerrors.h:315:0: error: "snprintf" redefined
>> d:\code\mingw_gcc4.5.4.20110428_static_win32\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.4/../../../../i686-pc-mingw32/include/libintl.h:375:0:
>>  note: this is the location of the previous definition
>> F:/cb/python272/include/pyerrors.h:316:0: error: "vsnprintf" redefined
>> d:\code\mingw_gcc4.5.4.20110428_static_win32\mingw\bin\../lib/gcc/i686-pc-mingw32/4.5.4/../../../../i686-pc-mingw32/include/libintl.h:380:0:
>>  note: this is the location of the previous definition
>
>
> I'm not sure your patch fix the conflict in the python header files.
>
> Thanks.
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Move asprintf and vasprintf into libmingwex.a instead of being inline funcions in stdio.h

[Ray Donnelly]

Updated patch, asprintf removed entirely, vasprintf moved from stdio.h
into the .a (gcc can't inline varargs functions anyway).

On Sat, Jun 30, 2012 at 5:44 PM, JonY  wrote:
> On 6/30/2012 22:23, Ray Donnelly wrote:
>> Hi guys,
>>
>> I've attached a fairly simple patch as requested by Kai on IRC which
>> allows GDB to be compiled successfully.
>>
>> Without the patch, configure for libiberty fails to find the functions
>> and tries to build its own versions which then leads to multiply
>> defined symbols due to the inclusion of stdio.h
>>
>> Since Windows doesn't provide either of these two functions it should
>> be safe to move them from being inlined functions into the lib.
>>
>
> asprintf prototype should not exist, you should be using the mingw stdio
> macro thing to reach it instead.
>
> These inlines should stay in the header, see the __CRT__NO_INLINE macro,
> the non-inline prototypes can go in there.
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>


mingw-w64-asprintf-not-inlined-2.patch
Description: Binary data
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Move asprintf and vasprintf into libmingwex.a instead of being inline funcions in stdio.h

[Ray Donnelly]

Thanks Kai,

You decided against renaming __mingw_vasprintf to vasprintf (and same
for asprintf) then?

Cheers,

Ray.

On Thu, Jul 5, 2012 at 12:59 PM, Kai Tietz  wrote:
> Hi,
>
> I disabled the stub-implemenation of asprintf and vasprintf.  By this
> gdb's build failure should be fixed and we avoid the MS-formatter vs.
> POSIX-formatter issue.  Each venture either needs to implement its own
> variant, or it can still use the __mingw_vasprintf variant.
>
> Cheers,
> Kai
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] Move asprintf and vasprintf into libmingwex.a instead of being inline funcions in stdio.h

[Ray Donnelly]

Playing devil's advocate here... given that:

libmingwex.a is only linked if someone passes
-D__USE_MINGW_ANSI_STDIO=1 and that
msvcrt doesn't implement asprintf or vasprintf,

could we not just say that anyone who expects ms formatting in this
scenario is just mistaken? - and they'd get warnings from the to that
effect compiler too.

Cheers,

Ray.

On Thu, Jul 5, 2012 at 1:20 PM, Kai Tietz  wrote:
> 2012/7/5 Ray Donnelly :
>> Thanks Kai,
>>
>> You decided against renaming __mingw_vasprintf to vasprintf (and same
>> for asprintf) then?
>>
>> Cheers,
>>
>> Ray.
>
> Yes, the issue is that __mingw_vasprintf assumes POSIX-formatter
> style.  This could lead to troubles for ventures checking for
> vasprintf/asprintf and assuming it has MS' formatting.
>
> Therefore I think it is more sane to disable those two functions in
> standard-namespace.  Of course people can check for __mingw_vasprintf
> and use it.  But so it is clear it has POSIX-formatting (and result)
> rules.
>
> Cheers,
> Kai
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Debugging with GDB on Windows / MinGW is painfully slow

[Ray Donnelly]

Hi guys,

Regarding GDB and Python:

I've got some WIP Python patches that were created for Necessitas Qt
Creator's NDK GDB for Android. They've since been merged into the
Google NDK:

https://android-review.googlesource.com/#/c/38501/

Using the patches in that merge request, it's possible to build Python
(and then GDB with that Python) using mingw-w64 (on Linux so far, MSYS
build is WIP) for both win32 and win64. The patch also generates a
shell script to replace python-config (which unfortunately uses
Python) so that GDB can pick up the right configuration details
automatically when used in a cross compilation setting.

The only missing part is setting PYTHONHOME env. var from within GDB.
The attached (and pretty horribly complicated) patch gives an example
of how this is done in the context of the NDK (I needed to do lots of
guess work and probing as I'm not sure what the final relative layout
will be- it should be as easy as calling GetModuleFileName and
stripping off some path elements).

Cheers,

Ray.

p.s. There's patches for Python 3.3.0b as well in
http://mingw-and-ndk.googlecode.com/files/python-273-and-330b1-patches-WIP.7z
p.p.s. There's built Android NDKs that use this on my googlecode site as well.

On Sat, Jul 21, 2012 at 4:25 PM, Ruben Van Boxem
 wrote:
> 2012/7/21 asmwarrior 
>>
>> On 2012-7-21 15:07, Eran Ifrah wrote:
>> >
>> >
>> > On Sat, Jul 21, 2012 at 7:59 AM, asmwarrior
>> > > > > wrote:
>> >
>> > On 2012-7-21 11:38, K. Frank wrote:
>> > > As I mentioned above, my gdb version is 7.3.0.
>> > >
>> > >> >You can try a recent gdb (mostly the gdb build from gdb cvs
>> > HEAD)
>> > > If anybody knows of a recent mingw or mingw-w64 build of gdb
>> > > that addresses this issue, please chime in.
>> > >
>> > You can try my build of gdb CVS (32bit)
>> > see:
>> >
>> > http://forums.codeblocks.org/index.php/topic,11301.msg77000.html#msg77000
>> >
>> > Thanks. There is one (minor?) problem with your gdb: it seems to
>> > requires python installation...  and the binaries are quite huge
>> > I prefer the current MinGW way packing things: everything in a single
>> > directory and there is no need to alter 'PATH' not to mention that python
>> > pollutes C:\Windows\ ... (and other places?), which makes it hard to move
>> > around my working environment
>>
>> Yes, the gdb build by me has dependency on python 2.7, but in-fact, you
>> don't need to put python.exe's path in your PATH environment.
>> If I remember correctly, you can just copy "python27.dll" and the folder
>> "Lib", and maybe some msvcrt.dll to your MinGW/bin, the gdb should work
>> fine. And I believe that using this way, the whole gdb package should be
>> portable. I mean the official python27.dll was build from MSVC, so you need
>> some MS crt dlls, besides that, python27.dll will automatically search its
>> own library named "Lib" in the same folder.
>> After such copying, you can safely uninstall your python distribution,
>> because all you needed is copied to MinGW/bin.
>>
>> I'm just a little lazy to package my build gdb with such python files.
>
>
> You can see here what's needed for Python GDB. My builds come with
> python-enabled gdb too. Only the python27.dll and the lib/ directory inside
> "bin" is necessary for correct Qt and Qt Creator functionality.
>
> Ruben
>
>>
>> >
>> > On the bright side, your gdb seems to be the fastest from the all the
>> > gdb's I have tested so far.
>> > The thing that did the change was changing the workflow a littlet:
>> >
>> > * start gdb
>> > * break at main
>> > * place pending breakpoints
>> > * continue
>> >
>> > as opposed to:
>> >
>> > * start gdb
>> > * place pending breakpoints
>> > * continue
>>
>> The above two method should not have many difference from my point of
>> view, I know a little about how gdb handling "pending breakpoints", when a
>> new dll loaded, gdb try to see the sources of the dll may matches the
>> pending bps, so it mainly scan all the debug information in the dll. The
>> more dll loaded, the more time you needed.
>>
>> BTW: I usually debug codeblocks(which have 10+ plugins as dlls) under gdb,
>> I see gdb works just fine. (start up quite soon when you have pending bps)
>>
>> asmwarrior
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
> --
> Live Security Virtual Conference

Re: [Mingw-w64-public] apparent "hang" using the experimental pthread library

[Ray Donnelly]

This is often useful for profiling:

http://www.codersnotes.com/sleepy/

On Tue, Aug 14, 2012 at 2:26 AM, Kyle Schwarz  wrote:
> On 8/13/2012 8:31 PM, NightStrike wrote:
>> On Wed, Aug 8, 2012 at 2:49 PM, Kyle  wrote:
>>> It's *very* slow. If you compare the speed to that of a older FFmpeg,
>>> the debug build is practically unusable.
>>
>> I'm coming into this very late, and I probably can't be of much help,
>> but just a thought.  Have you tried profiling ffmpeg to see where it's
>> wasting all of its time?  For instance, if it's seeing tons of delays
>> just trying to get mutexes, then that's a problem.
>
> Thank you for the help. Ive been forced to switch over to w32threads
> because of this issue and I'm willing to offer any help to get it fixed.
> I think winpthreads is a great package for not only FFmpeg but also
> other high cpu usage apps, and prefer it over any of the other pthread
> wrapper libraries.
>
> With that said, I haven't tried to profile FFmpeg. I'm not sure how I
> would go about doing that either.
>
>> Compiling with -pg and using gprof would be a help, as would throwing
>> some instrumentation in the code at various key points.
>
> I can supply a build with -pg, I haven't used gprof yet but I believe it
> works along with a build that is compiled with -pg.  I'm a bit rusty in
> C, but I'm very motivated to fix this so just walk me though anything
> you would like tested and I'll see that it's done.
>
>> Have you used gprof before?  It can be daunting with the output that it 
>> gives.
>
> Any progress on this bug is a huge help to me.
>
> Best regards,
>Kyle Schwarz
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] rubenvb 4.7.1-2-release build

[Ray Donnelly]

Interesting, my own build of jom (via mingw32 toolchain and my own Qt
compile ages ago) has never failed to my knowledge:

http://mingw-and-ndk.googlecode.com/files/jom.7z

On Thu, Aug 23, 2012 at 9:52 AM, Loaden  wrote:
> I know jom, it's only for nmake instead.
> Some times, it's will faild for building. So I don't like it.
> Qt is a complex system.
> So, I prefer to use nmake for MSVC, and mingw32-make for MinGW, and make for
> GCC.
> B.T.W, I can build qt5 under Linux, use you cross mingw-w64, so, thanks you
> very much!
> Thank you great work!
> 2012/8/23 Ruben Van Boxem 
>>
>> 2012/8/23 Ruben Van Boxem 
>>>
>>> 2012/8/23 Loaden 

 mingw32-make.exe problem after 4.7.0 ~ 4.7.1-2 and 4.6.3-1
 When I build Qt5 using
 x86_64-w64-mingw32-gcc-4.6.3-release-win64_rubenvb.7z on Windows, It's 
 works
 well!
 But the configure failed with 4.7.0 ~ 4.7.1-2 and 4.6.3-1

 Failed Message:
>
> g++ -Wl,-subsystem,console -mthreads -o ../../configure.exe main.o
> configureapp.o environment.o tools.o qarraydata.o qbytearray.o
> qbytearraymatcher.o qhash.o qlist.o qlocale.o qlocale_win.o 
> qlocale_tools.o
> qvector.o qutfcodec.o qtextcodec.o qglobal.o qnumeric.o qbuffer.o
> qdatastream.o qdir.o qdiriterator.o qfiledevice.o qfile.o qfileinfo.o
> qabstractfileengine.o qfilesystementry.o qfilesystemengine.o
> qfilesystemengine_win.o qfilesystemiterator_win.o qfsfileengine.o
> qfsfileengine_win.o qfsfileengine_iterator.o qiodevice.o qtextstream.o
> qlogging.o qtemporaryfile.o qsystemlibrary.o qbitarray.o qdatetime.o 
> qmap.o
> qregexp.o qstring.o qstringlist.o qvsnprintf.o qvariant.o qsystemerror.o
> qmetatype.o qmalloc.o qxmlstream.o qxmlutils.o quuid.o 
> qcryptographichash.o
> registry.o -lole32 -ladvapi32 -luuid
> g++: error: main.o: No such file or directory
> g++: error: configureapp.o: No such file or directory
> g++: error: environment.o: No such file or directory
> g++: error: tools.o: No such file or directory
> g++: error: qarraydata.o: No such file or directory
> g++: error: qbytearray.o: No such file or directory
> g++: error: qbytearraymatcher.o: No such file or directory
> g++: error: qhash.o: No such file or directory
> g++: error: qlist.o: No such file or directory
> g++: error: qlocale.o: No such file or directory
> g++: error: qlocale_win.o: No such file or directory
> g++: error: qlocale_tools.o: No such file or directory
> g++: error: qvector.o: No such file or directory
> g++: error: qutfcodec.o: No such file or directory
> g++: error: qtextcodec.o: No such file or directory
> g++: error: qglobal.o: No such file or directory
> g++: error: qnumeric.o: No such file or directory
> g++: error: qbuffer.o: No such file or directory
> g++: error: qdatastream.o: No such file or directory
> g++: error: qdir.o: No such file or directory
> g++: error: qdiriterator.o: No such file or directory
> g++: error: qfiledevice.o: No such file or directory
> g++: error: qfile.o: No such file or directory
> g++: error: qfileinfo.o: No such file or directory
> g++: error: qabstractfileengine.o: No such file or directory
> g++: error: qfilesystementry.o: No such file or directory
> g++: error: qfilesystemengine.o: No such file or directory
> g++: error: qfilesystemengine_win.o: No such file or directory
> g++: error: qfilesystemiterator_win.o: No such file or directory
> g++: error: qfsfileengine.o: No such file or directory
> g++: error: qfsfileengine_win.o: No such file or directory
> g++: error: qfsfileengine_iterator.o: No such file or directory
> g++: error: qiodevice.o: No such file or directory
> g++: error: qtextstream.o: No such file or directory
> g++: error: qlogging.o: No such file or directory
> g++: error: qtemporaryfile.o: No such file or directory
> g++: error: qbitarray.o: No such file or directory
> g++: error: qdatetime.o: No such file or directory
> g++: error: qmap.o: No such file or directory
> g++: error: qregexp.o: No such file or directory
> g++: error: qstring.o: No such file or directory
> g++: error: qstringlist.o: No such file or directory
> g++: error: qvsnprintf.o: No such file or directory
> g++: error: qvariant.o: No such file or directory
> g++: error: qsystemerror.o: No such file or directory
> g++: error: qmetatype.o: No such file or directory
> g++: error: qmalloc.o: No such file or directory
> g++: error: qxmlstream.o: No such file or directory
> g++: error: qxmlutils.o: No such file or directory
> g++: error: qcryptographichash.o: No such file or directory
> g++: error: registry.o: No such file or directory
> mingw32-make: *** [../../configure.exe] Error 1
> *** qtbase/configure exited with non-zero status.


 If I copy the mingw32-make.exe from
 x86_64-w64-mingw32

Re: [Mingw-w64-public] using libraries built with mingw in Visual C++

[Ray Donnelly]

Switch to Qt Creator instead!

/ducks.

On Fri, Aug 24, 2012 at 5:29 PM, Alex Loukissas  wrote:
> Hello,
>
> I was wondering whether it is possible to use static libraries built with
> mingw (e.g. libz) in a Visual C++ and link against them.
>
> To explain the motivation behind this: in my current setup, I'm using mingw
> to build both my application and my toolchain (which comprises of a number
> of libraries, which I link my application against). I would like to move to
> MSVC++ for my application development but would like to reuse the toolchain
> built using mingw.
>
> Any help is much appreciated!
>
> Thanks,
> Alex Loukissas
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [Development] Choosing a new MinGW for Qt 5

[Ray Donnelly]

Hi Pau,

The Android Necessitas Qt project moved from MinGW to MinGW-w64 for
our A4 release.

As we also build our own version of the Android NDK for Necessitas, we
used (improved and merged back into) their mingw-w64 build script also
build our cross MinGW compilers:

https://android.googlesource.com/platform/ndk/+/5d6dd385bd9814e8da832c70a598a729b9172585/build/tools/build-mingw64-toolchain.sh

For the released Windows version I used ruben's 4.7.0 GCC (the cross
compile did work fine for Qt and Qt Creator actually, but we never got
the packaging side of things finished)

We've run into just one bug so far in the Qt Creator we released with
it (and it's unlikely the compiler's fault).

Cheers,

Ray.

On Fri, Aug 31, 2012 at 2:28 PM, Pau Garcia i Quiles
 wrote:
> Hi,
>
> Qt Project is again trying to decide on what gcc to use on Windows. If
> someone could drop by developm...@qt-project.org and give more insight
> (like: SEH vs Dwarf2 builds, std::thread, make -j support, etc), it'd
> be great.
>
>
> -- Forwarded message --
> From:  
> Date: Fri, Aug 31, 2012 at 3:00 PM
> Subject: Re: [Development] Choosing a new MinGW for Qt 5
> To: thiago.macie...@intel.com, developm...@qt-project.org
>
>
>> -Original Message-
>> From: development-bounces+kai.koehne=nokia@qt-project.org
>> [mailto:development-bounces+kai.koehne=nokia@qt-project.org] On
>> Behalf Of ext Thiago Macieira
>> Sent: Thursday, August 30, 2012 6:17 PM
>> To: developm...@qt-project.org
>> Subject: Re: [Development] Choosing a new MinGW for Qt 5
>>
>> On quinta-feira, 30 de agosto de 2012 17.25.24, Pau Garcia i Quiles wrote:
>> > There are more differences than that. There are differences in
>> > features, such as threading support, large-file support, etc.
>> > Mingw-w64 is usually ahead of any other in terms of features.
>>
>> My suggestion on how to proceed is to choose one that offers the following or
>> most of the following:
>>
>>  - most recent GCC (4.7 preferably, 4.6 if not)
>>  - *working* GDB and tested with Creator, with Python support
>>  - large file support, threading
>>  - zero-overhead exceptions (no SJLJ exceptions)
>>  - standard win32 headers, if possible using the Platform SDK headers
>>  - large set of win32 import libraries
>>  - 32 and 64-bit in one package
>>  - make with -j support
>>  - if this exists: can link to .dll directly, instead of import libs
>
> Alright, since there are people both in favor of mingw-builds and
> mingw-64 I guess we have to do a proper comparison :) Question to the
> mingw-64 supporters: Which exact package should we evaluate?
> http://mingw-w64.sourceforge.net/ talks about "Version 2.0 [...] been
> released and is considered stable." But I couldn't find any pre-build
> toolchain with -2.0 in the file name under
> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/
>  ...
>
> Kai
>
> PS: I started already adding my personal experiences on
> http://qt-project.org/wiki/MinGW-64-bit .
>
>> We should choose one version to be the reference platform and work on
>> making it Tier 1. We shouldn't have two versions, that duplicates work.
>>
>> --
>> Thiago Macieira - thiago.macieira (AT) intel.com
>>   Software Architect - Intel Open Source Technology Center
>>  Intel Sweden AB - Registration Number: 556189-6027
>>  Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden
> ___
> Development mailing list
> developm...@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
>
> --
> Pau Garcia i Quiles
> http://www.elpauer.org
> (Due to my workload, I may need 10 days to answer)
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Fwd: [Development] Choosing a new MinGW for Qt 5

[Ray Donnelly]

I've merged a script and some patches [1] with the Google Android NDK
that allow me to cross compile Python 2.7.3 and also GDB using it
(built GDB then runs on Windows, Darwin or Linux). I can also build
these GDB/NDKs for 32 and 64bit on each of these hosts. The link I've
pasted is to the initial commit, there's been some bug fixes since
then. The cross compilation support for Python was done mostly by
Roumen Petrov [2] & [3], I just finished it off, adding Darwin support
and fixing a few MinGW problems. Maybe this could be of some use? I'm
hoping to get it integrated into some of the mingw-w64 toolchain build
scripts (Ruben's maybe?) and also upstreamed to CPython (though this
would be very difficult).

[1] 
https://android.googlesource.com/platform/ndk/+/e534e36be95815bdfa09756fa040acb2321a09c2
[2] http://bugs.python.org/issue3754
[3] http://bugs.python.org/issue3871

Cheers,

Ray.

On Tue, Sep 11, 2012 at 11:40 AM,   wrote:
>> -Original Message-
>> From: ext K. Frank [mailto:kfrank2...@gmail.com]
>> Sent: Monday, September 10, 2012 6:19 PM
>> To: mingw-w64-public@lists.sourceforge.net
>> Subject: Re: [Mingw-w64-public] Fwd: [Development] Choosing a new MinGW
>> for Qt 5
>>
>> I'm not using python for anything, so I don't care one way or another.
>> If not using python would solve the slow gdb start-up problem, I'd give it a 
>> try,
>> but, if I understand you correctly, you're saying that that's not the 
>> problem.
>
> Adding to that, Qt Creator nowadays _requires_ a Python-enabled gdb. So if 
> we're talking about a MinGW-64 package suited for Qt development, disabling 
> python is a no-go.
>
> Regards
>
> Kai
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] cc1plus.exe crash (x86_64-mingw-w64-gcc-4.7.1-release-c, c++, fortran-sjlj-rev3.7z)

[Ray Donnelly]

If you do --save-temps and put the .ii file somewhere then someone
might be able to diagnose better.

On Tue, Sep 11, 2012 at 1:13 PM,   wrote:
> Hi there,
>
> When trying to build latest Qt with the mingw-builds package 
> x86_64-mingw-w64-gcc-4.7.1-release-c,c++,fortran-sjlj-rev3.7z on an Windows 7 
> 64 bit I'm running into a crash of c11plus.exe : "cc1plus.exe has stopped 
> working", apparently an access violation. This happens after compiling almost 
> half of Qt 5 :(
>
> The offending call is:
>
> g++ -c -include debug\lib_pch.h -pipe -fno-keep-inline-dllexport -g -Wall 
> -Wextr
> a -fno-exceptions -frtti -DUNICODE -DQT_BUILD_DESIGNERCOMPONENTS_LIB 
> -DQT_BUILDI
> NG_QT -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS 
> -DQT_MOC_COMPA
> T -DQT_USE_QSTRINGBUILDER -DQT_DEPRECATED_WARNINGS -D_USE_MATH_DEFINES 
> -DQT_STAT
> ICPLUGIN -DQDESIGNER_COMPONENTS_LIBRARY -DQT_DLL -DQT_DESIGNER_LIB 
> -DQT_WIDGETS_
> LIB -DQT_XML_LIB -DQT_GUI_LIB -DQT_CORE_LIB -DQT_XML_LIB -DQT_CORE_LIB 
> -DQT_NO_E
> XCEPTIONS -I"D:\dev\qt\qt-5-mingw-builds-4.7.1-64\qtbase\include" 
> -I"D:\dev\qt\q
> t-5-mingw-builds-4.7.1-64\qtbase\include\QtDesignerComponents" 
> -I"D:\dev\qt\qt-5
> -mingw-builds-4.7.1-64\qtbase\include\QtDesignerComponents\5.0.0" 
> -I"D:\dev\qt\q
> t-5-mingw-builds-4.7.1-64\qtbase\include\QtDesignerComponents\5.0.0\QtDesignerCo
> mponents" -I"tmp" -I"." -I".." -I"..\..\lib\components" -I"..\..\lib\sdk" 
> -I"..\
> ..\lib\extension" -I"..\..\lib\shared" -I"..\propertyeditor" 
> -I"..\..\..\..\shar
> ed\qtpropertybrowser" -I"..\..\..\..\shared\qtgradienteditor" 
> -I"..\..\..\..\sha
> red\findwidget" -I"..\objectinspector" -I"..\signalsloteditor" 
> -I"..\formeditor"
>  -I"..\widgetbox" -I"..\buddyeditor" -I"..\taskmenu" -I"..\propertyeditor" 
> -I"..
> \..\..\..\shared\tools\shared\qtpropertybrowser" -I"..\tabordereditor" 
> -I"D:\dev
> \qt\qt-5-mingw-builds-4.7.1-64\qtbase\include\QtDesigner" 
> -I"D:\dev\qt\qt-5-ming
> w-builds-4.7.1-64\qtbase\include\QtDesigner\5.0.0" 
> -I"D:\dev\qt\qt-5-mingw-build
> s-4.7.1-64\qtbase\include\QtDesigner\5.0.0\QtDesigner" 
> -I"D:\dev\qt\qt-5-mingw-b
> uilds-4.7.1-64\qtbase\include\QtWidgets" 
> -I"D:\dev\qt\qt-5-mingw-builds-4.7.1-64
> \qtbase\include\QtWidgets\5.0.0" 
> -I"D:\dev\qt\qt-5-mingw-builds-4.7.1-64\qtbase\
> include\QtWidgets\5.0.0\QtWidgets" 
> -I"D:\dev\qt\qt-5-mingw-builds-4.7.1-64\qtbas
> e\include\QtXml" 
> -I"D:\dev\qt\qt-5-mingw-builds-4.7.1-64\qtbase\include\QtGui" -
> I"D:\dev\qt\qt-5-mingw-builds-4.7.1-64\qtbase\include\QtGui\5.0.0" 
> -I"D:\dev\qt\
> qt-5-mingw-builds-4.7.1-64\qtbase\include\QtGui\5.0.0\QtGui" 
> -I"D:\dev\qt\qt-5-m
> ingw-builds-4.7.1-64\qtbase\include\QtCore" -I"debug" -I"." 
> -I"D:\dev\qt\qt-5-mi
> ngw-builds-4.7.1-64\qtbase\mkspecs\win32-g++" -o debug\qdesigner_components.o 
> qd
> esigner_components.cpp
>
>
> This is a native 64 bit gcc. IIRC the gcc from the 32 bit package didn't 
> crash (even when compiling for 64 bit), but I'd have to compile for a couple 
> of hours again to verify...
>
> Can I do anything to help in fixing this? The stacktrace for obvious reasons 
> is pretty cryptic:
>
>>   cc1plus.exe!00bf64b4()
> [Frames below may be incorrect and/or missing, no symbols loaded for 
> cc1plus.exe]
> cc1plus.exe!00bf6500()
> cc1plus.exe!00bf67dd()
> cc1plus.exe!00bf255f()
> cc1plus.exe!0046162e()
> cc1plus.exe!00bf2ca9()
> cc1plus.exe!00bf34fe()
> cc1plus.exe!00678664()
> cc1plus.exe!00ed6975()
> ntdll.dll!76d385a8()
> ntdll.dll!76d49d0d()
> ntdll.dll!76d391af()
> ntdll.dll!76d71278()
> cc1plus.exe!00bf64b4()
> cc1plus.exe!00bf6500()
> cc1plus.exe!00bf67dd()
> cc1plus.exe!00bf255f()
> cc1plus.exe!0046162e()
> cc1plus.exe!00bf2ca9()
> cc1plus.exe!00bf357e()
> cc1plus.exe!006c0db6()
> cc1plus.exe!00517322()
> cc1plus.exe!00bfbce6()
> cc1plus.exe!00513fdb()
> cc1plus.exe!005140fd()
> cc1plus.exe!005167e1()
> cc1plus.exe!0067a25b()
> cc1plus.exe!004013d5()
> cc1plus.exe!004014f8()
> kernel32.dll!769c652d()
> ntdll.dll!76d4c521()
>
> Regards
>
> Kai
>
> PS: Please tell me if this isn't the right mailing list for such issues.
>
> --
> Kai Koehne
> Senior Software Engineer
> Nokia, Mobile Phones
>
> Nokia gate5 GmbH
> Firmensitz: Invalidenstr. 117, 10115 Berlin, Germany
> Registergericht: Amtsgericht Charlottenburg, Berlin: HRB 106443 B
> Umsatzsteueridentifikationsnummer: DE 812 845 193
> Geschäftsführer: Dr. Michael Halbherr, Karim Tähtivuori
>
>
> -

Re: [Mingw-w64-public] Fwd: [Development] Choosing a new MinGW for Qt 5

[Ray Donnelly]

You should be enjoying your holiday (sounds like you could be busy
just after it). I'll try to convince you when you get back.

Will go something like: cross compilation, homogeneous toolchain
environment, possible to have control of DLL base addresses, ncurses
support, winpthreads, and whatever else I can come up with by then.

Cheers,

Ray.

On Tue, Sep 11, 2012 at 3:30 PM, Ruben Van Boxem
 wrote:
> 2012/9/11 Ray Donnelly 
>>
>> I've merged a script and some patches [1] with the Google Android NDK
>> that allow me to cross compile Python 2.7.3 and also GDB using it
>> (built GDB then runs on Windows, Darwin or Linux). I can also build
>> these GDB/NDKs for 32 and 64bit on each of these hosts. The link I've
>> pasted is to the initial commit, there's been some bug fixes since
>> then. The cross compilation support for Python was done mostly by
>> Roumen Petrov [2] & [3], I just finished it off, adding Darwin support
>> and fixing a few MinGW problems. Maybe this could be of some use? I'm
>> hoping to get it integrated into some of the mingw-w64 toolchain build
>> scripts (Ruben's maybe?) and also upstreamed to CPython (though this
>> would be very difficult).
>
>
> Although I appreciate your efforts for allowing the building of Python with
> MinGW (and I'm hoping the efforts will be appreciated by Python upstream), I
> see absolutely no advantage over just using the offiial Python release and
> extracting the dll's from that. They will certainly work, and do not pollute
> the interwebz with somewhat incompatible Python dll's. Just my opinion
> though :)
>
> Ruben
>
>>
>>
>> [1]
>> https://android.googlesource.com/platform/ndk/+/e534e36be95815bdfa09756fa040acb2321a09c2
>> [2] http://bugs.python.org/issue3754
>> [3] http://bugs.python.org/issue3871
>>
>> Cheers,
>>
>> Ray.
>>
>> On Tue, Sep 11, 2012 at 11:40 AM,   wrote:
>> >> -Original Message-
>> >> From: ext K. Frank [mailto:kfrank2...@gmail.com]
>> >> Sent: Monday, September 10, 2012 6:19 PM
>> >> To: mingw-w64-public@lists.sourceforge.net
>> >> Subject: Re: [Mingw-w64-public] Fwd: [Development] Choosing a new MinGW
>> >> for Qt 5
>> >>
>> >> I'm not using python for anything, so I don't care one way or another.
>> >> If not using python would solve the slow gdb start-up problem, I'd give
>> >> it a try,
>> >> but, if I understand you correctly, you're saying that that's not the
>> >> problem.
>> >
>> > Adding to that, Qt Creator nowadays _requires_ a Python-enabled gdb. So
>> > if we're talking about a MinGW-64 package suited for Qt development,
>> > disabling python is a no-go.
>> >
>> > Regards
>> >
>> > Kai
>> >
>> >
>> > --
>> > Live Security Virtual Conference
>> > Exclusive live event will cover all the ways today's security and
>> > threat landscape has changed and how IT managers can respond.
>> > Discussions
>> > will include endpoint security, mobile security and the latest in
>> > malware
>> > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> > ___
>> > Mingw-w64-public mailing list
>> > Mingw-w64-public@lists.sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>>
>>
>> --
>> Live Security Virtual Conference
>> Exclusive live event will cover all the ways today's security and
>> threat landscape has changed and how IT managers can respond. Discussions
>> will include endpoint security, mobile security and the latest in malware
>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/501

Re: [Mingw-w64-public] cc1plus.exe crash (x86_64-mingw-w64-gcc-4.7.1-release-c, c++, fortran-sjlj-rev3.7z)

[Ray Donnelly]

On Tue, Sep 11, 2012 at 2:16 PM,   wrote:
>
>> -Original Message-
>> From: ext Ray Donnelly [mailto:mingw.andr...@gmail.com]
>> Sent: Tuesday, September 11, 2012 2:19 PM
>> To: mingw-w64-public@lists.sourceforge.net
>> Subject: Re: [Mingw-w64-public] cc1plus.exe crash (x86_64-mingw-w64-gcc-
>> 4.7.1-release-c, c++, fortran-sjlj-rev3.7z)
>>
>> If you do --save-temps and put the .ii file somewhere then someone might be
>> able to diagnose better.
>
> Hi Ray,
>
> Thanks for the tip. Adding --save-temps does generate an 
> qdesigner_components.ii file, but it's empty :(
>
> Regards
>
> Kai

Hmm, tricky! I'm guessing it crashes before flushing the file writes
in that case. Well, you could just preprocess the code (try adding
-E):

http://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html

Cheers,

Ray.

>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] libopengl32.a

[Ray Donnelly]

I'd look into angleproject if I was looking to do OpenGL programming
on Windows. It's what all the cool kids are doing anyway.

On Thu, Sep 13, 2012 at 9:39 AM, CanisMajorWuff
 wrote:
> Hello,
>
> I have not found libopengl32.a in rubenvb build
> (x86_64-w64-mingw32-gcc-4.7.1-2-release-win64_rubenvb).
> Could somebody suggest me  where I can get this library?
>
> With best regards,
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building a 64-bit Python-enabled GDB

[Ray Donnelly]

Hi John,

Not sure you'll be interested but I build my own version of Python
into some Android NDKs, and this Python is cross compilable/compiled.
>From a Linux box, 12 variants can be built (Windows, Mac, Linux) *
(x86, x86_64) * (2.7.3, 3.3.0b1). Native shouldn't be much of a
stretch too but it's not something I've tried. Here are the some 2.7.3
Windows builds I made.

http://mingw-and-ndk.googlecode.com/files/python-2.7.3-windows-x86.7z
http://mingw-and-ndk.googlecode.com/files/python-2.7.3-windows-x86_64.7z

As these were built specifically for GDB, part of my changes are to
output a shell script (bin/python-config.sh) the path to which can be
passed in as --with-python= ... with one caveat, you should modify in
that script the bit that says:
prefix="/tmp/cr-build/install/windows-x86_64/python-2.7.3" to mirror
where you extracted it to.

The sources for this project are currently on my Dropbox (as I'm not
100% ready to release - e.g. I'd want to update from 3.3.0b1 to a
non-beta and also make tcl/tk work for Idle first):

https://dl.dropbox.com/u/17108768/crucifixion-freedom.7z

Cheers,

Ray.

On Sat, Sep 15, 2012 at 4:32 AM, John E. / TDM  wrote:
> Hi all,
>
> Having finally gotten what may be a decent build of GCC 4.7.1, I'm
> moving on to GDB and looking at the possibility of bringing in Python
> support this time. However, I'm having trouble finding the appropriate
> headers and libraries to point GDB at for the build (x86_64-w64-mingw32
> host, x86_64-w64-mingw32 target).
>
> The best thing I've found so far is a file named
> "python-x86_64-w64-mingw32.zip" within rubenvb's 4.7.1 source tarball.
> However, I'm extremely hesitant to use it because it doesn't contain any
> sources, or build instructions, for the libraries it contains. Oh, and
> if I have to download MSVC and build Python myself, forget it.
>
> Ruben, do you have any clarifying information on your source? Or does
> anyone else have notes on how to create a 64-bit Python-enabled GDB?
>
> Thanks in advance,
> John E. / TDM
>
> --
> How fast is your code?
> 3 out of 4 devs don\\\'t know how their code performs in production.
> Find out how slow your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219672;13503038;z?
> 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

--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
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] Building a 64-bit Python-enabled GDB

[Ray Donnelly]

I explicitly set my path at the top of main in my gdb so that it finds
my Python every time. It's never failed. I also renamed python27.dll
to python2.7.dll to make sure that dll hell doesn't bite me.

In ~1.5 years I've had 0 complaints of problems with Python.

Vanilla is boring ;-)

Cheers,

Ray.

On Sat, Sep 15, 2012 at 3:41 PM, Ruben Van Boxem
 wrote:
> 2012/9/15 John E. / TDM 
>
>> Hi all,
>>
>> Having finally gotten what may be a decent build of GCC 4.7.1, I'm
>> moving on to GDB and looking at the possibility of bringing in Python
>> support this time. However, I'm having trouble finding the appropriate
>> headers and libraries to point GDB at for the build (x86_64-w64-mingw32
>> host, x86_64-w64-mingw32 target).
>>
>>
>> The best thing I've found so far is a file named
>> "python-x86_64-w64-mingw32.zip" within rubenvb's 4.7.1 source tarball.
>> However, I'm extremely hesitant to use it because it doesn't contain any
>> sources, or build instructions, for the libraries it contains. Oh, and
>> if I have to download MSVC and build Python myself, forget it.
>>
>> Ruben, do you have any clarifying information on your source? Or does
>> anyone else have notes on how to create a 64-bit Python-enabled GDB?
>>
>
> Hi,
>
> These files are just the stuff needed by Python/GDB to work and build. Check
> my scripts for python and gdb here:
> https://github.com/rubenvb/MinGW-w64-build-scripts/tree/master/scripts
>
> These files are from the official Python 2.7.3 installation exetables. They
> are the only official python builds available. You cannot build vanilla
> Python 2.7 with MinGW. I opted for the official release to not conflict with
> any existing installation users might have installed (as the python DLL will
> be in PATH)
>
> The 32-bit files are all directly extracted from the installer exe, the
> 64-bit package was missing an import libpython2.7.dll.a, which I generated
> using the usual steps. I think I also renamed the libraries so the gdb build
> can find it.
>
> If you need any more information, feel free to ask.
>
> Ruben
>
>
>>
>> Thanks in advance,
>> John E. / TDM
>>
>>
>> --
>> How fast is your code?
>> 3 out of 4 devs don\\\'t know how their code performs in production.
>> Find out how slow your code is with AppDynamics Lite.
>> http://ad.doubleclick.net/clk;262219672;13503038;z?
>> 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
>
>
>
> --
> How fast is your code?
> 3 out of 4 devs don\\\'t know how their code performs in production.
> Find out how slow your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219672;13503038;z?
> 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
>

--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
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] Building a 64-bit Python-enabled GDB

[Ray Donnelly]

In the Google NDK git repo:

https://android-review.googlesource.com/#/c/39651/

build/tools/toolchain-patches/gdb/0007-find-python.patch

Now that I re-read it, it's all about setting PYTHONHOME env var; the
dll is of course found by being in the same folder as gdb.exe (and
differently named from CPython's one).

For determining PYTHONHOME it expects a certain relative layout but
also does some searching (I wanted to be a bit defensive in case the
install prefix got modified).

Did you try to build Python yet using
https://dl.dropbox.com/u/17108768/crucifixion-freedom.7z ?

Cheers,

Ray.

On Sat, Sep 15, 2012 at 4:29 PM, niXman  wrote:
> 2012/9/15 Ray Donnelly:
>> I explicitly set my path at the top of main in my gdb so that it finds
>> my Python every time. It's never failed. I also renamed python27.dll
>> to python2.7.dll to make sure that dll hell doesn't bite me.
>
> Hi,
>
> Where can I find this patch? ;)
> Thank tou!
>
>
> --
> Regards,
> niXman
> ___
> Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
> http://sourceforge.net/projects/mingwbuilds/
>
> --
> How fast is your code?
> 3 out of 4 devs don\\\'t know how their code performs in production.
> Find out how slow your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219672;13503038;z?
> 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

--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
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] Building a 64-bit Python-enabled GDB

[Ray Donnelly]

Weird. Dropbox playing up.

I uploaded it to my google code page instead:

http://mingw-and-ndk.googlecode.com/files/crucifixion-freedom.7z

Cheers,

Ray.

On Sat, Sep 15, 2012 at 5:01 PM, niXman  wrote:
> 2012/9/15 Ray Donnelly:
>
>> Did you try to build Python yet using
>> https://dl.dropbox.com/u/17108768/crucifixion-freedom.7z ?
>
> No.
> I get an error 404.
>
>
> --
> Regards,
> niXman
> ___
> Dual-target(32 & 64 bit) MinGW compilers for 32 and 64 bit Windows:
> http://sourceforge.net/projects/mingwbuilds/
>
> --
> How fast is your code?
> 3 out of 4 devs don\\\'t know how their code performs in production.
> Find out how slow your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219672;13503038;z?
> 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

--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
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] Building a 64-bit Python-enabled GDB

[Ray Donnelly]

> Can you tell me what advantage(s) your version would have for Windows native 
> users?

I'm not sure Python integration into GDB is something that users are
going to really notice. Mostly they're going to see their QStrings
displayed nicely and the same for their STL containers and not think
twice about how it's happening!

Well it's like you said, binary vs source and also the usual msvc dll
debuggability issues.

My method compiles the Python project's sources (with a few patches,
granted) using compilers I trust.

There's always the test-suite if you want some extra re-assurance that
things are working correctly. I'm not going to pretend that there
aren't differences, but for the task of embedding into GDB (and any
other task I've put them to) I've never had any problems, both with Qt
Creator's pretty-printers, and the STL ones.

I'm starting to repeat myself a bit, but in terms of stability, my NDK
releases have had this GDB integration for ages now - the recent
difference is that now it is cross compiled and updated to 2.7.3 and
3.3.0b2. The Windows version of the Necessitas Android Qt SDK has had
> 13,000 downloads (and that was a few months ago - so likely nearer
20,000 now) and not a single issue has come up with the Python GDB
integration. It just works.

The patches have been tested and merged by Google too and down the
line I'll be trying to get them into CPython.

I guess in some ways it seems a bit like debating whether to take some
msvc compiled expat libraries or to compile them from source. They'll
both parse XML, but I know I'd rather build the software I release
myself so I can investigate and fix it if it ever goes wrong.

Cheers,

Ray.

On Sat, Sep 15, 2012 at 9:55 PM, John E. / TDM  wrote:
> On 9/15/2012 1:30 AM, Ray Donnelly wrote:
>> Hi John,
>>
>> Not sure you'll be interested but I build my own version of Python
>> into some Android NDKs, and this Python is cross compilable/compiled.
>> >From a Linux box, 12 variants can be built (Windows, Mac, Linux) *
>> (x86, x86_64) * (2.7.3, 3.3.0b1). Native shouldn't be much of a
>> stretch too but it's not something I've tried. Here are the some 2.7.3
>> Windows builds I made.
>
> Thanks for the input. Ultimately it seems to me that Ruben's method will
> prove the most stable, as it compiles directly against the Python
> project's own released binaries. Can you tell me what advantage(s) your
> version would have for Windows native users?
>
> -John E. / TDM
>
> --
> How fast is your code?
> 3 out of 4 devs don\\\'t know how their code performs in production.
> Find out how slow your code is with AppDynamics Lite.
> http://ad.doubleclick.net/clk;262219672;13503038;z?
> 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

--
How fast is your code?
3 out of 4 devs don\\\'t know how their code performs in production.
Find out how slow your code is with AppDynamics Lite.
http://ad.doubleclick.net/clk;262219672;13503038;z?
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] Building a 64-bit Python-enabled

[Ray Donnelly]

On Mon, Sep 17, 2012 at 4:49 PM, Thomas Stover  wrote:
>> From: Ray Donnelly 
>
>> Not sure you'll be interested but I build my own version of Python
>> into some Android NDKs, and this Python is cross compilable/compiled.
>>>From a Linux box, 12 variants can be built (Windows, Mac, Linux) *
>> (x86, x86_64) * (2.7.3, 3.3.0b1). Native shouldn't be much of a
>
> I'll check this out for sure. Last time I checked building python with 
> *mingw* was impossible, and so was cross compilation of any kind. Both of 
> which were major issues.

Great, let me know how you get on. Most of the credit for Python cross
and MinGW support must go to Roumen Petrov, my part was just to finish
off some parts (though as always there's a few more things I should
do) and to make it work for Darwin.

Ray.

>
> www.thomasstover.com
>
>
>
> --
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Mingw-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

[Ray Donnelly]

Hi guys,

Is there any chance this minor fix could be put into the branches?

http://sourceforge.net/tracker/?func=detail&aid=3533362&group_id=202880&atid=983356

Cheers,

Ray.

On Thu, Sep 20, 2012 at 9:17 PM, Ozkan Sezer  wrote:
> On 9/20/12, Kai Tietz  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

[Ray Donnelly]

Many thanks!

On Thu, Sep 20, 2012 at 9:58 PM, Ozkan Sezer  wrote:
> On 9/20/12, Kai Tietz  wrote:
>> Hi Ray,
>>
>> 2012/9/20 Ray Donnelly :
>>> Hi guys,
>>>
>>> Is there any chance this minor fix could be put into the branches?
>>>
>>> http://sourceforge.net/tracker/?func=detail&aid=3533362&group_id=202880&atid=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

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

[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  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

[Ray Donnelly]

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!

>
> Corinna
>
>>
>> On Fri, Oct 26, 2012 at 4:00 PM, Corinna Vinschen  
>> 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

[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
 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

[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
 wrote:
> On Fri, Oct 26, 2012 at 12:27 PM, Ruben Van Boxem
>  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] incorrect syntax while building QT 4.8.3

[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  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/3rdp

Re: [Mingw-w64-public] incorrect syntax while building QT 4.8.3

[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  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  
>> 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&

Re: [Mingw-w64-public] incorrect syntax while building QT 4.8.3

[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
 wrote:
> 2012/11/2 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.
>
>
> 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 
>> 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
>> >>  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

Re: [Mingw-w64-public] Standard library installation paths?

[Ray Donnelly]

For reliability, cross compiling on Linux is always a good idea.

On Thu, Nov 8, 2012 at 3:30 PM, Václav Šmilauer  wrote:
>
>>> I am currently compiling several 3rd-party libraries which I need for my
>>> code. Among those are glib, VTK, Qt and perhaps several others. I have
>>> the (32bit) MSYS installed, which provides standard directories like
>>> /usr/lib, /usr/include, ...
>> These should not be present, if they are, it is likely it is ONLY for
>> MSYS development, which you are not clearly doing, so please move them
>> away for safety.
> Ok for headers; I unstalled all msys-lib* packages and /usr/lib is now
> empty as well. Good.
>>> When configuring libs, I use --prefix=/c/MinGW64 to not to install them
>>> into the 32bit MSYS tree, but I fear that I will have comflicts between
>>> 32bit/64bit headers, as the 32bit ones are in the default search path.
>>> Secondly, it is a bit tedious to install everything to non-default
>>> paths. Is there some solution to this I am overseeing?
>> Use proper CPPFLAGS and LDFLAGS instead, there is no easy way to deal
>> with this.
> Ok.
>>> Second thing which comes to my mind: are there perhaps some pre-built
>>> packages for common libraries? How about the cross-packages from Fedora,
>>> couldn't they be just unpacked and used?
>> You could, but you may run into ABI problems if you don't have the exact
>> compiler configuration. YMMV.
> I will try not to use pre-compiled for now.
>
> I will have quite a few scripts (wget, unpack, patch, configure, make,
> make install) for various libs; will post it somewhere later. Perhaps
> someone will find it useful.
>> There is no 64bit MSYS. If you mean to build make with mingw-w64,
>> don't, MSYS make and mingw32-make are completely different and fulfill
>> different roles.
> Yes, I meant building 64bit make with mingw-w64. Currently, the "make"
> binary is the i686-pc-msys one. I will keep using it, then.
>> Check for BLODA instead. See
>> 
> Good pointer, thanks. Not clear how to disable Catalyst, having an ATI
> graphics card, though.
>
> Cheers, Václav
>
> --
> 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_nov
> ___
> 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_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?

[Ray Donnelly]

On Nov 18, 2012 6:25 PM, "Ruben Van Boxem"  wrote:
>
> 2012/11/5 Yves 
>>
>> 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  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 
wrote:
>>>
 2012/11/2 Yves Perron 
>
> 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
, std::to_string, and ) you will find GCC's libstdc++
unfortunately lacking. Everything else is usually implemented better than
on MSVC though, including .

 To use CMake, just be sure "g++" is in PATH, and run
 cmake path/to/source -G"MinGW 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 comma

Re: [Mingw-w64-public] MinWG64 on Windows, for Windows?

[Ray Donnelly]

On Mon, Nov 19, 2012 at 1:32 PM, Earnie Boyd
 wrote:
> On Sun, Nov 18, 2012 at 1:25 PM, Ruben Van Boxem
>  wrote:
>> 2012/11/5 Yves 
>>>
>>> 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?

[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
 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] [Mingw-users] Thoughts on how to build a linux / visual studio project (QuickFIX) with mingw

[Ray Donnelly]

I've had a quick look at the source code and it's littered with stuff like:

#ifdef _MSC_VER
#include 
...

So the fact is that the code itself conflates Windows builds with the
MSVC compiler via _MSC_VER

..you could in theory do something awful like ./configure
CFLAGS="-D_MSC_VER=" but the conflation will still
bite you due to things like:

#ifdef _MSC_VER
#pragma warning( disable : 4503 4355 4786 4290 )

...so no matter what build system you try to add or improve, a lot of
source files will have to be altered to remove the conflation.
Usually, it would end being lots of orthogonal
header/declaration/function and library tests, to unconflate using
autotools for example the Winsock2.h include would be compile-guarded
instead with #if HAVE_WINSOCK2_H

My personal opinion is that the only sensible way to proceed is to use
autotools because:
1. Autotools is/are fine when you get used to them, yes there's some
stuff to learn (see the resources I link to later), but it's
transferable knowledge.
2. Hand writing a Makefile is a lot of one-off-work for any single project.
3. An autotooling patch to support MSYS builds might benefit the
QuickFix project if they were willing to accept it (you could ask them
beforehand).

You mentioned CodeLite. This is irrelevant to this discussion; AFAICT,
it's an IDE and a pretty basic one at that. If you wanted to use a C++
IDE I'd go for Qt Creator because it's got an autotools plugin (it
worked fairly well when I tried it). I'm a big fan of Qt Creator
though.

You said that you didn't have MSYS and didn't want hassle setting it
up. I made a script to bootstrap a MinGW-w64 and MSYS environment that
might work for you:
https://raw.github.com/mingwandroid/crucifixion-freedom/master/scripts/windows/BootstrapMinGW64.vbs

Here are some free resources for autotools:
http://sourceware.org/autobook/
http://www.lrde.epita.fr/~adl/dl/autotools.pdf
http://www.flameeyes.eu/autotools-mythbuster/
https://www.gnu.org/software/autoconf-archive/

There's also a book you can buy:
http://nostarch.com/autotools.htm

Finally, I recommend console2 for any MSYS work. It's really good.
http://sourceforge.net/projects/console/

Good luck,

Ray.

On Sun, Jan 6, 2013 at 2:48 PM, JonY  wrote:
> On 1/6/2013 21:38, Ruben Van Boxem wrote:
>>
>> I'll try to clarify my point one more time: yes it is possible in autotools
>> to exclude code depending on configure. But that is not an autotools
>> specific feature. Code and/or build systems not meant to be used on
>> platforms that weren't in the dev's thoughts when written will not work.
>> And because autotools is very Unix-centric, chances are a lot higher that
>> they were written for Unix, and not with Windows in mind. This is a
>> practical/statistical fact, not some disadvantage of autotools.
>
> The statistics still do not mean autotools make Unix API a requirement,
> does it?
>
> The author already said it was working with MSVC, at which it was
> suggested he added mingw support to the configure scripts to follow the
> MSVC project if he wanted flexibility rather than adding yet another
> build system.
>
>
>
> --
> 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. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_123012
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
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. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
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-users] Thoughts on how to build a linux / visual studio project (QuickFIX) with mingw

[Ray Donnelly]

Yes,

That's precisely what I meant by the word "conflates".

On Sun, Jan 6, 2013 at 4:41 PM, Earnie Boyd
 wrote:
> On Sun, Jan 6, 2013 at 11:35 AM, Ray Donnelly wrote:
>> I've had a quick look at the source code and it's littered with stuff like:
>>
>> #ifdef _MSC_VER
>
> Which is the wrong MACRO to detect Windows build.  It is the right
> MACRO to detect using MSVC.
>
>> #include 
>> ...
>>
>> So the fact is that the code itself conflates Windows builds with the
>> MSVC compiler via _MSC_VER
>>
>> ..you could in theory do something awful like ./configure
>> CFLAGS="-D_MSC_VER=" but the conflation will still
>> bite you due to things like:
>>
>> #ifdef _MSC_VER
>> #pragma warning( disable : 4503 4355 4786 4290 )
>>
>
> This is the correct MACRO to use for compiler specific things like this.
>
> So to get this to build correctly with GCC you'll need to determine
> which items in the code identified by _MSC_VER should really be _WIN32
> and change them.
>
> --
> Earnie
> -- https://sites.google.com/site/earnieboyd
>
> --
> 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. ON SALE this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_123012
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
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. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012
___
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?)

[Ray Donnelly]

Just fix MSYS Autotooling for the whole thing and use libxml2!

;-)

On Thu, Jan 10, 2013 at 12:09 PM, pavel  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  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  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

[Mingw-w64-public] Patch for widl Makefile rule bug when builddir!=srcdir

[Ray Donnelly]

Cheers,

Ray.


mingw-w64-widl.patch
Description: Binary data
--
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. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_123012___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] MSYS alternative as a process-managing shell

[Ray Donnelly]

unixy utils built with Boost? Very cool. It'd be nice if an explicit
goal was cross compilation on many different OSes.

...but why not pitch in with MSYS2 instead? Your time, your choice, of
course; both are very worthy projects I think.

On Wed, Jan 16, 2013 at 8:37 AM, Ruben Van Boxem
 wrote:
> 2013/1/14 JonY 
>>
>> On 1/14/2013 22:49, Ruben Van Boxem wrote:
>> > That is of course a difficult one. Either internal bookkeeping or a
>> > simple
>> > (?) translation function *where need be* (the hardest part being the
>> > latter
>> > of course). MSYS achieves this somehow, so I'd start there.
>> >
>> >
>>
>> MSYS is pretty bad at path translation, it was what drove me to Cygwin
>> in the first place. Perhaps some setting on how aggressive it scans and
>> assumes a string as a path is a good idea.
>>
>> gcc -c abc.c -Dfoo="/bar1/bar2" <- is this a path to translate or just
>> some string?
>>
>> Unfortunately, it is impossible to tell without peering into the actual
>> code for context.
>
>
> I assume Cygwin keeps track of an internal filesystem? I know that's how it
> does symlinks; they are useless files outside the Cygwin environment.
>>
>>
>> >>
>> >>> If you could give me a real-world (albeit simple) example of some sh
>> >>> trickery that is impossible to implement (without e.g. the fully
>> >>> spec'ed
>> >>> functionality of fork()), I would love to know so I can dump this
>> >>> crazy
>> >>> idea in the trash can before I spend any lost time in it.
>> >>
>> >> Sh itself doesn't actually need full spec fork, since it has no concept
>> >> of memory addresses. The hard part is the other Unix apps that already
>> >> use fork calls in C.
>> >>
>> >
>> > That's good news, the C programs will need porting as I've said before
>> > in
>> > sofar the ports don't already exist.
>> >
>> >
>>
>> Hopefully, you don't repeat the unmaintainable mess that is GnuWin32.
>
>
> I've thought a lot about picking that up, right now I think implementing
> them on top of Boost is the only feasible and realistic option. It carries
> most (if not all) of the low level algorithms and code, time-tested and
> efficient.
>
>>
>> >>
>> >> Another hard part is the fork/exec pairs. As you run exec, the process
>> >> is expected to still have the same pid. It is possible to have a
>> >> process
>> >> to dump it's pid before exec'ing something else. Not sure how to
>> >> accomplish this in Windows without some external bookkeeping.
>> >
>> >
>> > That sounds like something that falls under the scope of the sh
>> > interpreter. I'm not sure how relevant this is when we have fully Win32
>> > native Unix-like utilities though.
>> >
>>
>> Well, there's that echo $$ > .pid && exec ... pair calls.
>
>
> I'll see how I can handle those. Perhaps an internal pid bookkeeping might
> be useful.
>
> In the meantime, I've written the basic skeleton layout of a new Unix Tools
> For Windows:
> https://github.com/rubenvb/UnixToolsForWindows
> (the readme with useful info is at the bottom)
>
> People who want to help, please do :). Boost is the underlying framework to
> be used. As I'm new to it (as a whole, some small parts I've used before)
> myself, I'm going to start with "echo" and "date", which will give me a
> little experience with program_options and date_time.
>
> Note I am reinventing the wheel, but in a hopefully useful way.
>
> Cheers,
>
> Ruben
>
>>
>>
>>
>>
>>
>>
>>
>> --
>> 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
>>
>
>
> --
> Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
> and much more. Keep your Java skills current with LearnJavaNow -
> 200+ hours of step-by-step video tutorials by Java experts.
> SALE $49.99 this month only -- learn more at:
> http://p.sf.net/sfu/learnmore_122612
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>

--
Master Java SE, Java EE, Eclipse, Spring, Hibernate, JavaScript, jQuery
and much more. Keep your Java skills current with LearnJavaNow -
200+ hours of step-by-step video tutorials by Java experts.
SALE $49.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122612 
___
Mingw-w64-public mailing list

Re: [Mingw-w64-public] [Mingwbuilds-users] Qt 5.0.1 binary packages with MinGW-builds toolchain

[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  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] Patch for widl Makefile rule bug when builddir!=srcdir

[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  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] Patch for widl Makefile rule bug when builddir!=srcdir

[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  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  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

[Ray Donnelly]

Hi Jacek,

I hope this is ok now?

Best regards,

Ray.

On Mon, Feb 11, 2013 at 12:27 PM, Ray Donnelly  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  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  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] 64bit Python bindings for libftdi1-1.0 with MinGW-w64

[Ray Donnelly]

There are mingw pythons around if you want to try that route?
On 19 Feb 2013 13:45, "Xiaofan Chen"  wrote:

> On Tue, Feb 19, 2013 at 5:22 PM, JonY  wrote:
> > On 2/19/2013 08:12, Xiaofan Chen wrote:
> >> On Tue, Feb 19, 2013 at 6:12 AM, JonY 
> 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] Using Python and Mingw64

[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
 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  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

[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
 wrote:
> Ray, Thanks for the downloads.
> When Compiling Sip i get the following error.
>
> C:\dev\sip-4.14.3>mingw32-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 
> 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
>>  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  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

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

[Ray Donnelly]

In case anyone (else) cares I needed to make some minor changes
(attached) for compiling sip with my MinGW-w64 64bit Python:

To build:

cd /tmp
wget -c 
http://garr.dl.sourceforge.net/project/pyqt/sip/sip-4.14.4/sip-4.14.4.zip
unzip sip-4.14.4.zip
cd sip-4.14.4
patch -p1 < /c/sip-4.14.4-mingw-python.patch
/c/python27.mingw64/bin/python.exe configure.py --platform=cygwin-g++
CFLAGS="-D__USE_MINGW_ANSI_STDIO -m64" LFLAGS="-m64"
CXXFLAGS="-D__USE_MINGW_ANSI_STDIO -m64"
make

I had an issue with make install, but have left that as an exercise
for anyone interested.

On Wed, Mar 13, 2013 at 2:00 PM, Ray Donnelly  wrote:
> 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
>  wrote:
>> Ray, Thanks for the downloads.
>> When Compiling Sip i get the following error.
>>
>> C:\dev\sip-4.14.3>mingw32-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 
>> 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
>>>  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  wrote:

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

[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"  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 
>
>> 2013/3/13 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.
>>>
>>
>> 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
>>>  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  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
>>> >>
>>

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

[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
 wrote:
> Op 23 mrt. 2013 19:11 schreef "NightStrike"  het
> volgende:
>
>
>>
>> On Thu, Mar 14, 2013 at 9:37 PM, Ray Donnelly 
>> 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] Python on x64

[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  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] Windows GNU Make patches

[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"  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

[Ray Donnelly]

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

>
>
>
> 2013/6/2 Ruben Van Boxem 
>
>> 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] GDB version information for ruben vb build

[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  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

[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 wrote:

> 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  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)

[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  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 
>>
>>
>> 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->Build&Run
>> 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] Is there a way to control the output file format of windres directly during building wx?

[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 wrote:

> 2013/6/4 zhangxinghai 
>
>>  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] MSYS2 GPL infringement (was Re: MSYS2)

[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  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+rDDhuLclwpAIJ7p1FX4BwIgnzbCyYxZ9u8rlRB16cntIaJk

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

[Ray Donnelly]

On Tue, Jun 11, 2013 at 1:25 PM, LRN  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] MSYS2 GPL infringement (was Re: MSYS2)

[Ray Donnelly]

I wonder if it would be possible to have a plugin system to allow for the
behaviour changes we need to cygwin.dll, so msys.dll exists and only
handles those parts and cygwin.dll loads that as a plugin, if there's no
plugin specified then everything proceeds as 'normal cygwin'.

Would you be willing to consider something like this Corinna?


On Wed, Jun 12, 2013 at 12:50 PM, Alexpux  wrote:

>
>
> --
> Alexpux
> Отправлено с помощью Sparrow 
>
> среда, 12 июня 2013 г. в 14:47, Corinna Vinschen написал:
>
> Hi Алексей,
>
> On Jun 11 21:10, Алексей Павлов wrote:
>
> Cygwin and MSYS have significantly different goals (even if MSYS is
> entirely based on Cygwin).
>
> My understanding is that MSYS is the minimal shell required to run
> autotools and get sources from internet from different repositories.
>
>
> I'm again puzzled as to the mixup between the underlying POSIX DLL
> called Cygwin/MSYS2, and the full distro (The DLL plus all tools) called
> Cygwin/MSYS2.
>
> I'm concerned about forking the Cygwin DLL.
>
> I have no problems at all if you create a distro called MSYS2 centered
> around the upstream Cygwin DLL.
>
> MSYS is about porting Unix programs to Windows without having a Posix
> emulation layer, and then (hopefully!) getting those changes up-streamed.
>
>
> But Cygwin/MSYS2, the DLL *is* a POSIX layer. You can call it a parrot,
> and it's still a POSIX layer.
>
> Typically, on MSYS, the executables that are run want to be native Win32
> where-as on Cygwin they want to be Posix and this will always be the case
> and a problem.
>
>
> Why? Cygwin (the DLL) never refused to run native applications.
>
> 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
>
> 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
>
> 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
>
> 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+
>
>
> 5. Add "-W" option to bash.exe's pwd command for compatibility with old
> MSYS.
>
>
> Bash again, the underlying Cygwin DLL is not affected.
>
> You are right
>
>
> 6. Perhaps remove /cygdrive prefix to simply typing paths. Mostly this is
> to retain compatibility with MSYS-enabled software that makes assumptions
> about /c/ being equivalent to C:/
>
> It's not necessary at all to change the Cygwin/MSYS2 DLL to make this
> happen. Just add this to /etc/fstab:
>
> none / cygdrive binary,posix=0,user 0 0
>
> Stop all Cygwin processes, login to your bash and try this:
>
> $ cd /c
> $ ls
> $Recycle.Bin Documents and Settings ProgramData System Volume Information
> bootmgr pagefile.sys Python32 Users
> BOOTNXT PerfLogs rhcygwin Windows
> cygwin Program Files swapfile.sys
> cygwin64 Program Files (x86) Symbols
>
> thanks for it!
>
> 7. Minor changes to other userland programs (such as Perl so it reports
> msys as $^O) which again helps to retain compatibility.
>
>
> Again, some tool, doesn't affect the Cygwin DLL.
>
> Not very critical for me because it can be resolved
>
> The reality is that MSYS exists and it's really old and getting in the way
> of developers, and MSYS2 is needed to replace this. I'm surprised therefore
> at the negative reaction, but really hope that MSYS2 can be viewed as a
> complimentary off-shot from Cygwin (even *hopefully* by the Cygwin
> developers!).
>
>
> 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 under

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

[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 wrote:

> 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.s

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

[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 wrote:

> 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] MinGW-w64 (64-bit/POSIX/SEH) Based on GCC 4.8.0 Regression with -O3 flag (Spotted on QtCore 4.8.5)

[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  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] End of rubenvb builds

[Ray Donnelly]

I think everyone's got their own build systems, LRN has one,
mingw-builds have theirs, Ruben has his, you've got yours (kudos for
using PowerShell though, I didn't know anyone did that ;-))

I wish I had the time to investigate porting either nix or homebrew to
Windows, but that'd just be another build system I guess, other than
that, porting the mingw-builds system to be able to use Linux and/or
Darwin as the build system would be really useful for someone to have
a try at.

On Fri, Jul 12, 2013 at 9:41 PM, Jon  wrote:
> On Fri, 12 Jul 2013 19:43:04 +0200
> Kai Tietz  wrote:
>
>> 2013/7/10 Jon :
>> >> > > While the question about what current users are using is already hard 
>> >> > > to answer, there's IMO a bigger one: What _potential_ users are there 
>> >> > > that aren't already using mingw-w64 :) I started looking into 
>> >> > > mingw-w64 maybe a year ago, only to find out that
>> >> > >   - there's no 'official' installer/ toolchain
>> >> > >   - there are a whole bunch of 'personal' builds & mingw-w64 derived 
>> >> > > projects
>> >> > >   - different projects provide a myriad of different gcc versions x 
>> >> > > architecture x exception handling mechanism x threading library 
>> >> > > combinations (and again, little hints on what is the 'recommended' 
>> >> > > configuration for most users).
>> >> > >
>> >> > ...SNIP...
>> >> >
>> >> > I do not say that not offering any option is the right way. But there
>> >> > should be something what is "default". And the "default" should be
>> >> > offered as that. It should be much more visible, and available in a
>> >> > click or two from the homepage. And last but not least, the "default"
>> >> > should not be tagged as a personal build. You should minimize the number
>> >> > of question he needs to answer to get "just some compiler to build my
>> >> > program with".
>> >> >
>> >> > To summarize, IMO, mingw-w64, although technically as good as it is,
>> >> > emits bad signals to newcomers. Unfortunately, it has always been
>> >> > repelling for new users and, I believe, it is also the reason why
>> >> > mingw-builds (although also not ideal for sure) succeeded so easily. It
>> >> > simply filled the gap in the demand, which you never attempted to fill.
>> >>
>> >> I believe everyone will concur.
>> >>
>> >> ...SNIP...
>> >>
>> >> In any case we now have the question: what would be official or even
>> >> advised?
>> >
>> > This is not a technical issue. It's primarily a mingw-w64 project 
>> > leadership and
>> > simplification challenge.
>> >
>> > It's not helpful that neither Kai nor JonY has definitively weighed in on 
>> > whether
>> > an official mingw-w64 default toolchain makes sense. Actually, that's not 
>> > true.
>> > Awhile back Kai was very involved with announcing Ruben as the new build 
>> > release
>> > mgr. I interpreted Kai's actions to mean that he felt mingw-w64 needed a 
>> > maintained,
>> > official, easy-to-use default toolchain in addition to the automated 
>> > testing builds.
>>
>> Well, I assumed I was clear about that already.  IMO it is absolutely
>> necessary that we (mingw-w64) are providing an official
>> toolchain-version, which we are recommenting.
>> To be clear here, those toolchain-releases aren't mingw-w64 releases.
>> The mingw-w64 releaes are just releases of our repository, not that of
>> combinations with other ventures.
>> And exactly this might be confusing here for some people.  A pre-build
>> toolchain release is always just "one" variant of a combination using
>> our stuff with other ventures.  That makes such releases so hard to be
>> marked as "recommented".
>> Nevertheless I agree completely that we have to provide such pre-build
>> toolchains, so that users have an easier access to our work.
>>
>>
>> > But "interpreting" or "implying" or "inferring" is not useful. Explicit 
>> > clarification
>> > from Kai and JonY as mingw-w64 leaders is needed. I suspect one reason why 
>> > this hasn't
>> > happened is that both already have too much on their plate and don't want 
>> > to set the
>> > expectation that either will be responsible for implementing and 
>> > maintaining an official
>> > toolchain like JonY appears (aweome) to be doing at 
>> > http://cygwin.mirrors.pair.com/release/gcc4/
>> > The old speak-up-and-get-stuck-with-it paradox ;)
>> >
>> > That's OK, and is why I believe the first step needs to be Kai/JonY saying 
>> > (a) "The
>> > mingw-w64 project needs an official, easy-to-use toolchain", (b) "Neither 
>> > of us
>> > have the bandwidth to implement/maintain it", and (c) "We're actively 
>> > looking for
>> > a new committer to take on this role. If this is going to happen and be 
>> > sustainable,
>> > we need your help."
>>
>> 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

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

[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  wrote:
> Hi,
>
> On Fri, Jul 12, 2013, Jon wrote:
>> On Fri, 12 Jul 2013 19:43:04 +0200
>> Kai Tietz  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=48808831&iu=/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=48808831&iu=/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

[Ray Donnelly]

Great work Alexey.

Many thanks for the /dev/null fix; I can build llvm with it successfully now.

--
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=48808831&iu=/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

[Ray Donnelly]

Will there be a new developer snapshot too or should I just unpack
this on-top of the last one and hope for the best?

On Mon, Aug 26, 2013 at 7:19 AM, niXman  wrote:
> 2013/8/26 Alexey Pavlov
>
>> New added:
>>  - mc-4.8.10 (now properly work only under mintty);
>>  - nano-2.3.2;
>
> Thank you!
>
>
> --
> 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/
>
> --
> Introducing Performance Central, a new site from SourceForge and
> AppDynamics. Performance Central is your source for news, insights,
> analysis and resources for efficient Application Performance Management.
> Visit us today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/4140/ostg.clktrk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Introducing Performance Central, a new site from SourceForge and 
AppDynamics. Performance Central is your source for news, insights, 
analysis and resources for efficient Application Performance Management. 
Visit us today!
http://pubads.g.doubleclick.net/gampad/clk?id=48897511&iu=/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

[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  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=58040911&iu=/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=58040911&iu=/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

[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  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 
> 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=58040911&iu=/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=58040911&iu=/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=58040911&iu=/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=58040911&iu=/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] Using the official MinGW (32bit) distribution and integrate/install the x64 bit toolchains (targets)

[Ray Donnelly]

Here's my HOWTO for mingw-builds compilers and MSYS2:

1. Choose an MSYS2 (latest x32 or x64 version) from:
http://sourceforge.net/projects/msys2/files/Alpha-versions/

2. Install mingw-builds' MinGW-w64 GCC, run:
http://kent.dl.sourceforge.net/project/mingwbuilds/mingw-builds-install/mingw-builds-install.exe
and select the compiler that you want, and install it to somewhere in
your msys32 or msys64 file hierarchy, in my case, I extract to
C:\msys64, ending up with C:\msys64\mingw64

3. Run MSYS2 (e.g. C:\msys64\mingw_shell.bat) and in the command prompt enter:
nano ~/.profile
and add:
PATH=/mingw64:$PATH
(change this if you didn't extract install MinGW-w64 GCC to the root
of your msys32/msys64 folder, and of course also if you didn't install
the 64-bit mingw-builds' MinGW-w64 GCC)
Ctrl-X to exit nano, select to save the file.
(vim is also provided in the latest MSYS2 releases so use that if you prefer ..)

4. Exit MSYS2 with "exit", relaunch it, and test that gcc works.

Use git, svn, hg, gcc, autotools, nano, vim, Python and whatever else
is provided to write/download/build software.

ConsoleZ is also in there, the next release will have that working
nicer out of the box.

There's MSYS2 developer tarballs (
http://sourceforge.net/projects/msys2/files/developers/ ) for people
interested in helping out on MSYS2 itself or building other MSYS2
software. If you're not sure if you want to build MSYS2 software then
you probably don't want to build MSYS2 software and should stick to
building MinGW (i.e. native Windows) software.

On Wed, Aug 28, 2013 at 11:39 PM, Jim Michaels  wrote:
>
> tutorial I just wrote, based on help I just got:
> http://jesusnjim.com/programming/just-starting/configuring-compile-environment.html
>
> 
> From: Thomas Jung 
> To: public-mingw-w64-public-5nwgofrqmnerv+lv9mx5uipxlwaov...@plane.gmane.org
> Cc: John E. / TDM 
> Sent: Monday, August 26, 2013 2:35 PM
> Subject: Re: [Mingw-w64-public] Using the official MinGW (32bit)
> distribution and integrate/install the x64 bit toolchains (targets)
>
>
>
>
> Hello John E. / TDM wrote:
>
>>> is there a complete HowTo (like a step, by step guide)
>>> how to integrate/install _in_addtition_ to the usual
>>> mingw-get-inst.exe installation, which only builds 32 bit
>>> targets? (btw, installed the latest package respository)
>> *snip*
>>> Or is this not possible?
>>>
>>> I tried TDM too but would like to "merge" install both.
>>> The official 32bit version of MinGW and the mingw-64 builds
>>> into the same toplevel-directory, usually "C:\MinGW"
>>
>> This is not recommended. The two different projects' GCC header and
>> library search orders are different enough to cause confusion when the
>> toolchain executables go looking for their runtimes. Keep your MinGW and
>> MinGW-w64 installations in separate sysroots.
>>
>> -John E. / TDM
>
> Ok, Thank you for the tip. But I don't find a "Step By Step" or
> Tutorial a HowTo to install all the usuall tools (make, msys, gdp
> and additional, but useful libs like pthreads or other useful tools
> to install within MinGW and to setup the mingw-w64 Installation.
>
> I only see the Automated builds, which inludes the basic precompiled
> compilers with unusual postfixes ... There is no installer available.
> Does anybody know such a "Guide" Tutorial or the relevant READMES
> and how to instlal tools like autoconf, etc. ?
>
> It's hard for me to see only the ${POSTFIX}_gcc.exe and how to insall
> all the other tools... perhaps I'm blind but any help would be fine
> and tips e.g. which MSYS build I should use... etc.
>
> T.
>
>
>
>
>
>
>
>
> --
> 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=58040911&iu=/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=58040911&iu=/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 la

Re: [Mingw-w64-public] MinGW and Msys Directories

[Ray Donnelly]

MSYS2 is basically Cygwin without the posix-purity stuff going and
instead a laser sharp focus on interoperability between MSYS2 tools
and Windows tools. It is "still Windows" but it uses it's own GCC that
links to (and creates software that links to) msys-2.0.dll that
provides a more posix-like set of system libraries and environment.

A regular Windows toolchain would not be the same.

On Sun, Sep 1, 2013 at 2:13 PM, Baruch Burstein  wrote:
> If I understand your answer correctly, MSYS(2) is basically just "Windows
> with POSIX tools, directory layout and paths", but it is still Windows. If
> so, hen why does it need it's own toolchain, and what are "MSYS binaries"?
> Wouldn't a regular Windows toolchain with Windows binaries be the same?
>
>
> On Sat, Aug 31, 2013 at 5:09 PM, LRN  wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 31.08.2013 17:14, wynfi...@gmail.com wrote:
>> >
>> > #1
>> >
>> > I'm sure that there is a good reason to have two very similiar root type
>> > directories such as MinGW and msys, but I can't see it. But, I am new to
>> > MinGW. To me two different pseudo root directories.
>> >
>> > Can someone explain why the two are necessary and on would not suffice?
>> > Or point me to a document which explains it?
>> >
>> > C:\MinGW  and
>> > C:\> >
>> > Also some directory has a link or is a link.  /usr?
>> >
>>
>> Welcome to the land of crazy!
>>
>> First, some clarifications:
>>
>> MinGW is a toolchain (compiler, linker, import libraries for MS
>> runtimes, headers). It works on W32 and produces pure W32 code, just
>> like MSVC does. There are two independent projects that make these
>> toolchains:
>> * mingw.org - they make mingw.org toolchains (their mailing list is
>> mingw-users at sourceforge.net)
>> * mingw-w64 - they make mingw-w64 toolchains (this is mingw-w64 mailing
>> list you're writing to).
>>
>> I won't try to explain to you which toolchain is better (spoiler:
>> mingw-w64 is).
>>
>> However, you need something to a buildsystem to drive the toolchain (run
>> it with appropriate arguments to compile things and produce binaries).
>> MSVC uses Visual Studio and Microsoft make (nmake, if i remember
>> correctly?) or some other crazy stuff.
>>
>> The decision on which buildsystem to use falls upon package developers,
>> not on mingw developers. Most free software packages are built by GNU
>> autotools (which produce GNU makefiles, which are interpreted by GNU
>> make).
>>
>> GNU Autotools use POSIX shell to run. GNU Makefiles produced by GNU
>> Autotools almost always use POSIX shell in some places. And while GNU
>> Make itself can be built for W32 (and thus may not have any POSIX
>> dependencies), these makefiles require a POSIX shell, and to produce
>> them ('configure' the package) you need a POSIX shell.
>>
>> MSYS provides a POSIX environment (including a POSIX shell, compatible
>> versions of GNU Autotools, and a POSIXly version of GNU Make) on W32.
>>
>> Thus, unless the package you are compiling uses some kind of alternative
>> buildsystem without any POSIX dependencies (CMake, SCons, plain
>> makefiles with no shell code, ), you need both
>> MinGW and MSYS.
>>
>> There are two projects that make MSYS:
>> * mignw.org - they make the original MSYS (MSYS1)
>> * some random people on the net (mostly it's just alexey) affiliated
>> mostly with mingw-w64 project - they make MSYS2
>>
>> (also, there's the Cygwin project, which has its own POSIX-only
>> environment, and its own toolchains, but to produce W32 binaries there
>> you have to cross-compile from Cygwin to W32; if you know what
>> "cross-compiling" is, and you're ok with it, then stop reading here and
>> go download&install Cygwin, and ask questions on Cygwin mailing list).
>>
>> Your MSYS is from mingw.org (i can tell from the way directories are
>> laid out).
>> I don't know which flavor of MinGW toolchains you're using though.
>>
>> At this point you should decide whether you really want to use mingw-w64
>> toolchain or a mingw.org toolchain. If it's mingw.org, then stop reading
>> and go to their mailing list and ask your questions there. If it's
>> mingw-w64, then read on.
>>
>> Since MSYS is a separate, POSIX environment, it has its own stuff - a
>> special toolchain (i686-pc-msys) that produces MSYS binaries, its own
>> set of GNU Autotools scripts. Also, all non-portable (POSIX-only) stuff
>> lives in MSYS - such as bash.
>>
>> Inside MSYS environment you have a virtual root directory and lots of
>> POSIXly things. Namely, for compatibility with real POSIX OSes, MSYS has
>> a /usr directory (which is just an alias for the root directory).
>>
>> /usr is an alias, not a link. In fact, MSYS doesn't use any symlinks at
>> all. Cygwin has its own symlink emulation (which is not compatible with
>> W32) by default (but you can make it use W32 symlinks on newer versions
>> of Winodws). MSYS2 and Cygwin tend to have more complex directory layouts.
>>
>> To keep MinGW stuff from conflictin

Re: [Mingw-w64-public] MinGW and Msys Directories

[Ray Donnelly]

Also, I already answered that question.

"MSYS2 is basically Cygwin without the posix-purity stuff going and
instead a laser sharp focus on interoperability between MSYS2 tools
and Windows tools. It is "still Windows" but it uses it's own GCC that
links to (and creates software that links to) msys-2.0.dll that
provides a more posix-like set of system libraries and environment.

A regular Windows toolchain would not be the same."

.. could you do us all a huge favour and actually bother to read the
replies people write to you, or just use Google?

On Mon, Sep 2, 2013 at 3:31 PM, Alexey Pavlov  wrote:
>
>
>
> 2013/9/2 Baruch Burstein 
>>
>> Then how is msys essentially different than cygwin?
>>
> MSYS dll has some peaces of code that translate cygwin-style paths to
> windows-style paths for non-msys programs. Also software are patched to
> properly work with windows line endings. This is primary differences between
> cygwin and msys. Under MSYS you can use native win32 gcc toolchains.
>>
>>
>> On Mon, Sep 2, 2013 at 5:25 AM, Alexey Pavlov  wrote:
>>>
>>> msys-2.0.dll is renamed and patched cygwin1.dll.
>>>
>>>
>>> 2013/9/2 Baruch Burstein 
>>>>
>>>> What is this msys-2.0.dll? What functions does it supply? How is this
>>>> different than cygwin's infamous dll?
>>>>
>>>>
>>>> On Sun, Sep 1, 2013 at 4:35 PM, Ray Donnelly 
>>>> wrote:
>>>>>
>>>>> MSYS2 is basically Cygwin without the posix-purity stuff going and
>>>>> instead a laser sharp focus on interoperability between MSYS2 tools
>>>>> and Windows tools. It is "still Windows" but it uses it's own GCC that
>>>>> links to (and creates software that links to) msys-2.0.dll that
>>>>> provides a more posix-like set of system libraries and environment.
>>>>>
>>>>> A regular Windows toolchain would not be the same.
>>>>>
>>>>> On Sun, Sep 1, 2013 at 2:13 PM, Baruch Burstein 
>>>>> wrote:
>>>>> > If I understand your answer correctly, MSYS(2) is basically just
>>>>> > "Windows
>>>>> > with POSIX tools, directory layout and paths", but it is still
>>>>> > Windows. If
>>>>> > so, hen why does it need it's own toolchain, and what are "MSYS
>>>>> > binaries"?
>>>>> > Wouldn't a regular Windows toolchain with Windows binaries be the
>>>>> > same?
>>>>> >
>>>>> >
>>>>> > On Sat, Aug 31, 2013 at 5:09 PM, LRN  wrote:
>>>>> >>
>>>>> >> -BEGIN PGP SIGNED MESSAGE-
>>>>> >> Hash: SHA1
>>>>> >>
>>>>> >> On 31.08.2013 17:14, wynfi...@gmail.com wrote:
>>>>> >> >
>>>>> >> > #1
>>>>> >> >
>>>>> >> > I'm sure that there is a good reason to have two very similiar
>>>>> >> > root type
>>>>> >> > directories such as MinGW and msys, but I can't see it. But, I am
>>>>> >> > new to
>>>>> >> > MinGW. To me two different pseudo root directories.
>>>>> >> >
>>>>> >> > Can someone explain why the two are necessary and on would not
>>>>> >> > suffice?
>>>>> >> > Or point me to a document which explains it?
>>>>> >> >
>>>>> >> > C:\MinGW  and
>>>>> >> > C:\>>>> >> >
>>>>> >> > Also some directory has a link or is a link.  /usr?
>>>>> >> >
>>>>> >>
>>>>> >> Welcome to the land of crazy!
>>>>> >>
>>>>> >> First, some clarifications:
>>>>> >>
>>>>> >> MinGW is a toolchain (compiler, linker, import libraries for MS
>>>>> >> runtimes, headers). It works on W32 and produces pure W32 code, just
>>>>> >> like MSVC does. There are two independent projects that make these
>>>>> >> toolchains:
>>>>> >> * mingw.org - they make mingw.org toolchains (their mailing list is
>>>>> >> mingw-users at sourceforge.net)
>>>>> >> * mingw-w64 - they make mingw-w64 toolchains (this is mingw-w64
>

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

[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  wrote:
> On 9/5/13, Adrien Nader  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=58041391&iu=/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=58041391&iu=/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

[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  wrote:
> On 2013-9-9 17:25, Alexey Pavlov wrote:
>> New MSYS2 snapshots:
>>
>> 32-bit:x32-msys2-beta2-20130909.tar.xz 
>> 
>>
>> 64-bit:x64-msys2-beta2-20130909.tar.xz 
>> 
>>
>> *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=64545871&iu=/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=64545871&iu=/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

[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
 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=60135991&iu=/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=60135991&iu=/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!!

[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  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  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=60136231&iu=/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=60136231&iu=/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=60136231&iu=/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?

[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  wrote:
>
> On Sat, Nov 9, 2013 at 12:11 PM, Alexpux  wrote:
>>
>>
>> 09 нояб. 2013 г., в 8:45, Jon  написал(а):
>>
>> 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=60136231&iu=/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=60136231&iu=/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

[Ray Donnelly]

I wonder if we need some Arch-linux-a-like infrastructure for this
ace-ness? Of course paying for that would be a problem ..

On Tue, Nov 12, 2013 at 5:10 PM, Zach Thibeau
 wrote:
> I'm tempted to port some of Rubens pkgbuild scripts from the aur, maybe
> setting up something similar to the aur site on archlinux
>
> On Nov 12, 2013 12:04 PM, "Alexey Pavlov"  wrote:
>>
>>
>>
>>
>> 2013/11/12 Jon 
>>>
>>> Oh Alexey you madcap.
>>>
>>> And in honor of Get to Know Your Inner Scot Day, let me be the first to
>>> shout a hearty FUCK YES.
>>>
>>> Oh hell, JonY's going to ban me...
>>>
>>> # setup a desktop shortcut with `C:\Windows\System32\cmd.exe /e:on /v:on
>>> /k C:\Apps\msys32\msys2_shell.bat`...yea mintty options!
>>>
>>> ...and:
>>>
>>> Jon@Black ~
>>> $ pacman -Syu
>>> :: Synchronizing package databases...
>>>  msys is up to date
>>> :: Starting full system upgrade...
>>>  there is nothing to do
>>>
>>> Jon@Black ~
>>> $ pacman -Sl
>>> ...[SNIP]...
>>> msys bash 4.2.045-1 [installed]
>>> msys bash-completion 2.1-1 [installed]
>>> ...[SNIP]...
>>> msys xz 5.0.5-1
>>>
>>> Jon@Black ~
>>> $ pacman -S xz
>>> resolving dependencies...
>>> looking for conflicting packages...
>>>
>>> Packages (1) xz-5.0.5-1
>>>
>>> Total Download Size:   0.12 MiB
>>> Total Installed Size:  0.85 MiB
>>>
>>> :: Proceed with installation? [Y/n]
>>> :: Retrieving packages ...
>>>  xz-5.0.5-1-i686  118.5 KiB  95.4K/s 00:01
>>> [] 100%
>>> (1/1) checking keys in keyring
>>> [] 100%
>>> (1/1) checking package integrity
>>> [] 100%
>>> (1/1) loading package files
>>> [] 100%
>>> (1/1) checking for file conflicts
>>> [] 100%
>>> (1/1) checking available disk space
>>> [] 100%
>>> (1/1) installing xz
>>> [] 100%
>>> warning: directory ownership differs on /usr/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/bin/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/doc/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/locale/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/man/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/man/man1/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/locale/cs/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/locale/de/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/locale/fr/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/locale/it/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/locale/pl/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/locale/pl/LC_MESSAGES/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/locale/it/LC_MESSAGES/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/locale/fr/LC_MESSAGES/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/locale/de/LC_MESSAGES/
>>> filesystem: 1002:513  package: 1000:513
>>> warning: directory ownership differs on /usr/share/locale/cs/LC_MESSAGES/
>>> filesystem: 1002:513  package: 1000:513
>>
>>
>>
>> I'm disable this warning and next pacman release don't show it. This
>> warning is about my uid:gid and yours conflicts. This is not fatal or
>> anything bad on windows. Pacman store my uid:gid in package database but
>> your system doesn't know my account)
>>
>> Regards,
>> Alexey.
>>
>>>
>>> Jon@Black ~
>>> $ xz --version
>>> xz (XZ Utils) 5.0.5
>>> liblzma 5.0.5
>>>
>>> Jon@Black ~
>>> $ pacman -Q | grep xz
>>> xz 5.0.5-1
>>>
>>>
>>>
>>>
>>> On Tue, Nov 12, 2013 at 7:43 AM, Alexpux  wrote:


 12 нояб. 2013 г., в 16:36, Óscar Fuentes  написал(а):

 > Hello Alexey,
 >
 > Alexey Pavlov  writes:
 >
 >> Today I want to announce that MSYS2 now has console package manager -
 >> pacman that is ported from Arch Linux. I'm still working on porting
 >> pacman
 >> but it work in general.
 >
 > It worked correctly here with
 >
 > $ pacman -Sy
 >
 > $ pacman -S git
 >
 > 
 >
 > $ git --version
 > git version 1.8.4.3
 >
 > There were lots of warnings on pacman's output, like this:
 >
 > atención: directory ownership differs on /usr/
 > filesystem: 1003:513  package: 1000:513
>>

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

[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  wrote:
>
> 14 нояб. 2013 г., в 0:56, Jon  написал(а):
>
>
>>
>> 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=63469471&iu=/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=63469471&iu=/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=63469471&iu=/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

[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,   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=111408631&iu=/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=111408631&iu=/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]

[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  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=111408631&iu=/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=111408631&iu=/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]

[Ray Donnelly]

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

On Tue, Dec 10, 2013 at 1:43 PM, asmwarrior  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=7227&action=diff)
> With this patch, I can let GDB to simulate a correct inferior call if the 
> inferior(debugee) is built from MinGW GCC version>7.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=111408631&iu=/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=111408631&iu=/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?

[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"  wrote:

> Óscar Fuentes  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=84349831&iu=/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=84349831&iu=/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

[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  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=119420431&iu=/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=119420431&iu=/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

[Ray Donnelly]

You should try Clang 3.4 in MSYS2.

On Mon, Jan 13, 2014 at 9:34 PM, Baruch Burstein  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=119420431&iu=/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=119420431&iu=/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

[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  wrote:
> On Tue, Jan 14, 2014 at 3:46 PM, Ruben Van Boxem 
> wrote:
>>
>> 2014/1/14 Baruch Burstein 
>>>
>>> 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=119420431&iu=/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=119420431&iu=/4140/ostg.clktrk
___
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] dont define strtod if __USE_MINGW_STRTOX

[Ray Donnelly]

--- stdlib.h.orig 2014-02-26 03:30:27.0 +
+++ stdlib.h 2014-03-03 14:26:29.010258800 +
@@ -409,7 +409,9 @@
   /* libmingwex.a provides a c99-compliant strtod() exported as __strtod() */
   extern double __cdecl __MINGW_NOTHROW
   __strtod (const char * __restrict__ , char ** __restrict__);
+#if !defined(__USE_MINGW_STRTOX)
 #define strtod __strtod
+#endif /* !defined(__USE_MINGW_STRTOX) */
 #endif /* __NO_ISOCEXT */

 #if !defined __NO_ISOCEXT  /* in libmingwex.a */

--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/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] current way to printf a size_type and size_t?

[Ray Donnelly]

On Sat, Mar 15, 2014 at 11:59 PM, LRN  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] Building LLVM with mingw-w64

[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
 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
> :
>
>> 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
>

--
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] Sigh! Back To Microsoft Compiler

[Ray Donnelly]

On Thu, Mar 20, 2014 at 8:33 AM, Jim Michaels  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 
> To: "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 :
>> 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=121054471&iu=/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 f

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

[Ray Donnelly]

On Sun, Mar 23, 2014 at 1:11 AM, LRN  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/ 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-

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

[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)

[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  wrote:
> 2014-04-13 17:52 GMT+02:00 Ozkan Sezer :
>> On 4/13/14, Ray Donnelly  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] Register your vote (was Re: mingw-w64 may move to git in the future)

[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  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

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

[Ray Donnelly]

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

> If I am using a separate mingw installation, which shell would I use?
>
>
> On Wed, May 7, 2014 at 9:52 PM, Alexpux  wrote:
>
>>
>> 07 мая 2014 г., в 22:45, Baruch Burstein 
>> написал(а):
>>
>> 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 wrote:
>>
>>> Thank you.
>>>
>>>
>>> On Wed, May 7, 2014 at 9:38 PM, Alexpux  wrote:
>>>

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

 32-bit:
 msys2-base-i686-20140507.tar.xz

 64-bit:
 msys2-base-x86_64-20140507.tar.xz

 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:
 • 3 signs your SCM is hindering your productivity
 • Requirements for releasing software faster
 • Expert tips and advice for migrating your SCM now

 http://p.sf.net/sfu/perforce___
 Mingw-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:
 • 3 signs your SCM is hindering your productivity
 • Requirements for releasing software faster
 • Expert tips and advice for migrating your SCM now
 http://p.sf.net/sfu/perforce
 ___
 Mingw-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:
>> • 3 signs your SCM is hindering your productivity
>> • Requirements for releasing software faster
>> • Expert tips and advice for migrating your SCM now
>>
>> http://p.sf.net/sfu/perforce___
>> Mingw-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:
>> • 3 signs your SCM is hindering your productivity
>> • Requirements for releasing software faster
>> • Expert tips and advice for migrating your SCM now
>> http://p.sf.net/sfu/perforce
>> ___
>> Mingw-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:
> • 3 signs your SCM is hindering your productivity
> • Requirements for releasing software faster
> • Expert tips and advice for migrating your SCM now
> http://p.sf.net/sfu/perforce
> ___
> Mingw-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:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce___
Mingw-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

[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:
• 3 signs your SCM is hindering your productivity
• Requirements for releasing software faster
• Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] freeimage

[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

[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

[Ray Donnelly]

.. actually, they're not prebuilt libraries, just libraries we provide
our own builds of.

On Tue, Jul 8, 2014 at 5:01 PM, Ray Donnelly  wrote:
> 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

[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] MSYS2 issues

[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