Hi,
I'm new to mingw-w64. Thanks for creating such a useful cross platform
project!
I am having a problem I'm hopeful someone can help me with. The problem is
I can build and run my application on linux (i386-linux) and 64bit windows
(x86_64-win64), but it fails to link properly when I target 32b
Ah, looks like the reason for the strange behaviour was my using
release with debug info build type for cmake. Optimizations play funky
with the debugger it seems. Now all is in order...phew.
So, summarizing again for reference:
* Make sure python 2.7 is installed
* Make sure you don't enable any
Dear Ruben,
> Just for reference: no patching done on my side. The only things I would
> patch (for release build things) are build related things, which do not
> affect the workings of the program at all.
What could typically be "build-related things"? Do you mean
the makefiles for instance, ne
Hello Ruben!
On Mon, May 14, 2012 at 4:05 PM, Ruben Van Boxem
wrote:
> 2012/5/14 K. Frank
> ...
>>
>> Did you remember to compile with "-static"?
>>
>> (I'm only half joking. I just burnt up a couple of hours tracking down
>> an on-exit crash due to me using threads without "-static".)
>
> Unre
2012/5/14 K. Frank
> Hi Ruben!
>
> On Mon, May 14, 2012 at 2:27 PM, Ruben Van Boxem
> wrote:
> > 2012/5/14 Antony Riakiotakis
> >>
> >> Hi,
> >>
> >> First, good news:
> >> MinGW-w64 support for blender is getting more complete by the day, ...
> > ...
> > I decided to build blender from source,
Hi Ruben!
On Mon, May 14, 2012 at 2:27 PM, Ruben Van Boxem
wrote:
> 2012/5/14 Antony Riakiotakis
>>
>> Hi,
>>
>> First, good news:
>> MinGW-w64 support for blender is getting more complete by the day, ...
> ...
> I decided to build blender from source, which worked using the instructions
> on th
Hmmm...I really can't say.. unfortunately, openmp destabilizes the
build (crash when rendering subdivision modified objects) so it may be
causing the error with threading on your build. Also we bundle the
pthread library that came from a different MinGW64 build, which may
cause the issues with thre
2012/5/14 JonY
> On 5/14/2012 19:40, MARTIN Pierre wrote:
> > Dear Kai, JonY, Ozkan and list readers,
> >
> > As suggested by list users, i have filled a bug report right here:
> >
> https://sourceforge.net/tracker/?func=detail&aid=3526537&group_id=202880&atid=983354
> > If you think it's not cle
2012/5/14 Antony Riakiotakis
> Hi,
>
> First, good news:
> MinGW-w64 support for blender is getting more complete by the day, to
> the point where users download and test (and may even prefer, due to
> the speed increase ;) ) mingw-w64 builds. There have been a few
> compiler-related issues but m
Hi Guys!
On Mon, May 14, 2012 at 4:10 AM, Kai Tietz wrote:
> 2012/5/14 xunxun :
>> 于 2012/5/14 15:15, Ruben Van Boxem 写道:
>>> I'll add that in my next build. The question becomes then why is this
>>> not detected by configure automatically?
>> Maybe Kai knows.
>>
>> This happened in gcc4.6.x firs
Looks like I managed to make it work with QT too, sorry for the fuss.
Still when tracing with gdb the cursor seems to hop randomly in the
source...I don't know why that may be unfortunately :/
--
Live Security Virtual Conf
This is getting allot of coverage over at lwn.net btw. On the issue of
APIs, if the court were to rule in the manor discussed, it would simply
be too destructive to the industry to even contemplate. Every single
thing having to do with programming would be subject to frivolous
litigation and USA wo
> Go ahead and make a bug report, thanks. Dlltool for mingw and mingw-w64
> are really the same, I don't think Ruben does any patching for binutils.
Done, right there:
https://sourceforge.net/tracker/?func=detail&aid=3526550&group_id=202880&atid=983354
Thank you all for your help, right now i know
On 5/14/2012 19:40, MARTIN Pierre wrote:
> Dear Kai, JonY, Ozkan and list readers,
>
> As suggested by list users, i have filled a bug report right here:
> https://sourceforge.net/tracker/?func=detail&aid=3526537&group_id=202880&atid=983354
> If you think it's not clear enough, i would like your f
Dear Kai, JonY, Ozkan and list readers,
As suggested by list users, i have filled a bug report right here:
https://sourceforge.net/tracker/?func=detail&aid=3526537&group_id=202880&atid=983354
If you think it's not clear enough, i would like your feedback about
what i could possibly detail about, o
Hi,
First, good news:
MinGW-w64 support for blender is getting more complete by the day, to
the point where users download and test (and may even prefer, due to
the speed increase ;) ) mingw-w64 builds. There have been a few
compiler-related issues but more like gcc-related than MinGW-64
related I
On Mon, May 14, 2012 at 12:54 PM, Kai Tietz wrote:
> 2012/5/13 MARTIN Pierre :
>> Dear Kai, dear list readers,
>>
>> No, gendef seems to add double @ symbol happily. You can file a
>> bug about gendef to our bugtracker for this.
>>
>> i surely will.
>>
>> Simply remove double @ at line end. thing
2012/5/13 MARTIN Pierre :
> Dear Kai, dear list readers,
>
> No, gendef seems to add double @ symbol happily. You can file a
> bug about gendef to our bugtracker for this.
>
> i surely will.
>
> Simply remove double @ at line end. things like ...@12@12 to ...@12.
>
> Done.
>
>
> As long as they ar
2012/5/14 xunxun :
> 于 2012/5/14 15:15, Ruben Van Boxem 写道:
>> I'll add that in my next build. The question becomes then why is this
>> not detected by configure automatically?
> Maybe Kai knows.
>
> This happened in gcc4.6.x first, so I use --enable-libstdcxx-time=yes
> from then.
>
> --
> Best Re
于 2012/5/14 15:15, Ruben Van Boxem 写道:
> I'll add that in my next build. The question becomes then why is this
> not detected by configure automatically?
Maybe Kai knows.
This happened in gcc4.6.x first, so I use --enable-libstdcxx-time=yes
from then.
--
Best Regards,
xunxun
Op 14 mei 2012 09:03 schreef "xunxun" het volgende:
>
> 于 2012/5/14 7:40, K. Frank 写道:
> > Hello All!
> >
> > I am finding that std::this_thread::sleep_for is not fully/properly
implemented.
> >
> > I am using Ruben's 64-bit mingw-w64 4.7.0-enabled build.
> >
> > When I try compiling:
> >
> >
于 2012/5/14 7:40, K. Frank 写道:
> Hello All!
>
> I am finding that std::this_thread::sleep_for is not fully/properly
> implemented.
>
> I am using Ruben's 64-bit mingw-w64 4.7.0-enabled build.
>
> When I try compiling:
>
> g++ -std=c++0x -static -o test_sleep test_sleep.cpp
>
> the line:
>
>
22 matches
Mail list logo
