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

On Jun 7, 2017 3:19 PM, "Brad Garton" wrote: I wish I could (go the total mingw-w64 route). The libs I'm building are for use in OpenFrameworks and Unity, and I don't think mingw-w64 projects exist for them. OpenFrameworks had good support for mingw-w64 via msys2 stuff

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

MSYS2 is a software distribution with both (extremely) Cygwin-like and also native Windows software, all (usually) launched from mintty. On Nov 12, 2016 3:41 PM, "Corinna Vinschen" <vinsc...@redhat.com> wrote: > On Nov 12 14:52, Ray Donnelly wrote: > > On Nov 12, 2016 1

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

On Nov 12, 2016 1:30 PM, "Corinna Vinschen" wrote: > > On Nov 12 12:27, JonY wrote: > > On 11/12/2016 11:57, Mihail Konev wrote: > > > Applications now could call iscygtty(STDIN_FILENO) > > > in order to detect whether they are running from > > > Cygwin/MSys terminal. > > > >

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

Hi Mario, On Mon, Aug 15, 2016 at 11:29 AM, Mario Emmenlauer wrote: > > Dear All, > > I don't know how/where to report this or how to debug the issue, > please let me know what I can do. I tried upgrading protobuf to the > new 3.0.0 release in Alexpux/MINGW-packages. However

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

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

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

Here's the sqrt(x) NaN propgation patch again, this time with a reference to the IEEE standard and as a git patch. If it's ok to commit, can someone go ahead? Ray Donnelly (1): sqrt: Fix NaN propagation for IEEE Std 754-2008 mingw-w64-crt/math/sqrt.def.h | 5 ++--- 1 file changed, 2

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

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

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

On 30 Dec 2015 15:39, "lh_mouse" wrote: > > Here is a ported, standalone version of nano for Windows. (Special thanks to mingwandroid.) I only did a small amount of work ages ago, but thanks for the mention. > https://github.com/lhmouse/nano-win > > You can clone that

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

On Sat, Oct 3, 2015 at 11:46 PM, FX wrote: >> MSYS2 distributes the gcc fortran package based on mingw-w64 (see the >> output of pacman -Ss fortran). You can inspect how it is built by >> consulting its PKGBUILD recipe. It is here, along with the necessary >> patches:

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

On Sat, Aug 8, 2015 at 8:37 PM, Duane Ellis du...@duaneellis.com wrote: It's built from this project (and branch, be careful to not use master!) on github: https://github.com/Alexpux/mingw-builds/tree/develop but as I say, you want canadian cross, and well, I'll not repeat what I wrote

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

On Sat, Aug 8, 2015 at 6:22 PM, Duane Ellis du...@duaneellis.com wrote: HI, My ultimate goal is to build a number of “python enabled” instances of GDB that run on Windows. (ie: ARM, MIPS, and a few other core types) I have a candian-cross setup on my linux box, it works great for

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

On Sat, Aug 8, 2015 at 7:18 PM, Duane Ellis du...@duaneellis.com wrote: Thanks for the quick reply. MinGW-w64 doesn't have an instance of Python or an instance of a Python Enabled GDB since MinGW-w64 is a source-only project, more-or less. I assume the builds you are talking about are the

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

On Sat, Aug 8, 2015 at 7:35 PM, Ray Donnelly mingw.andr...@gmail.com wrote: On Sat, Aug 8, 2015 at 7:18 PM, Duane Ellis du...@duaneellis.com wrote: Thanks for the quick reply. MinGW-w64 doesn't have an instance of Python or an instance of a Python Enabled GDB since MinGW-w64 is a source-only

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

On Tue, May 19, 2015 at 9:27 AM, Alexpux alex...@gmail.com wrote: 19 мая 2015 г., в 10:48, Ruben Van Boxem vanboxem.ru...@gmail.com написал(а): 2015-05-19 9:22 GMT+02:00 Alexpux alex...@gmail.com: 19 мая 2015 г., в 10:09, Ruben Van Boxem vanboxem.ru...@gmail.com написал(а):

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

On 24 Mar 2015 07:06, Adrien Nader adr...@notk.org wrote: Hi, On Sat, Mar 21, 2015, Norbert Pfeiler wrote: Hi, it’s nice to see an update on the website, looks good. What I’d like to see though, is a mention of msys2 in the downloads section. The difficulty with an msys2 entry on the

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

On Fri, Jan 16, 2015 at 12:35 PM, Jacek Caban ja...@codeweavers.com wrote: Hi Ray, I'm sorry for the delay. On 01/12/15 21:41, Ray Donnelly wrote: We simply typedef it to int. */ typedef int MIB_TCP_STATE; +#include tcpmib.h MIC_TCP_STATE should be declared in tcpmib.h. Please

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

On Mon, Jan 12, 2015 at 6:44 PM, Ray Donnelly mingw.andr...@gmail.com wrote: On Thu, Jan 8, 2015 at 6:01 PM, Kai Tietz ktiet...@googlemail.com wrote: Committed to master after review on IRC by Jacek. I removed _Field_size_part_ macro use, as noted by review of Jacek. Kai 2015-01-08 17:33

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

On Thu, Jan 8, 2015 at 6:01 PM, Kai Tietz ktiet...@googlemail.com wrote: Committed to master after review on IRC by Jacek. I removed _Field_size_part_ macro use, as noted by review of Jacek. Kai 2015-01-08 17:33 GMT+01:00 Kai Tietz ktiet...@googlemail.com: Hi, Any comment on the attached

Re: [Mingw-w64-public] asctime_r duplications

to adopt it, just to kick the tyres once if you don't mind? On 1/7/15, Ray Donnelly mingw.andr...@gmail.com wrote: On Wed, Jan 7, 2015 at 11:45 AM, Dongsheng Song dongsheng.s...@gmail.com wrote: On Wed, Jan 7, 2015 at 7:33 PM, Jacek Caban ja...@codeweavers.com wrote: Hi Alexey, On 01/07/15

Re: [Mingw-w64-public] asctime_r duplications

On Wed, Jan 7, 2015 at 11:45 AM, Dongsheng Song dongsheng.s...@gmail.com wrote: On Wed, Jan 7, 2015 at 7:33 PM, Jacek Caban ja...@codeweavers.com wrote: Hi Alexey, On 01/07/15 09:06, Alexey Pavlov wrote: Ladt changes to time functions lead to multiple definitions of asctime_r in some

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

On Tue, Nov 11, 2014 at 2:02 PM, Dongsheng Song dongsheng.s...@gmail.com wrote: I think you need add 1 line like this: TODO: real thread safe implementation. Why? msvcrt is thread safe already. On Tue, Nov 11, 2014 at 8:15 PM, Martell Malone martellmal...@gmail.com wrote: Comments

Re: [Mingw-w64-public] getpid issue

On Fri, Nov 7, 2014 at 11:10 AM, Ozkan Sezer seze...@gmail.com wrote: On 11/7/14, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2014-11-07 9:25 GMT+01:00 Ozkan Sezer seze...@gmail.com: On 11/7/14, Dongsheng Song dongsheng.s...@gmail.com wrote: If we define _POSIX_, then getpid (process.h)

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

On Mon, Nov 3, 2014 at 3:45 PM, Baruch Burstein bmburst...@gmail.com wrote: On Mon, Nov 3, 2014 at 2:37 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2014-11-03 10:30 GMT+01:00 Baruch Burstein bmburst...@gmail.com: I am curious why only a few of the executables get prefixed versions? I

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

On Sun, Nov 2, 2014 at 1:19 AM, Greg Jung gvj...@gmail.com wrote: Hi guys, I am using mingw-w64 gcc v4.8.2 installed under the /mingw32 directory under mingw and I compile using msys/1.0 shell, or CMAKE from msys using MSYS Makefiles. I adopted this after installing from a recipe and found

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

I'm tired, corrections inline: On Sun, Nov 2, 2014 at 1:54 AM, Ray Donnelly mingw.andr...@gmail.com wrote: On Sun, Nov 2, 2014 at 1:19 AM, Greg Jung gvj...@gmail.com wrote: Hi guys, I am using mingw-w64 gcc v4.8.2 installed under the /mingw32 directory under mingw and I compile using msys

Re: [Mingw-w64-public] icons?

On Mon, Oct 27, 2014 at 7:38 PM, Mark Cianfaglione m.cianfagli...@valydate.com wrote: On Mon, 2014-10-27 at 19:18 +0300, LRN wrote: Is there some way to distribute the icons with the application and how is it done? Mark The thing you are searching is a resource file (.rc). By it you

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

On Sat, Oct 25, 2014 at 1:47 PM, Mark Cianfaglione m.cianfagli...@valydate.com wrote: Hi I'm using MSYS2 and Mingw-w64 on a Windows 7 64 bit system and I've got a situation where I've compiles a program that uses GTK3 but I get a cannot execute binary file: Exec format error when I try to

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

On Tue, Oct 21, 2014 at 10:57 AM, JonY jo...@users.sourceforge.net wrote: On 10/21/2014 17:50, JonY wrote: On 10/21/2014 03:58, Ray Donnelly wrote: Comments welcome. Hi, Do you mind writing better comments for the patch? A single line followed by a blank line and then a longer description

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

Thanks to Martell Malone. 0001-winpthreads-removed-legacy-time-functions-from-pthre.patch Description: Binary data -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through

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

Comments welcome. 0001-localtime_r-guard-to-_POSIX-or-_POSIX_THREAD_SAFE_FU.patch Description: Binary data -- Comprehensive Server Monitoring with Site24x7. Monitor 10 servers for $9/Month. Get alerted through email,

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

On Tue, Oct 14, 2014 at 2:26 PM, Jose Alf. jose...@rocketmail.com wrote: I would like to help to build a new installer. I suggest we use InnoSetup or NSIS. I like InnoSetup because it's easier to mantain, but NSIS generates smaller installer files. I can try to understand what the current

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

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

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

On Fri, Aug 22, 2014 at 4:14 PM, Stefan Ruppert s...@myarm.com wrote: Hi all, I have the following problem. I managed to compile our software which uses Qt 4.8.6 with g++ mingw32-w64 (rubenvb-4.7.2-release) in 32bit mode on a 64bit Windows 7 machine. All parts of our software runs correctly

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

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

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

Hi Ruben, Please take this in the friendly/jokey manner it is intended. This isn't the first time you corrected me on the return value from main when I'm making a test-case to demonstrate a compiler issue; I honestly couldn't care less and my goal is to use the minimum amount of characters and

Re: [Mingw-w64-public] MSYS2 issues

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

Re: [Mingw-w64-public] MSYS2 issues

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

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

Hello, While porting msysGit to MSYS2/MinGW-w64 we ran into this: $ PATH=/mingw64/bin:$PATH gcc --version gcc.exe (Rev1, Built by MSYS2 project) 4.9.1 $ cat test.c #include unistd.h static inline pid_t fork(void); void main() {} $ PATH=/mingw64/bin:$PATH gcc test.c test.c:2:21: warning:

Re: [Mingw-w64-public] freeimage

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

Re: [Mingw-w64-public] freeimage

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

Re: [Mingw-w64-public] freeimage

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

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

[X] Yes, move to git [ ] No, continue with SVN -- Is your legacy SCM system holding you back? Join Perforce May 7 to find out: #149; 3 signs your SCM is hindering your productivity #149; Requirements for releasing

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

msys2_shell.bat them prepend the path to your mingw-w64 onto PATH On May 7, 2014 9:01 PM, Baruch Burstein bmburst...@gmail.com wrote: If I am using a separate mingw installation, which shell would I use? On Wed, May 7, 2014 at 9:52 PM, Alexpux alex...@gmail.com wrote: 07 мая 2014 г., в

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

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

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

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

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

Can someone with commit rights take care of this for us please? Best regards, Ray. On Sun, Apr 13, 2014 at 5:35 PM, Kai Tietz ktiet...@googlemail.com wrote: 2014-04-13 17:52 GMT+02:00 Ozkan Sezer seze...@gmail.com: On 4/13/14, Ray Donnelly mingw.andr...@gmail.com wrote: Seems 3 imports were

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

On Sun, Mar 23, 2014 at 1:11 AM, LRN lrn1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 S[mart|tupid] build[1] got a minjor update = About = sbuild is a set of scripts that build various free software packages for Windows from the source, starting with a GCC toolchain

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

On Thu, Mar 20, 2014 at 8:33 AM, Jim Michaels jmich...@yahoo.com wrote: but I thought that it was said here that the win32 version does not work with sjlj in a stable way - yet? You've resurrected a month old thread with an email that is 100% non-sequitur. At no point in this this thread has

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

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

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

On Sat, Mar 15, 2014 at 11:59 PM, LRN lrn1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 16.03.2014 2:26, Jim Michaels wrote: my understanding is gcc uses size_t for both. I think there used ot be a %I or something like that for size_type, but not sure what it is now,

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

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

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

You should try Clang 3.4 in MSYS2. On Mon, Jan 13, 2014 at 9:34 PM, Baruch Burstein bmburst...@gmail.com wrote: I am trying to use Ruben's clang builds (clang 3.2). I unpacked the zip and ran `clang64env.cmd`. When I tried compiling a trivial c program, I get the error: fatal error:

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

Putting source files in anything but ascii folders is asking for trouble. Lots of trouble. Just don't. On Sat, Jan 11, 2014 at 2:38 PM, lh_mouse lh_mo...@126.com wrote: The problem happens with the encoding of the source file's path, not the file's contents. Anyway I agree with you that it is

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

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

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

Hi, Would it be possible to point me to these patches you've got? I'd like to take a look. Ray. On Tue, Dec 10, 2013 at 4:57 AM, asmwarrior asmwarr...@gmail.com wrote: On 2013-12-10 12:46, Alexpux wrote: We provide only static library for zlib and it named «libz.a». Try to search… So, I

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

Yes, that's what I was after, many thanks. On Tue, Dec 10, 2013 at 1:43 PM, asmwarrior asmwarr...@gmail.com wrote: On 2013-12-10 20:53, Ray Donnelly wrote: Hi, Would it be possible to point me to these patches you've got? I'd like to take a look. Ray. Hi, Ray, do you mean my local patches

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

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

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

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

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

Arch is also my Linux distro of choice, so this is something I am very much looking forward to using too. (More) good work Alexey! On Sat, Nov 9, 2013 at 6:46 PM, Jon jon.for...@gmail.com wrote: On Sat, Nov 9, 2013 at 12:11 PM, Alexpux alex...@gmail.com wrote: 09 нояб. 2013 г., в 8:45, Jon

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

Please leave and take care that the door doesn't hit you on the way out. On Fri, Nov 8, 2013 at 10:41 PM, Incongruous incongru...@outlook.com wrote: My oh my, you are one of them, aren't you. Wait, what about MinGW, is MinGW a tentacle of Google? -Original Message- From: Ozkan Sezer

Re: [Mingw-w64-public] MSYS2

To work around this problem you can use 7z GUI to extract and it when it asks if you want to overwrite the Python include files with a 0 byte sized one, say No to all. On Wed, Oct 23, 2013 at 11:49 AM, Rainer Emrich sf.rai...@emrich-ebersheim.de wrote: Am 22.10.2013 17:00, schrieb Alexey Pavlov:

Re: [Mingw-w64-public] MSYS2

It is because git follows the busybox method of having one executable and symlinks to it for the all the various sub-commands. symlinks and Windows don't go together for various reasons, so they are dereferenced instead. On Sun, Sep 15, 2013 at 3:56 PM, asmwarrior asmwarr...@gmail.com wrote: On

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

For most projects that use it, mingw-w64 is grabbed from svn and the releases are largely ignored. Whether that's a good thing or not is another matter of course. On Thu, Sep 5, 2013 at 3:17 PM, Roger Pack rogerdpa...@gmail.com wrote: On 9/5/13, Adrien Nader adr...@notk.org wrote: On Wed, Sep

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

Re: [Mingw-w64-public] Qt problem

-versions/ On Wed, Aug 28, 2013 at 7:31 PM, Incongruous incongru...@outlook.com wrote: nO!, mY bAd. I got the link correctly now. Thanks! -Original Message- From: Ray Donnelly Sent: Wednesday, August 28, 2013 1:46 PM To: mingw-w64-public@lists.sourceforge.net Subject: Re: [Mingw-w64

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

- package gnustep which will help test the objc toolchain Have you seen http://www.cocotron.org/ too? On Sat, Jul 13, 2013 at 12:22 PM, Adrien Nader adr...@notk.org wrote: Hi, On Fri, Jul 12, 2013, Jon wrote: On Fri, 12 Jul 2013 19:43:04 +0200 Kai Tietz ktiet...@googlemail.com wrote: a)

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)

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

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

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

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

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

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

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,

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

On Tue, Jun 11, 2013 at 1:25 PM, LRN lrn1...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11.06.2013 15:58, Ray Donnelly wrote: MSYS itself was badly fragmented by the msysgit project which uses an even earlier version of MSYS than the latest one which is also

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

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

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

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

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

Sorry, gmail fail (Enter Key caused a Send rather than a newline..) The URL for mingw-builds Qt-builds releases is: http://sourceforge.net/projects/mingwbuilds/files/external-binary-packages/Qt-Builds/ On Mon, Jun 3, 2013 at 8:11 AM, Ray Donnelly mingw.andr...@gmail.comwrote: Hi Abir, Qt

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

It seems clear to me that you should submit a patch that fixes this to Qt Project, and also if possible file the boost unit_test issue with the mingw-builds project. On Mon, Jun 3, 2013 at 9:56 AM, Abir Basak abirba...@gmail.com wrote: I was using build by Ruben for Mingw W64 for long times

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

Hi Ruben. For mingw builds the develop branches are best to track. AFAIK, all patches needed for make have been merged upstream. But Alexey will know better... On 2 Jun 2013 13:09, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: Hi everyone, I'm cleaning up my build scripts and including

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

See I told you he'd know better! On 2 Jun 2013 16:03, Алексей Павлов alex...@gmail.com wrote: 2013/6/2 Ruben Van Boxem vanboxem.ru...@gmail.com Hi everyone, Hi, Ruben! I'm cleaning up my build scripts and including automated application of patches etc. I previously had an old cvs

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

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:

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

, Ray Donnelly mingw.andr...@gmail.com wrote: Hi Ruben. It would be great to have recruit you to the cause to get these merged. My experience in that regard has been a bit frustrating. I think the patches are split up reasonably, except for the huge ones from Roumen Petrov. Due

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

Boxem vanboxem.ru...@gmail.com 2013/3/13 Ray Donnelly mingw.andr...@gmail.com You could use my Python if you want: https://mingw-and-ndk.googlecode.com/files/python-2.7.3-win64.7z https://mingw-and-ndk.googlecode.com/files/python-2.7.3-win32.7z They were compiled using MinGW-w64 compilers

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

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.

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

'objmap.o' failed mingw32-make[1]: *** [objmap.o] Error 1 mingw32-make[1]: Leaving directory 'C:/dev/sip-4.14.3/siplib' makefile:3: recipe for target 'all' failed mingw32-make: *** [all] Error 2 On Wed, Mar 13, 2013 at 2:33 PM, Ray Donnelly mingw.andr...@gmail.com wrote: You could use my

Re: [Mingw-w64-public] 64bit Python bindings for libftdi1-1.0 with MinGW-w64

There are mingw pythons around if you want to try that route? On 19 Feb 2013 13:45, Xiaofan Chen xiaof...@gmail.com wrote: On Tue, Feb 19, 2013 at 5:22 PM, JonY jo...@users.sourceforge.net wrote: On 2/19/2013 08:12, Xiaofan Chen wrote: On Tue, Feb 19, 2013 at 6:12 AM, JonY

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

Hi Jacek, I hope this is ok now? Best regards, Ray. On Mon, Feb 11, 2013 at 12:27 PM, Ray Donnelly mingw.andr...@gmail.com wrote: I think I took it as an opportunity to learn a tiny bit of automake having avoided it so far! Ho hum... an update is in progress. On Mon, Feb 11, 2013 at 10

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

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

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

Hi Jacek, Sorry for the long response time. Please find attached a new version of the patch that adds the warning you mentioned. I also named it as .a txt file and removed all auto generated files. Best regards, Ray. On Mon, Jan 14, 2013 at 12:40 PM, Jacek Caban ja...@codeweavers.com wrote:

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

See: http://dwarfstd.org/doc/DWARF4.pdf APPENDIX E--DWARF COMPRESSION DUPLICATE ELIMINATION (INFORMATIVE) I've no idea what state they're in for GCC/GDB for Windows. On Thu, Jan 31, 2013 at 2:31 PM, niXman i.nix...@gmail.com wrote: 2013/1/31 Koehne Kai: the difference is actually in the

Re: [Mingw-w64-public] msxml with mingw-w64 (for QuickFIX) (was: libxml2 with mingw-w64?)

Just fix MSYS Autotooling for the whole thing and use libxml2! ;-) On Thu, Jan 10, 2013 at 12:09 PM, pavel pa...@pamsoft.cz wrote: Hi Frank, I think you should definitively use msxml2.h. I use msxml quite often in my applications, but I have my own generated include file, which contains the

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

On Mon, Nov 19, 2012 at 1:32 PM, Earnie Boyd ear...@users.sourceforge.net wrote: On Sun, Nov 18, 2012 at 1:25 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2012/11/5 Yves yves.per...@modusfx.com Hi Ruben, All the while I tried all packages, since I`m still oscillating between 32 bit

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

...@users.sourceforge.net wrote: On Mon, Nov 19, 2012 at 8:37 AM, Ray Donnelly wrote: On Mon, Nov 19, 2012 at 1:32 PM, Earnie Boyd You may need to build it yourself using the GCC sources. I need to create a document for doing this so I can just point to it. Even better, you could encode your knowledge

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

On Nov 18, 2012 6:25 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2012/11/5 Yves yves.per...@modusfx.com Hi Ruben, All the while I tried all packages, since I`m still oscillating between 32 bit and 64 bit, TDM seemed to be the way to go, at least to compile to compile on Windows for

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

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,

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

, CanisMajorWuff canismajorw...@gmail.com wrote: I am using make from. Do you mean to use another make? On 11/2/2012 2:19 PM, Ray Donnelly wrote: Yeah, that's usually down to the way MSYS bash implements fork-like behaviour... It's in intermittent thing, I usually wrap my calls to make up

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

-make.exe specifically to avoid more confusion. I intend my make.exe to (one day) be able to also work from MSYS (by hand parsing fstab), cmd.exe and whatever else I can throw it at. On Fri, Nov 2, 2012 at 1:34 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: 2012/11/2 Ray Donnelly mingw.andr

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

I've never seen any precedent of anyone ever doing this anywhere. Are you saying we are all in violation here? If so, 'we' includes a huge amount of developers and applications (every Windows C++ application built with GCC!) On Fri, Oct 26, 2012 at 4:00 PM, Corinna Vinschen vinsc...@redhat.com

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

On Fri, Oct 26, 2012 at 4:38 PM, Corinna Vinschen vinsc...@redhat.com wrote: On Oct 26 16:10, Ray Donnelly wrote: I've never seen any precedent of anyone ever doing this anywhere. Are you saying we are all in violation here? If so, 'we' includes a huge amount of developers and applications

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

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

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

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

Re: [Mingw-w64-public] UpdateLayeredWindowIndirect missing in lib32/user32.def

Hi guys, Is there any chance this minor fix could be put into the branches? http://sourceforge.net/tracker/?func=detailaid=3533362group_id=202880atid=983356 Cheers, Ray. On Thu, Sep 20, 2012 at 9:17 PM, Ozkan Sezer seze...@gmail.com wrote: On 9/20/12, Kai Tietz ktiet...@googlemail.com wrote:

Re: [Mingw-w64-public] UpdateLayeredWindowIndirect missing in lib32/user32.def

Many thanks! On Thu, Sep 20, 2012 at 9:58 PM, Ozkan Sezer seze...@gmail.com wrote: On 9/20/12, Kai Tietz ktiet...@googlemail.com wrote: Hi Ray, 2012/9/20 Ray Donnelly mingw.andr...@gmail.com: Hi guys, Is there any chance this minor fix could be put into the branches? http

  1   2   >