Re: [Mingw-w64-public] Not understanding SJLJ dependency tradeoffs

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

Re: [Mingw-w64-public] Not understanding SJLJ dependency tradeoffs

2013/7/15 niXman > 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 >

Re: [Mingw-w64-public] [mingw-w64:discussion] No symbols in libscrnsave.a; source file scrnsave.c commented out

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 > Hello, > > I'm using Debian wheezy and I've been trying to cross-compile a scree

Re: [Mingw-w64-public] Some DLL-related issues remain

2013/7/8 Ruben Van Boxem > 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 I suppo

Re: [Mingw-w64-public] Not understanding SJLJ dependency tradeoffs

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, althou

Re: [Mingw-w64-public] Can't output (ostream <<) std::chrono::duration

2013/7/5 K. Frank > 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 u

Re: [Mingw-w64-public] Slow pointer union

2013/6/2 Etienne Sandré-Chardonnal > 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 > some data), never b

Re: [Mingw-w64-public] rubenvb 4.8 stdthread experimental compiler: printf %I64d?

2013/5/2 Jim Michaels > in rubenvb 4.8 stdthread experimental compiler, with > #include > 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 from the auto buil

Re: [Mingw-w64-public] MSYS2

On 2013-7-10 1:21, Alexey Pavlov wrote: > Upload new MSYS2 snapshots: > > 32-bit: x32-msys2-alpha-20130709.tar.xz > > > 64-bit: x64-msys2-alpha-20130709.tar.xz >

[Mingw-w64-public] Interlocked* patches follow-up

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 forwardin

Re: [Mingw-w64-public] MSYS2

2013/7/15 asmwarrior : > > > On 2013-7-10 1:21, Alexey Pavlov wrote: >> Upload new MSYS2 snapshots: >> >> 32-bit: x32-msys2-alpha-20130709.tar.xz >> >> >> 64-bit: x64-msys2-alpha-20130709

Re: [Mingw-w64-public] MSYS2

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

Re: [Mingw-w64-public] MSYS2

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 i

Re: [Mingw-w64-public] Not understanding SJLJ dependency tradeoffs

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. > > Just now I checked with [

Re: [Mingw-w64-public] Can't output (ostream <<) std::chrono::duration

Hi Ruben! On Mon, Jul 15, 2013 at 3:41 AM, Ruben Van Boxem wrote: > 2013/7/5 K. Frank > >> 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::en

Re: [Mingw-w64-public] MSYS2

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

Re: [Mingw-w64-public] Not understanding SJLJ dependency tradeoffs

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 I use the rubenvb >> > toolchains. >> >

Re: [Mingw-w64-public] Not understanding SJLJ dependency tradeoffs

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

Re: [Mingw-w64-public] Interlocked* patches follow-up

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

Re: [Mingw-w64-public] Not understanding SJLJ dependency tradeoffs

2013/7/15 Earnie Boyd > 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

Re: [Mingw-w64-public] Not understanding SJLJ dependency tradeoffs

2013/7/16 Ruben Van Boxem: > Why not just add -static to the link flags for the GCC executables? You can > do this through LDFLAGS (I think) or abuse --with-host-libstdc++ for it. > This makes any GCC compiler executable independent of dll's of the toolchain > used to build it. Already used: http

[Mingw-w64-public] Mass rebuild report for July 15 2013

This is a report for the 20130715 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. This mass rebuild was done using winpthreads instead of the old pthreads-w32 implementation. In Fedora itself

[Mingw-w64-public] [Patch] _bittest, _bittestandset, etc

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 input

Re: [Mingw-w64-public] Mass rebuild report for July 15 2013

ges. > 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-boo

Re: [Mingw-w64-public] Interlocked* patches follow-up

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

Re: [Mingw-w64-public] MSYS2

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 r

Re: [Mingw-w64-public] Interlocked* patches follow-up

yeah, Jacek's patch is ok. Kai Am 15.07.2013 16:06 schrieb "dw" : > > > > >> 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 buil

Re: [Mingw-w64-public] Interlocked* patches follow-up

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 work