On Fri, Jul 19, 2013 at 4:16 AM, Kai Tietz wrote:
> I am not able your patch the next two weeks. If Jacek, Ozkan, or dw
> confirm, then patch is oj for appkay.
>
> Kai
>
> Am 18.07.2013 10:14 schrieb "Rafaël Carré" :
>>
>> Hello,
>>
>> Le 18/07/2013 21:49, Erik van Pienbroek a écrit :
>> > Hi,
>>
I am not able your patch the next two weeks. If Jacek, Ozkan, or dw
confirm, then patch is oj for appkay.
Kai
Am 18.07.2013 10:14 schrieb "Rafaël Carré" :
> Hello,
>
> Le 18/07/2013 21:49, Erik van Pienbroek a écrit :
> > Hi,
> >
> > We recently received some bug reports that executables compile
On 7/19/2013 06:49, Jim Michaels wrote:
> http://gcc.gnu.org/onlinedocs/gcc-4.8.1/libgomp/Enabling-OpenMP.html#Enabling-OpenMP
>
> OpenMP is listed in the GCC manual. I was going to try to recompile an
> application that uses openmp, butapparently omp.h is missing, and so is
> libiomp5md.dll and
http://gcc.gnu.org/onlinedocs/gcc-4.8.1/libgomp/Enabling-OpenMP.html#Enabling-OpenMP
OpenMP is listed in the GCC manual. I was going to try to recompile an
application that uses openmp, butapparently omp.h is missing, and so is
libiomp5md.dll and its lib file.
-
Jim Michaels
jmi
> you are changing Interlocked*() calls to system DLL
> functions into inline functions
This is true. If you are using x86, non-underscore versions (ie
InterlockedExchange vs _InterlockedExchange) of these 6 functions.
> I hope this is disabled by default / __MINGW_INTRIN_INLINE is undefined
>
I can confirm that with GCC 4.9. In cause of our headers, it always
chooses inline version, which is good.
That is the best possible outcome. For this particular situation. But
it's possible that's not always the case.
What with normal implementations, inline implementations, dllimport
im
2013/7/18 Václav Zeman
> On 07/15/2013 12:02 PM, Jacek Caban wrote:
> > 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/jace
Hello,
Le 18/07/2013 21:49, Erik van Pienbroek a écrit :
> Hi,
>
> We recently received some bug reports that executables compiled with
> mingw-w64 couldn't be executed on Windows XP environments. Users
> would get fatal error messages which indicate that the symbol strnlen
> couldn't be found in
On 07/15/2013 12:02 PM, Jacek Caban wrote:
> 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/7de73e013cbeec88464d19b07bc
Hi,
We recently received some bug reports that executables compiled with
mingw-w64 couldn't be executed on Windows XP environments. Users
would get fatal error messages which indicate that the symbol strnlen
couldn't be found in msvcrt.dll (which is correct for Windows XP).
I've verified this wit
On 07/18/13 08:49, dw wrote:
>
>> this issue seems t be related to a bug fixed for gcc' trunk and for
>> the 4.8 branch.
>> Could you test more recent version to see if issue remains?
>>
>
> Umm. Hmm. Ok, well, the compiler now does (silently) pick one of the
> two defined implementations and us
11 matches
Mail list logo
