On 21/03/2017 07:43, Ruben Van Boxem wrote:
> Op 21 mrt. 2017 8:07 a.m. schreef "Liu Hao"
> :
>
> On 2017/3/20 20:49, Jon Turney wrote:
>> Windows 10 now has a separate exception for OutputDebugStringW, rather
> than
>> converting the string to ANSI and rai
Windows 10 now has a separate exception for OutputDebugStringW, rather than
converting the string to ANSI and raising DBG_PRINTEXCEPTION_C.
(See
https://ntquery.wordpress.com/2015/09/07/windows-10-new-anti-debug-outputdebugstringw/)
Signed-off-by: Jon Turney
---
mingw-w64-headers/include
Use PDH_FUNCTION rather than just PDH_STATUS, so these functions are
correctly decorated with WINAPI (= stdcall on x86), so linkage works
correctly on x86.
---
mingw-w64-headers/include/pdh.h | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/mingw-w64-headers/include/p
If you've not already investigated it for options for the binary
downloads, this is worth considering and currently free for OSS
https://bintray.com/
It could be compelling when combined with some of the other mentions.
Jon
On Thu, Jun 11, 2015 at 12:04 PM, Ivan Garramona
wrote:
> Hi
m I'll try to find time to look at the
PKGBUILD's
On 1/7/15, Ray Donnelly wrote:
> On Wed, Jan 7, 2015 at 2:45 PM, Jon wrote:
>> Looks to be the issue behind my recent go build fail...
>>
>> $ pacman -Q | grep mingw
>> mingw-w64-x86_64-binutils-git 2.25.r81
4.0.0.4370.d008dc5-1
mingw-w64-x86_64-zlib 1.2.8-5
C:\Apps\go-git [go_1.4 +8 ~0 -0 !]> .\buildall.ps1
---> building for windows/amd64 platform
# Building C bootstrap tool.
cmd/dist
# Building compilers and Go bootstrap tool.
lib9
libbio
liblink
cmd/cc
cmd/gc
cmd/6l
C:\Users\Jon\AppData
On Mon, Jun 9, 2014 at 10:33 AM, Jon wrote:
>
> On Mon, Jun 9, 2014 at 10:20 AM, Jon wrote:
>
>>
>> On Sat, Jun 7, 2014 at 2:06 PM, Jon wrote:
>>
>>> The 4.8.x series changed its default behavior re: libgcc linking when on
>>> Windows
>>&g
On Mon, Jun 9, 2014 at 10:20 AM, Jon wrote:
>
> On Sat, Jun 7, 2014 at 2:06 PM, Jon wrote:
>
>> The 4.8.x series changed its default behavior re: libgcc linking when on
>> Windows
>>
>> http://gcc.gnu.org/gcc-4.8/changes.html#windows
>>
>> I&#
On Sat, Jun 7, 2014 at 2:06 PM, Jon wrote:
> The 4.8.x series changed its default behavior re: libgcc linking when on
> Windows
>
> http://gcc.gnu.org/gcc-4.8/changes.html#windows
>
> I'm testing with my environment to confirm 4.9.x default libgcc linking
> behavior (f
ng, niXman and Alexey please confirm your toolchain's
default behavior re: libgcc linking.
Thank you.
Jon
--
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive ne
On 06/05/2014 14:33, LRN wrote:
> On 06.05.2014 17:26, Kai Tietz wrote:
>> 2014-05-06 15:01 GMT+02:00 LRN:
>> Patch is of course ok. I just wanted a note on mailing-list that you've
>> update to current (which version?).
> OpenGL 4.4, i think.
>
> In my RSS feed there's an entry about OpenGL 4.4
On Wed, May 14, 2014 at 4:07 PM, Jon wrote:
> Similar to how msys includes a `patch.exe.manifest` file in it's 2.6.1
> patch archive from
>
> http://sourceforge.net/projects/mingw/files/MSYS/Extension/
>
> please consider adding a manifest file to an updated release o
Similar to how msys includes a `patch.exe.manifest` file in it's 2.6.1
patch archive from
http://sourceforge.net/projects/mingw/files/MSYS/Extension/
please consider adding a manifest file to an updated release of msys2's
2.7.1 patch (i686 and x86_64) archives.
A manifest file is one of the wo
On Mon, Apr 28, 2014 at 2:32 PM, Adrien Nader wrote:
> On Mon, Apr 28, 2014, Jon wrote:
> > On Mon, Apr 28, 2014 at 10:03 AM, LRN wrote:
> >
> > > -BEGIN PGP SIGNED MESSAGE-
> > > Hash: SHA1
> > >
> > > On 28.04.2014 17:04, JonY wrote
On Mon, Apr 28, 2014 at 10:03 AM, LRN wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 28.04.2014 17:04, JonY wrote:
> > On 4/28/2014 19:53, Ruben Van Boxem wrote:
> >> Different repositories may sound like a nice idea, but keeping them in
> >> sync can be a pain, depending on the
:
>>
>> Using the windows cmd box terminal console, then on Win-Buids which is
>> using MinGW64.
>> How do you compile a source package which comes with a "configure" shell
>> script made for the *nix world?
>>
C:\Users\Jon\Documents\CDev\winpthreads-s
>
> Also: Where should I get the sources for winpthreads?
>
>
http://sourceforge.net/p/mingw-w64/code/HEAD/tree/trunk/mingw-w64-libraries/winpthreads/
--
Rapidly troubleshoot problems before they affect your business. Most
On Sat, Nov 23, 2013 at 12:55 PM, Alexpux wrote:
>
> 23 нояб. 2013 г., в 13:56, Jon написал(а):
>
> > To confirm, the only effect of setting MSYSTEM (e.g. - setting to MSYS,
> MINGW32, or MINGW64) in an MSYS2 + mingw-w64 environment is (a) uname
> changes its out
To confirm, the only effect of setting MSYSTEM (e.g. - setting to MSYS,
MINGW32, or MINGW64) in an MSYS2 + mingw-w64 environment is (a) uname
changes its output, and therefore (b) config.guess spews one of the
following three?
${UNAME_MACHINE}-pc-mingw64
${UNAME_MACHINE}-pc-mingw32
${UNAME_M
On Mon, Nov 18, 2013 at 4:06 PM, Alexey Pavlov wrote:
>
>
>
> 2013/11/19 Jon
>
>>
>>
>> On Mon, Nov 18, 2013 at 3:46 PM, Alexey Pavlov wrote:
>>
>>>
>>>
>>>
>>> 2013/11/19 Jon
>>>
>>>&
On Mon, Nov 18, 2013 at 3:46 PM, Alexey Pavlov wrote:
>
>
>
> 2013/11/19 Jon
>
>>
>> On Mon, Nov 18, 2013 at 3:05 PM, Ruben Van Boxem <
>> vanboxem.ru...@gmail.com> wrote:
>>
>>> 2013/11/18 Alexey Pavlov
>>>
>>>>
>
On Mon, Nov 18, 2013 at 3:05 PM, Ruben Van Boxem
wrote:
> 2013/11/18 Alexey Pavlov
>
>>
>>
>>
>> 2013/11/18 Jon
>>
>>> Reasons why the following in a 32bit MSYS2's /etc/pacman.conf is an
>>> awful idea?
>>>
>>> [
Reasons why the following in a 32bit MSYS2's /etc/pacman.conf is an awful
idea?
[mingw]
#Server = https://sourceforge.net/projects/msys2/files/REPOS/MINGW/$arch
Server = https://sourceforge.net/projects/msys2/files/REPOS/MINGW/x86_64
I don't believe there are any MSYS2 32bit exes or DLLs at
> You need rebase dlls. Close MSYS2 and execute autorebase.bat from msys
> root directory
>
Will the dlls always need to be rebased after an upgrade? If not, which
specific upgrade scenarios will need a rebase?
Perhaps a comment added to autorebase.bat summarizing the scenarios that
require rebas
On Sun, Nov 17, 2013 at 1:06 PM, Jon wrote:
> $ pacman -Syu
> :: Synchronizing package databases...
> msys 75.5 KiB 337K/s 00:00
> [] 100%
> :: Starting full system upgrade...
> resolving dependencies...
> looking for
$ pacman -Syu
:: Synchronizing package databases...
msys 75.5 KiB 337K/s 00:00
[] 100%
:: Starting full system upgrade...
resolving dependencies...
looking for conflicting packages...
Packages (4) bash-4.2.045-3 mpfr-3.1.2.p4-1 msys2-base-1
On Fri, Nov 15, 2013 at 3:56 AM, Kai Tietz wrote:
> 2013/11/15 Jon :
> > After skimming LRN's ntldd https://github.com/LRN/ntldd tool, reading
> tinype
> > again http://www.phreedom.org/research/tinype/ and updating my upx
> > http://upx.sourceforge.net/ I'm
l (binutils?)
that already does this? RTFM links to get smarter?
Thanks, Jon
--
DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Acc
On Wed, Nov 13, 2013 at 3:53 PM, Alexpux wrote:
>
> 14 нояб. 2013 г., в 0:48, Jon написал(а):
>
>
> On Wed, Nov 13, 2013 at 3:36 PM, Alexpux wrote:
>
>>
>> 14 нояб. 2013 г., в 0:31, Jon написал(а):
>>
>> I'm an old cygwin user who went astray
> 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 exp
On Wed, Nov 13, 2013 at 3:36 PM, Alexpux wrote:
>
> 14 нояб. 2013 г., в 0:31, Jon написал(а):
>
> I'm an old cygwin user who went astray years ago and would like to confirm
> my MSYS2 setup.
>
> Here's what I'm doing to have a sandboxed style setup that iso
I'm an old cygwin user who went astray years ago and would like to confirm
my MSYS2 setup.
Here's what I'm doing to have a sandboxed style setup that isolates my
normal windows setup. For example, I don't want MSYS2's default
/etc/profile to think HOME is C:\Users\Jon. I
t the benefit of a tutorial based upon your adventurous ramp up.
Tutorial style documentation is lacking and many of us take for granted the
challenges of setting up a workable toolchain for the first time.
Jon
--
Dream
adeoffs between convenience and
size. I trust your instincts and choices.
Since we now have pacman (thank you!) there's very little downside. :)
On Tue, Nov 12, 2013 at 2:56 PM, Alexey Pavlov wrote:
>
>
>
> 2013/11/12 Jon
>
>> Why were the following packages not sel
Why were the following packages not selected for inclusion in this version
of the BASE download?
msys autoconf 2.69-1
msys automake 1.14-1
msys libtool 2.4.2-1
--
DreamFactory - Open Source REST & JSON Services for H
..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@
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/a8f47daae77bb2390843250fbe6
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 an
>> What is patch not doing that you want? It should be able to
> >> handle git diff output if you pass the magic -p option or modify
> >> the resulting diff a bit.
> >>
> >>
> > I need a no-install exe that can apply both git and unified style
> > patches as-is without requiring manual tweaks to
On Fri, Nov 8, 2013 at 11:12 AM, Ruben Van Boxem
wrote:
> 2013/11/8 Jon
>
>> Largely irrelevant these days given how well git and mercurial run on
>> windows, but is anyone aware of a self-contained patch exe that runs on
>> windows and understands both unified diffs
Largely irrelevant these days given how well git and mercurial run on
windows, but is anyone aware of a self-contained patch exe that runs on
windows and understands both unified diffs and git diffs?
The goal is to have a simple, single file, no dependency patching tool for
use with automated buil
the link to the tcltk buildlet
https://github.com/jonforums/buildlets/blob/master/build_tcltk.ps1#L79-L80
On Thu, Nov 7, 2013 at 10:41 PM, Jon wrote:
> While updating my powershell-based build recipes ("buildlets") for 64-bit
> and other things, I get the following build
6.1-src.tar.gz
---> activating toolchain [64-bit]
---> configuring tcl8.6.1 [64-bit]
---> building tcl8.6.1 [64-bit]
C:\Users\Jon\Documents\CDev\buildlets-git\tcl8.6.1\win\tclWin32Dll.c:42:3:
error: conflicting
types for 'EXCEPTION_REGISTRATION'
} EXCEPTION_REGISTRATION;
^
In
Thanks Alexey. I can now build gvim.exe and xxd.exe with the mingw32-make
repack of `x86_64-4.8.2-release-win32-seh-rt_v3-rev0.7z`
On Wed, Oct 2, 2013 at 10:21 AM, Jon wrote:
> On Win8 64bit using the recent mingw-w64 binary toolchain
> `x86_64-4.8.1-release-win32-seh-rt_v3-rev2.7z` to
No. You gave an answer to a question Incongruous did not ask.
Unfortunately, your answer could confuse newcomers searching this ML.
Read Incongruous' post again. It said "I would like to test for MinGW64 to
include or exclude some code..."
I think LRN, Ruben, and the FAQ provided the correct answ
On Tue, Oct 15, 2013 at 7:23 AM, Ruben Van Boxem
wrote:
> 2013/10/15 LRN
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> On 15.10.2013 14:06, Incongruous wrote:
>> > I would like to test for MinGW64 to include or exclude some code;
>> something like:
>> > #ifdef MinGW64
>> > doThis();
On Fri, Oct 11, 2013 at 1:47 AM, LRN wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Sbuild (i686 MSYS2 + i686 mingw-w64) was updated.
>
Impressive.
Similar to my other post, I'm assuming you're OK with additional download
traffic to `mingw_base_url_template` if I get interested in
On Fri, Oct 11, 2013 at 3:41 AM, Adrien Nader wrote:
> Hi,
>
> I am pleased to announce the first alpha for the 1.3 release of
> win-builds.org.
>
>
Interesting and this is certainly humorous
http://cgit.notk.org/adrien/yypkg/win-builds.git/tree/hall_of_shame.html
If I become interested in using
On Sat, Oct 5, 2013 at 3:15 PM, Baruch Burstein wrote:
>
> On Sat, Oct 5, 2013 at 4:52 AM, Jon wrote:
>
>>
>> Heh heh, Incongruous it's your luck day.
>>
>> JonY, gave you all the answers and you didn't even have to dig. Oh well,
>> the Socratic m
> >
> > Good luck with spelunking the awesomeness that makes up your MinGW-w64
> > toolchain.
> >
>
> Do go on.
>
>
Your turn. I'm waiting to learn some cool new build tool tricks from you or
others :)
--
October Webinars:
Heh heh, Incongruous it's your luck day.
JonY, gave you all the answers and you didn't even have to dig. Oh well,
the Socratic method is overrated and irritating after about two questions ;)
--
October Webinars: Code for P
d::cout << "Hello C++ World!" << std::endl;
}
int main() {
say_hello();
return 0;
}
start playing, and keep playing, until you learn more about the tools. GDB
is a great friend, but I won't show it below. These examples are from my
Win8 64bit on a W530 using an offi
On Thu, Oct 3, 2013 at 5:27 AM, JonY wrote:
> On 10/3/2013 06:27, Jon wrote:
> > FAQ entry added under Execution section
> >
> > https://sourceforge.net/apps/trac/mingw-w64/wiki/FAQ
> >
> > Answer added as
> >
> >
> https://sourceforge.net/apps/tr
hread and I'll make appropriate changes.
Jon
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Ge
ngwbuilds 4.7.3
toolchain `x32-4.7.3-release-win32-sjlj-rev1.7z`, or
b) Use the original 64bit setup but prepend MSYS2
(x64-msys2-beta2-20130909.tar.xz) to %PATH% and use `make` instead of
`mingw32-make`
I'm still investigating, but is anyone else able to reproduce or also
having problems with ming
On Tue, Oct 1, 2013 at 6:15 PM, JonY wrote:
> On 10/1/2013 22:49, Jon wrote:
> > What you likely lack is free time and the desire to maintain
> documentation.
> > Understandable.
> >
>
> Since you seem free, you can prepare the text, I'll look through it and
On Tue, Oct 1, 2013 at 5:24 AM, JonY wrote:
> On 10/1/2013 07:34, Jon wrote:
> > Bottom line: MinGW-w64 project documentation needs help starting with the
> > FAQ. Add a specific entry addressing Incongruous' question and make this
> > one go away.
> >
>
>
link.
And who knows, maybe JonY will find the ML questions to be just a bit more
funny. Pfft, who am I kidding...I just want to see JonY tersely tell
someone to RTFM ;)
Jon
--
October Webinars: Code for Performance
Free Intel w
> > Well, let us see how many traffic will come up for this. For now I
> > would like to see discussions like this on our public mailing list.
> >
> > If we find out that traffic is too high, then we can still create
> > another mail-list for it.
>
> Okay.
>
>
I wasn't suggesting another mailing l
thread that lists specific areas (small and large)
where you guys could use community help in building and maintaining the
official mingw-w64 builds.
Will official mingw-w64 builds be available only for 4.8.1+, or will a
limited
guaranteed that can be used to build GCC. This
> is I think the main reason a lot of people are complaining. This should be
> very much avoided in the future IMHO.
>
> Just my 2c,
>
> Ruben
>
> i'd like to hear nixman and alexey's perspective as it relates t
set of eyes to review for English and
clarity, I'd
be more than happy to assist. Just email me a version off-list.
If not, that's fine and I'm looking forward to the new `mingw-w64-builds`
directory
contents of "official" builds :)
Jon
---
Fail fast. Fail of
orge.net/mingw-w64/?download".
> SF keeps an index of file names by project to know where on the file
> system it exists.
This style of download link still appears to work both manually
curl -L -O
http://downloads.sourceforge.net/mingw-w64/i686-w64-mingw32-gcc-4.8.0-win32_rube
On Mon, 15 Jul 2013 11:02:20 +0400
niXman wrote:
> 2013/7/15 Jon:
> > When I build C apps with mingwbuilds 4.8.1-win32-sjlj, the built artifacts
> > have a runtime dependency on
> > `libgcc_s_sjlj-1.dll`. This is not the case when I use the rubenvb
> > toolchains.
&
wnsides of toolchains behaving like the rubenvb toolchains
wrt SJLJ?
5) Any other important tradeoffs to be aware of? (no SEH vs Dwarf vs SJLJ
discussion please ;))
Jon
--
See everything from the browser to the dat
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
> >> > > tha
ot;Official Builds" folder
Two concerns. First, who's going to take on the release mgr role, and second,
does
this add any real value above and beyond what mingwbuilds is already providing?
To help with the release mgr role, I strongly believe the toolchain build
process needs
to be t
pilers
are provided. The current automated builds (apparently targeted to internal
testing usage) are not a solution. I'm hoping that a version of Ruben's work at
https://github.com/rubenvb/MinGW-w64-build-scripts
can be the foundation of a new official mingw-w64 toolchain release pr
switched under `C:\DevTools\mingw` by a tool that works similar
to MKLINK.
The bottom line is that while my workflow does not appear to be a good match
for Cygwin's primary use cases, I
greatly benefit from MSYS (and likely MSYS2) creative and targeted use of
On Sat, 30 Mar 2013 22:51:34 -0400
NightStrike wrote:
> On Sat, Mar 30, 2013 at 9:28 PM, JonY wrote:
> > On 3/31/2013 04:35, Jon wrote:
> >>
> >> With respect to
> >> http://www.gnu.org/licenses/gpl-faq.html#WhatCaseIsOutputGPL
> >> is it true that
On Sat, 30 Mar 2013 23:59:22 +0800
JonY wrote:
> On 3/30/2013 15:47, Ruben Van Boxem wrote:
> > Op 29 mrt. 2013 16:48 schreef "JonY" het
> > volgende:
> >>
> >> Hello,
> >>
> >> After careful thought, we have decided to make gendef, genidl and
> >> genpeimg use GPLv3 or later for all future relea
enerates this false conftest failure
> >> >
> >> > configure:12982: gcc -g -O2 -c conftest.S 1>&5
> >> > conftest.S:1:80: fatal error:
> >> > /c/Users/Jon/Downloads/temp/lzo/lzo-2.06/asm/i386/src_gas/lzo1x_f1.S: No
> >> > such file or di
r battle-tested solution than my
> > throw-sed-at-it impulse.
> >
> > This section of configure.ac
> >
> > http://paste.ubuntu.com/5657059/
> >
> > generates this false conftest failure
> >
> > configure:12982: gcc -g -O2 -c conftest.S 1>&
w-sed-at-it impulse.
This section of configure.ac
http://paste.ubuntu.com/5657059/
generates this false conftest failure
configure:12982: gcc -g -O2 -c conftest.S 1>&5
conftest.S:1:80: fatal error:
/c/Users/Jon/Downloads/temp/lzo/lzo-2.06/asm/i386/src_gas/lzo1x_f1.S: No such
file
tradeoffs. Qt 5.1+ currently recommends dwarf+posix threading combo.
4) For 64-bit C++ code, the current "best" recommendation is dwarf+seh when
using 4.8.0+ unless one has other constraints.
Any other important tradeoffs/considerations?
Jon
---
Fail fast. Fail often. Fail publicly. Learn
> 2013/3/2 Jon :
> >> > There is one problem: There is no liboldname90 in Mingw-w64, hence I kept
> >> > liboldname.
> >> Yes, for what purpose you need it?
> >
> > I'm updating my 32/64bit build systems to better automate how I use
&
the objects in libraries like
`libmoldname.a`?
Jon
---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums
--
Everyone hates slow websi
> PS: we do have a wiki page that no one seems to find... (I'm not blaming you,
> it's just an observation :P)
> http://sourceforge.net/apps/trac/mingw-w64/wiki/GeneralUsageInstructions
The page needs updating in the following areas. I'd push a draft but have
forgotten my credentials :(
* "Down
I gave it Arch, Ubuntu Server, and Snow Leopard VMs
each with cross-build support.
Good luck.
Jon
---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums
--
other tools are needed? I'd skimmed the repo, saw
`update_liblist.pl`, dismissed it and thought all could be built via
Makefile(s). Sounds like I got it wrong.
Jon
--
Keep yourself connected to Go Parallel:
DESIGN Ex
:
https://github.com/oneclick/rubyinstaller/blob/master/config/devkit.rb#L30-L68
https://github.com/oneclick/rubyinstaller/blob/master/config/compilers/mingw64.rb#L3-L37
Then, what else do you need to do to get all those pieces to play nicely
to
Windows
2.8% - Build on Windows for Windows (all MinGW flavors)
0.2% - Build on Windows for Windows (VC++)
Now turn it around. What do you expect to be the build breakdown for devs
trying to use ironCrate?
Jon
[1] I don
On Mon, 12 Nov 2012 07:14:42 +0800
JonY wrote:
> On 11/12/2012 03:36, Pau Garcia i Quiles wrote:
> > On Sun, Nov 11, 2012 at 7:05 PM, Jon wrote:
> >
> >> So here's the question.
> >>
> >> Can the method I use when cross-compiling, namely, use cmake
blob/master/mrblib/CMakeLists.txt#L3-45
So here's the question.
Can the method I use when cross-compiling, namely, use cmake's
`ExternalProject` module (causes cmake to run itself and generate artifacts in
a different dir) to pre-build an environment on the b
On Sun, 11 Nov 2012 09:39:26 +0800
JonY wrote:
> On 11/11/2012 02:22, Jon wrote:
> >
> > It's unfortunate you both had bad experiences with cmake. Cmake really is
> > quite powerful, and recent syntax mods make it friendlier to use.
> >
> > For example, I
OpenWRT...
https://github.com/mruby/mruby/blob/master/cmake/Toolchain-OpenWRT-ANY.cmake
You get the point.
And one more thing, cmake generates ninja build files (yes, the ninja
single-file-exe runs on Windows and is easily built on Windows using mingw) in
addition to the plethora of
On Fri, 2 Nov 2012 15:20:10 -0400
Earnie Boyd wrote:
> On Fri, Nov 2, 2012 at 3:01 PM, Jon wrote:
> >
> > I settled for the "fix" of using mingw.org gcc 4.6.2 32bit but don't
> > understand why it works since the 4.6.2 .pyd's still have deps on
>
try again with a custom spec to force everything to
msvcr90.dll and try with
http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.7.2/
Jon
--
LogMeIn Central: Instant, anywhere, Remote PC access and managem
do well: release quality versions when they're
ready, and enable downstream integrators to choose the version they feel is the
best for their needs. Hard, schedule-based major version release cycles aren't
a good fit for mingw-w64. Perhaps for other projects similar to Ubuntu, but not
On Mon, Sep 24, 2012 at 8:15 AM, Ruben Van Boxem
wrote:
> 2012/9/24 Ozkan Sezer
>>
>> On Mon, Sep 24, 2012 at 10:30 AM, Ruben Van Boxem
>> wrote:
>> > 2012/9/24 Jon
>> >>
>> >> > > fyi...the following libuv build fail still exists in
> 2012/9/24 Ozkan Sezer
>
> > On Mon, Sep 24, 2012 at 10:30 AM, Ruben Van Boxem
> > wrote:
> > > 2012/9/24 Jon
> > >>
> > >> > > fyi...the following libuv build fail still exists in
> > >> > > `i686-w64-mingw32-gcc-4.7
SS
rubenvb 4.7.2: FAIL
I've happily used your builds for awhile now as my reference MinGW-w64
toolchain. Perhaps in the future when you guys see similar issues that impact
well known libraries, a patch MinGW-w64 release can be quickly tagged as a way
of helping downstream integrat
fyi...the following libuv build fail still exists in
`i686-w64-mingw32-gcc-4.7.2-release-win32_rubenvb.7z`
> On 9/11/12, Jon wrote:
> > In an custom msys wrapped
> > `i686-w64-mingw32-gcc-4.7.1-2-release-win32_rubenvb.7z` toolchain I get the
> > following build fail wi
In an custom msys wrapped
`i686-w64-mingw32-gcc-4.7.1-2-release-win32_rubenvb.7z` toolchain I get the
following build fail with libuv that doesn't occur when I use a mingw.org based
4.6.2 toolchain.
C:\Users\Jon\Documents\CDev\libuv-git>make
gcc -Iinclude -Iinclude/uv-private -g --s
On Sun, Jun 17, 2012 at 12:58 PM, niXman wrote:
> 2012/6/17 K. Frank:
>> Okay, thanks for the info. I'll probably wait for a std::thread-enabled
>> 4.7.1 release before I consider upgrading. (As I mentioned, I'm not
>> facing any particular issue.)
>
> In my builds std_concurrency is enabled:
>
>> configure:1340: checking for gcc
>> configure:1356: found /c/Program Files/OpenAxiom/bin/gcc
You're begging for failures when you install to a PATH with spaces. For example:
C:\Users\Jon\Documents\CDev\sandbox>echo %PATH%
C:\"spacey path\mingw-rvb\bin";...
C:\Us
0
I've had very good experiences with the `rubenvb` builds (he's
currently got GCC 4.6.3 and 4.7.0 release builds) and the
`mingwbuilds` from http://sourceforge.net/projects/mingwbuilds/files/
I find both the usability and the size-on-disk to be superior to the
current automated `*-bin_i686-mingw
ig/compilers/mingw64.rb
In fact, I just updated and smoke tested the 4.7.1 mingwbuilds flavor
https://github.com/oneclick/rubyinstaller/commit/a7e8db081c627c872d95ffb7b3d6fec213419f55
Jon
---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http:
"Local: %A, %B %d, %Y %H:%M %z", my_local_tm))
puts(buffer);
return 0;
}
Jon
---
Fail fast. Fail often. Fail publicly. Learn. Adapt. Repeat.
http://thecodeshop.github.com | http://jonforums.github.com/
twitter: @jonforums
> On 3/22/2012 2:01 PM, Jon wrote:
> >> Would it be possible to generate a new automated build for mingw? If
> >> I remember correctly the mingw build-bots were down?
> >
> > Perhaps it's time to rethink the current automated build strategy with an
> &g
1 - 100 of 145 matches
Mail list logo
