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.
Just now I checked with [1] and [2] and found no dependency on
`libgcc_s_sjlj-1.dll`
What am I
2013/7/15 niXman i.nix...@gmail.com
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.
Just now I checked with [1] and [2] and found no
Hi,
could someone look at this please:
http://sourceforge.net/p/mingw-w64/discussion/723798/thread/54ec11c2/?limit=25#3046
Seems like an obvious-to-fix thing if what the OP says is right.
Ruben
2013/6/16 Faroe fa...@users.sf.net
Hello,
I'm using Debian wheezy and I've been trying to
2013/7/8 Ruben Van Boxem vanboxem.ru...@gmail.com
Op 8-jul.-2013 00:40 schreef Charles Programmr
charles.hernan...@gmail.com het volgende:
Thanks for the reply, Derek,
After downloading these, I'm not seeing clang in these builds, or is
there something I'm perceptually missing?
Am
2013/7/15 Ruben Van Boxem:
Let's get some things cleared out:
1) you can link libgcc statically by adding -static-libgcc to the link
command. There is also a -static-libstdc++ to go with it IIANM.
2) libgcc is not C++ only. You do need the dll version for exceptions to
work right, although
2013/7/5 K. Frank kfrank2...@gmail.com
Hello List!
The following code snippet fails to compile:
auto us = std::chrono::microseconds(7);
std::cout us std::endl; // error
(But std::cout us.count() std::endl; works as expected.)
So it looks like std::chrono::duration isn't set
2013/6/2 Etienne Sandré-Chardonnal etienne.san...@m4x.org
Dear all,
I'm using Mingw gcc 4.8.0 rubenvb seh build for x64 (native compiler)
In my program, I am using large binary trees, each node being a Node class
which is either a true node (two children pointers) or a leaf (pointer on
2013/5/2 Jim Michaels jmich...@yahoo.com
in rubenvb 4.8 stdthread experimental compiler, with
#include stdint.h
int64_t x=1;
printf(%02I64d, x);
I am getting a warning.
sleep.cpp:122:91: warning: unknown conversion type character 'I' in format
[-Wformat=]
this seems to break tradition
On 2013-7-10 1:21, Alexey Pavlov wrote:
Upload new MSYS2 snapshots:
32-bit: x32-msys2-alpha-20130709.tar.xz
http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130709.tar.xz/download
64-bit: x64-msys2-alpha-20130709.tar.xz
Hi,
Please review following patches:
http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/45606ff91bcf7bf34e81acc13ce239bc524290cd
Let's get rid of empty files.
http://repo.or.cz/w/mingw-w64/jacek.git/commitdiff/7de73e013cbeec88464d19b07bccfc46285c35a5
Inline functions are better way for
2013/7/15 asmwarrior asmwarr...@gmail.com:
On 2013-7-10 1:21, Alexey Pavlov wrote:
Upload new MSYS2 snapshots:
32-bit: x32-msys2-alpha-20130709.tar.xz
http://sourceforge.net/projects/msys2/files/Alpha-versions/32-bit/x32-msys2-alpha-20130709.tar.xz/download
64-bit:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15.07.2013 12:02, asmwarrior wrote:
My suggestion is: Is it possible to include the vim in your packages,
when I use the git tool, I need the vim (especially in git rebase -i
interactive mode), the MSYSGit package do have vim. see:
On 2013-7-15 18:15, Alexey Pavlov wrote:
Need to see how many dependencies it has. If not big then maybe I do it.
E:\code\msys\PortableGit-1.8.3-preview20130601\share\vim\vim73\vim.exe
It's dependency can be seen in attachment png image.
Another question is: Is it possible to fix the bug in
On Mon, 15 Jul 2013 11:02:20 +0400
niXman i.nix...@gmail.com 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.
Just now I
Hi Ruben!
On Mon, Jul 15, 2013 at 3:41 AM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
2013/7/5 K. Frank kfrank2...@gmail.com
Hello List!
The following code snippet fails to compile:
auto us = std::chrono::microseconds(7);
std::cout us std::endl; // error
(But std::cout
On 2013-7-15 18:44, LRN wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 15.07.2013 12:02, asmwarrior wrote:
My suggestion is: Is it possible to include the vim in your packages,
when I use the git tool, I need the vim (especially in git rebase -i
interactive mode), the
2013/7/15 Jon jon.for...@gmail.com:
On Mon, 15 Jul 2013 11:02:20 +0400
niXman i.nix...@gmail.com 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
On Mon, Jul 15, 2013 at 2:09 PM, Alexey Pavlov wrote:
2013/7/15 Jon :
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
Let's get rid of empty files.
Ok by me.
Since my automake isn't up to creating .in files, I was going to wait
until I was sure I wasn't going to have any more before asking someone
to help. I'm aware of at least one more file that needs to have this
done (intrincs\membarrier.c is not an
2013/7/15 Earnie Boyd ear...@users.sourceforge.net
On Mon, Jul 15, 2013 at 2:09 PM, Alexey Pavlov wrote:
2013/7/15 Jon :
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
1) Move these functions to intrin-impl.h:
_bittest, _bittest64
_bittestandset, _bittestandreset, _bittestandcomplement
_bittestandset64, _bittestandreset64, _bittestandcomplement64
2) Update inline asm code:
*a) Remove memory clobber*.
*b) Remove volatile keyword.*
c) Several changes to
.
The following packages FAILED to rebuild:
mingw-boost-1.53.0-1
Build logs:
http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20130715/mingw-boost-1.53.0-1
In function `ZN5boost6detail17basic_timed_mutex7destroyEv':
/builddir/build/BUILD/mingw-boost-1.53.0/win32/./boost/thread
Inline functions are better way for forwarding calls, esp. in this case.
Ok by me, but shouldn't you do all 6?
Turns out your prediction of trouble came true faster than expected.
Looking at the mass build report, there are a number of errors that all
map to these stdcall functions. As
On 2013-7-15 22:28, Alexpux wrote:
zyh23@zyh /d/test_msys2/git_local
$ git svn clone file:///d/test_msys2/svn_repo/
/d/test_msys/git_local/svn_re
po
2 [main] perl 11956 child_info_fork::abort: unable to remap msys-svn_diff-
1-0.dll to same address as parent (0xDE) - try running
yeah, Jacek's patch is ok.
Kai
Am 15.07.2013 16:06 schrieb dw limegreenso...@yahoo.com:
Inline functions are better way for forwarding calls, esp. in this case.
Ok by me, but shouldn't you do all 6?
Turns out your prediction of trouble came true faster than expected.
Looking at the
Arrg! That's not going to work either.
You can't inline something (which is what we are doing) AND have it be
DLLIMPORT (which is what boost is doing):
/error: inlining failed in call to always_inline 'LONG
InterlockedExchange(volatile LONG*, LONG)': function not inlinable/
This would
26 matches
Mail list logo
