On Jun 7, 2017 3:19 PM, "Brad Garton" wrote:
I wish I could (go the total mingw-w64 route). The libs I'm building are
for use in OpenFrameworks and Unity, and I don't think mingw-w64 projects
exist for them.
OpenFrameworks had good support for mingw-w64 via msys2 stuff last time I
checked. Uni
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" wrote:
> On Nov 12 14:52, Ray Donnelly wrote:
> > On Nov 12, 2016 1:30 PM, "
On Nov 12, 2016 1:30 PM, "Corinna Vinschen" wrote:
>
> On Nov 12 12:27, JonY wrote:
> > On 11/12/2016 11:57, Mihail Konev wrote:
> > > Applications now could call iscygtty(STDIN_FILENO)
> > > in order to detect whether they are running from
> > > Cygwin/MSys terminal.
> > >
> > > Without that, the
Hi Mario,
On Mon, Aug 15, 2016 at 11:29 AM, Mario Emmenlauer wrote:
>
> Dear All,
>
> I don't know how/where to report this or how to debug the issue,
> please let me know what I can do. I tried upgrading protobuf to the
> new 3.0.0 release in Alexpux/MINGW-packages. However gcc hangs when
> comp
The R language has some hacks specifically for mingw-w64 that
were caused by our handling of NaNs in sqrt(x). R uses a
special valued NaN to mean 'Not Available' and expects it to
be retained through various calculations. Our sqrt(x) doesn't
do this, instead it normalises such a NaN (retaining sign
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
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 so
On 30 Dec 2015 15:39, "lh_mouse" wrote:
>
> Here is a ported, standalone version of nano for Windows. (Special thanks
to mingwandroid.)
I only did a small amount of work ages ago, but thanks for the mention.
> https://github.com/lhmouse/nano-win
>
> You can clone that repository then run ./BUILD
On Sat, Oct 3, 2015 at 11:46 PM, FX wrote:
>> MSYS2 distributes the gcc fortran package based on mingw-w64 (see the
>> output of pacman -Ss fortran). You can inspect how it is built by
>> consulting its PKGBUILD recipe. It is here, along with the necessary
>> patches: https://github.com/Alexpux/MI
On Tue, Aug 25, 2015 at 1:53 PM, Gisle Vanem wrote:
> Alexandre Pereira Nunes wrote:
>
>> See tdm-gcc, it works like that.
>
> I know (that's why I love TDM-gcc). But according to my:
> f:\MingW32\MingW-w64\bin\gcc.exe -v --help
>
> MingW-w64 could do that too:
> -m32 Generate 32bit i386 c
On Sat, Aug 8, 2015 at 8:37 PM, Duane Ellis wrote:
>
> It's built from this project (and branch, be careful to not use
> master!) on github:
> https://github.com/Alexpux/mingw-builds/tree/develop but as I say, you
> want canadian cross, and well, I'll not repeat what I wrote before,
> I'd just enc
On Sat, Aug 8, 2015 at 7:35 PM, Ray Donnelly wrote:
> On Sat, Aug 8, 2015 at 7:18 PM, Duane Ellis 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 pr
On Sat, Aug 8, 2015 at 7:18 PM, Duane Ellis wrote:
> Thanks for the quick reply.
>
> MinGW-w64 doesn't have an instance of Python or an instance of a
> Python Enabled GDB since MinGW-w64 is a source-only project, more-or
> less. I assume the builds you are talking about are the semi-official
> min
On Sat, Aug 8, 2015 at 6:22 PM, Duane Ellis wrote:
> HI,
>
> My ultimate goal is to build a number of “python enabled” instances of GDB
> that run on Windows.
> (ie: ARM, MIPS, and a few other core types)
>
> I have a candian-cross setup on my linux box, it works great for everything
> but the “
On Tue, May 19, 2015 at 9:27 AM, Alexpux wrote:
>
> 19 мая 2015 г., в 10:48, Ruben Van Boxem
> написал(а):
>
> 2015-05-19 9:22 GMT+02:00 Alexpux :
>>
>>
>> 19 мая 2015 г., в 10:09, Ruben Van Boxem
>> написал(а):
>>
>> Additionally, there seem to be some misconceptions as to the number of
>> diff
On Tue, Mar 24, 2015 at 9:46 AM, Ray Donnelly wrote:
> On Tue, Mar 24, 2015 at 8:36 AM, Adrien Nader wrote:
>> On Tue, Mar 24, 2015, Ray Donnelly wrote:
>>> On 24 Mar 2015 07:06, "Adrien Nader" wrote:
>>> >
>>> > Hi,
>>> &g
On Tue, Mar 24, 2015 at 8:36 AM, Adrien Nader wrote:
> On Tue, Mar 24, 2015, Ray Donnelly wrote:
>> On 24 Mar 2015 07:06, "Adrien Nader" wrote:
>> >
>> > Hi,
>> >
>> > On Sat, Mar 21, 2015, Norbert Pfeiler wrote:
>> > &g
On 24 Mar 2015 07:06, "Adrien Nader" 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 t
On Fri, Jan 16, 2015 at 2:23 PM, Ray Donnelly wrote:
> On Fri, Jan 16, 2015 at 12:35 PM, Jacek Caban wrote:
>> Hi Ray,
>>
>> I'm sorry for the delay.
>>
>> On 01/12/15 21:41, Ray Donnelly wrote:
>>> We simply typedef it to int. */
&g
On Fri, Jan 16, 2015 at 12:35 PM, Jacek Caban 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
>
> MIC_TCP_STATE should
On Mon, Jan 12, 2015 at 6:44 PM, Ray Donnelly wrote:
> On Thu, Jan 8, 2015 at 6:01 PM, Kai Tietz wrote:
>> Committed to master after review on IRC by Jacek.
>>
>> I removed _Field_size_part_ macro use, as noted by review of Jacek.
>>
>> Kai
>>
>>
On Mon, Jan 12, 2015 at 6:45 PM, Jacek Caban wrote:
> ---
> mingw-w64-headers/include/iprtrmib.h | 1 +
> 1 file changed, 1 insertion(+)
>
Seems that #include needs to be moved after:
typedef int MIB_TCP_STATE;
.. since MIB_TCP_STATE is used in tcpmib.h .. or some other
re-organisation that cau
On Thu, Jan 8, 2015 at 6:01 PM, Kai Tietz 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 :
>> Hi,
>>
>> Any comment on the attached changes? Ok for apply?
>>
We ran
mp\go9683.tmp\symtab.o C:\Us
>
You'll need to rebuild mingw-w64-headers from the PKGBUILD for now.
p.s. The MSYS2/MinGW-w64 go packages are AFAIK, under maintained, do
you think you could take a look at our PKGBUILD sometime to see if
it's correct / working well? I'm not asking y
On Wed, Jan 7, 2015 at 11:45 AM, Dongsheng Song
wrote:
> On Wed, Jan 7, 2015 at 7:33 PM, Jacek Caban wrote:
>> Hi Alexey,
>>
>> On 01/07/15 09:06, Alexey Pavlov wrote:
>>> Ladt changes to time functions lead to multiple definitions of
>>> "asctime_r" in some programs. For example,
>>
>> I just pu
On Tue, Nov 11, 2014 at 2:02 PM, Dongsheng Song
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
> wrote:
>> Comments Suggestions and changes Welcome.
>>
>> Kind Re
On Fri, Nov 7, 2014 at 11:10 AM, Ozkan Sezer wrote:
> On 11/7/14, Ruben Van Boxem wrote:
>> 2014-11-07 9:25 GMT+01:00 Ozkan Sezer :
>>
>>> On 11/7/14, Dongsheng Song wrote:
>>> > If we define _POSIX_, then getpid (process.h) was hidden.
>>> > Is it correct ?
>>> >
>>> > PS: MSVC 2012 is the last
On Mon, Nov 3, 2014 at 3:45 PM, Baruch Burstein wrote:
> On Mon, Nov 3, 2014 at 2:37 PM, Ruben Van Boxem
> wrote:
>>
>> 2014-11-03 10:30 GMT+01:00 Baruch Burstein :
>>>
>>> I am curious why only a few of the executables get prefixed versions? I
>>> just tried running a certain makefile with prefi
I'm tired, corrections inline:
On Sun, Nov 2, 2014 at 1:54 AM, Ray Donnelly wrote:
> On Sun, Nov 2, 2014 at 1:19 AM, Greg Jung wrote:
>> Hi guys,
>>
>> I am using mingw-w64 gcc v4.8.2 installed under the /mingw32 directory under
>> mingw and I compile using ms
On Sun, Nov 2, 2014 at 1:19 AM, Greg Jung wrote:
> Hi guys,
>
> I am using mingw-w64 gcc v4.8.2 installed under the /mingw32 directory under
> mingw and I compile using msys/1.0 shell, or CMAKE from msys using "MSYS
> Makefiles".
> I adopted this after installing from a recipe and found it worked
On Mon, Oct 27, 2014 at 7:38 PM, Mark Cianfaglione
wrote:
> On Mon, 2014-10-27 at 19:18 +0300, LRN wrote:
>
>> >> Is there some way to distribute the icons with the application and how
>> >> is it done?
>> >>
>> >> Mark
>> >
>> > The thing you are searching is a resource file (.rc). By it you are
On Sat, Oct 25, 2014 at 1:47 PM, Mark Cianfaglione
wrote:
> Hi
>
> I'm using MSYS2 and Mingw-w64 on a Windows 7 64 bit system and I've got
> a situation where I've compiles a program that uses GTK3 but I get a
> "cannot execute binary file: Exec format error" when I try to execute
> it.
>
> I thou
On Tue, Oct 21, 2014 at 10:57 AM, JonY 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
>> follow
Comments welcome.
0001-localtime_r-guard-to-_POSIX-or-_POSIX_THREAD_SAFE_FU.patch
Description: Binary data
--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS,
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 ema
On Tue, Oct 14, 2014 at 2:26 PM, Jose Alf. wrote:
>
> I would like to help to build a new installer. I suggest we use InnoSetup or
> NSIS. I like InnoSetup because it's easier to mantain, but NSIS generates
> smaller installer files. I can try to understand what the current installer
> does, but i
On Thu, Oct 2, 2014 at 10:59 PM, Yaron Keren wrote:
> Well, something went wrong with MSYS2. I uninstalled MSYS2 and reinstalled,
> now libmangle compiles and build goes on. Odd. I did encounter a problem
> before with MSYS2 while doing pacman -Syu, there were errors and the upgrade
> wasn't compl
On Fri, Aug 22, 2014 at 4:14 PM, Stefan Ruppert wrote:
> Hi all,
>
> I have the following problem. I managed to compile our software which
> uses Qt 4.8.6 with g++ mingw32-w64 (rubenvb-4.7.2-release) in 32bit mode
> on a 64bit Windows 7 machine. All parts of our software runs correctly
> in wow64
On Thu, Aug 7, 2014 at 8:42 PM, Richard Shaw wrote:
> I'm working on documenting how to build a project natively in windows, which
> first means figuring out the quirks myself and I ran into an issue with g++
> not being able to find headers with unix style paths "/usr/local/include".
>
> My envir
Hi Ruben,
Please take this in the friendly/jokey manner it is intended.
This isn't the first time you corrected me on the return value from
main when I'm making a test-case to demonstrate a compiler issue; I
honestly couldn't care less and my goal is to use the minimum amount
of characters and so
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
static inline pid_t fork(void);
void main() {}
$ PATH=/mingw64/bin:"$PATH" gcc test.c
test.c:2:21: warning: conflicting
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.
-
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
s
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
.. 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.pat
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 l
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 t
[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
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
>> нап
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
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 whe
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
=
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-co
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 mention
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 fol
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
--- 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 ** __restr
> 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 p
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 fou
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
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
> > late
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.
>>
&g
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 st
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
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 ne
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 sit
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 revie
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, N
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 con
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, Ale
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:
>>> He
nd 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?
>>>>
>>>>
>>>&g
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 se
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-
-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
> S
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
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!
>
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 fr
> - 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
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 b
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 wro
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 Vins
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 u
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
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
&
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,
exp
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
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 Creato
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
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
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
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
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.
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
gt;
> 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/py
ed.
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, 201
; 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
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.
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:
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:
1 - 100 of 142 matches
Mail list logo
