2011/9/21 K. Frank
> Hi Ruben!
>
> Slight change of topic, but related...
>
> On Wed, Sep 21, 2011 at 11:57 AM, Ruben Van Boxem
> wrote:
> > Hi,
> >
> > I'm running into this compiler error when building Qt 4.8 with my 4.6
> > std::thread toolchain:
>
> Please keep me (us) posted on this, and pl
Hi Ruben!
Slight change of topic, but related...
On Wed, Sep 21, 2011 at 11:57 AM, Ruben Van Boxem
wrote:
> Hi,
>
> I'm running into this compiler error when building Qt 4.8 with my 4.6
> std::thread toolchain:
Please keep me (us) posted on this, and please offer any advice about
building Qt wi
Hi,
I'm running into this compiler error when building Qt 4.8 with my 4.6
std::thread toolchain:
m:\Development\Source\Qt\src\corelib\tools\qdatetime.cpp: In function
> 'QDateTimePrivate::Spec utcToLocal(QDate&, QTime&)':
>
m:\Development\Source\Qt\src\corelib\tools\qdatetime.cpp:4069:18: error:
Francois,
I was trying for some time to build dlls for JNI and java 64 bits and
always failed (albeit using gfortran as linker).
Would you mind listing all your compile and linker flags?
Thx a bunch,
H.
--
All the data
2011/9/21 Ruben Van Boxem
> Hi everyone!
>
> I am glad to announce yet another awesome rubenvb MinGW-w64 build! I
> backported the std::thread fixes for GCC to version 4.6, and built all my
> stuff again. This time, I used vanilla MinGW-w64 v2 (SVN release branch) and
> winpthreads, which recentl
Hi everyone!
I am glad to announce yet another awesome rubenvb MinGW-w64 build! I
backported the std::thread fixes for GCC to version 4.6, and built all my
stuff again. This time, I used vanilla MinGW-w64 v2 (SVN release branch) and
winpthreads, which recently received a bunch of attention to supp
> > > Did you try with `which gcc` and starting from there?
> >
> > Yes, thanks. But I haven't spent enough time thinking about an easy way to
> > use following to translate the `which gcc` path back to the cmd.exe friendly
> > version...likely will settle on a (hopefully non-fragile) regex on the
2011/9/21 Jon
> > >>> I'm working on an app (targeted to run on WinXP_SP2+) having DLLs
> with runtime dependencies on the particular MinGW-w64 `libgcc_s_sjlj-1.dll`
> and `libstdc++-6.dll` artifacts used to build the app. As such, these
> specific artifact versions will need to be placed on the
> >>> I'm working on an app (targeted to run on WinXP_SP2+) having DLLs with
> >>> runtime dependencies on the particular MinGW-w64 `libgcc_s_sjlj-1.dll`
> >>> and `libstdc++-6.dll` artifacts used to build the app. As such, these
> >>> specific artifact versions will need to be placed on the end
x86_64-w64-mingw32-strip kbhook.dll
gives a 88 kb file instead of 509 kb.
Thanks
François
From: Ruben Van Boxem [mailto:vanboxem.ru...@gmail.com]
Sent: mercredi, 21. septembre 2011 13:32
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Compiling a dll for JNI and java 6
2011/9/21 RAPPAZ Francois
> >Btw I assume you could shrink DLL in size by using here strip for it.
>
>
> How exactly ? is it a compiler option ?
>
>
strip is a part of binutils and is a standalone program. You can run it like
so:
strip myexecutable.exe
or
strip mylibrary.dll
or
x86_64-w64-mingw3
>Btw I assume you could shrink DLL in size by using here strip for it.
How exactly ? is it a compiler option ?
François
--
All the data continuously generated in your IT infrastructure contains a
definitive record of cu
2011/9/21 xunxun
> Hi, Ruben
>
> If you back port the std::thread to gcc4.6, you can use the patch.
>
Thanks for the patch, but I had already located the official commits, which
I cherry-picked into the 4.6 branch instead.
>
> ps: may you follow the binutils bug issue PR 12762 (
> htt
2011/9/21 RAPPAZ Francois :
> Brv
>
> It works... the dll is now 509 KB, but it is loaded without error.
>
> For me this is all like magic going on...
>
> Thanks a lot for your help.
>
> François
>
Nice to hear that it finally works for you. No problem, be welcome :)
Btw I assume you coul
Brv
It works... the dll is now 509 KB, but it is loaded without error.
For me this is all like magic going on...
Thanks a lot for your help.
François
-Original Message-
From: Kai Tietz [mailto:ktiet...@googlemail.com]
Sent: mercredi, 21. septembre 2011 11:00
To: mingw-w64-pu
On Wed, Sep 21, 2011 at 12:41 PM, Kai Tietz wrote:
> 2011/9/21 Pete Batard :
>> On 2011.09.21 07:51, Ozkan Sezer wrote:
>>> Hmm, do the following fix your case?
>>>
>>> Kai?
>>>
>>> --- _timeval.h~ 2010-05-26 20:21:09.0 +0300
>>> +++ _timeval.h 2011-09-21 09:48:42.0 +0
2011/9/21 Pete Batard :
> On 2011.09.21 07:51, Ozkan Sezer wrote:
>> Hmm, do the following fix your case?
>>
>> Kai?
>>
>> --- _timeval.h~ 2010-05-26 20:21:09.0 +0300
>> +++ _timeval.h 2011-09-21 09:48:42.0 +0300
>> @@ -16,7 +16,7 @@ struct timeval
>> #define timeriss
On 2011.09.21 07:51, Ozkan Sezer wrote:
> Hmm, do the following fix your case?
>
> Kai?
>
> --- _timeval.h~ 2010-05-26 20:21:09.0 +0300
> +++ _timeval.h2011-09-21 09:48:42.0 +0300
> @@ -16,7 +16,7 @@ struct timeval
> #define timerisset(tvp) ((tvp)->tv_sec
Hi,
So I see that here no libstdc++-6.dll is linked. Could you try to
rebuild it with additional option '-static'?
Kai
2011/9/21 RAPPAZ Francois :
> Just in case, here is first lines of the dump of the 32 bits dll that works
> with java 32 bits.
>
> kbhook32.dll: file format pei-i386
> kbh
Hi, Ruben
If you back port the std::thread to gcc4.6, you can use the patch.
ps: may you follow the binutils bug issue PR 12762 (
http://sourceware.org/bugzilla/show_bug.cgi?id=12762 )?
I can't find the smallest testcase.
Thanks.
--
Best Regards,
xunxun
diff -ruNa old/gcc/c
20 matches
Mail list logo