Op 3 apr. 2013 07:41 schreef "Ahso Aa" het volgende:
>
> Hi
> it works with mingw32 on Vista64 or on Linux/gcc 32 and 64bit. But with
mingw64 I get:
> a segmentation fault at IMG_Load:
>
> static int LoadGLTex(char *pFileName, int TextureId)
> {
> SDL_Surface* image = IMG_Load(pFileName);
>
> Any
Hi
it works with mingw32 on Vista64 or on Linux/gcc 32 and 64bit. But with
mingw64 I get:
a segmentation fault at IMG_Load:
static int LoadGLTex(char *pFileName, int TextureId)
{
SDL_Surface* image = IMG_Load(pFileName);
Any help on what to change?
Many thanks
Mike
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Le 03/04/2013 00:07, JonY a écrit :
> On 4/2/2013 23:34, Kai Tietz wrote:
>> patch is ok. jony any objections?
>>
>> thanks Kai
>
> I'm OK with it.
Committed as r5715
Thanks
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment:
On 4/2/2013 23:34, Kai Tietz wrote:
> patch is ok. jony any objections?
>
> thanks
> Kai
I'm OK with it.
signature.asc
Description: OpenPGP digital signature
--
Minimize network downtime and maximize team effectiven
patch is ok. jony any objections?
thanks
Kai
Am 02.04.2013 11:51 schrieb "Rafaël Carré" :
> Remove time/_time32 .c replacements
> ---
> mingw-w64-crt/ChangeLog |7 +
> mingw-w64-crt/Makefile.am|4 +-
> mingw-w64-crt/Makefile.in| 1923
> ++
On Apr 2 11:05, NightStrike wrote:
> On Tue, Apr 2, 2013 at 9:48 AM, Corinna Vinschen wrote:
> > On Apr 2 03:00, NightStrike wrote:
> >> On Tue, Apr 2, 2013 at 2:40 AM, Corinna Vinschen
> >> wrote:
> > Ok, done. The order of the variables is different between 32 and 64
> > bit. I did it the
On Tue, Apr 2, 2013 at 9:48 AM, Corinna Vinschen wrote:
> On Apr 2 03:00, NightStrike wrote:
>> On Tue, Apr 2, 2013 at 2:40 AM, Corinna Vinschen wrote:
> Ok, done. The order of the variables is different between 32 and 64
> bit. I did it the same way as in the following shell32.a rule for the
On Apr 2 03:00, NightStrike wrote:
> On Tue, Apr 2, 2013 at 2:40 AM, Corinna Vinschen wrote:
> > The below patch implements this. It strips the intrinsic functions
> > from the src_libmingwex variable and introduces a src_intrincs
> > variable instead. It also renames src_libmingwex32 and src_l
On Tue, Apr 2, 2013 at 2:40 AM, Corinna Vinschen wrote:
> Hi,
>
> today we got a report on the cygwin-developers mailing list, which
> reported that linking a certain library fails, because some of the
> inline functions in winnt.h can't be resolved by the linker under
> Cygwin:
>
> http://cygwi
Hi,
today we got a report on the cygwin-developers mailing list, which
reported that linking a certain library fails, because some of the
inline functions in winnt.h can't be resolved by the linker under
Cygwin:
http://cygwin.com/ml/cygwin-developers/2013-04/msg00010.html
The problem here is t
Thank you all for your clear explanations!
On Tue, Apr 2, 2013 at 3:23 PM, JonY wrote:
> On 4/2/2013 20:05, Ruben Van Boxem wrote:
> > If you want a static winpthreads but shared libgcc/libstdc++, you'll need
> > to remove libwinpthread.dll.a from your toolchain directory. Your mileage
> > may
On 4/2/2013 20:05, Ruben Van Boxem wrote:
> If you want a static winpthreads but shared libgcc/libstdc++, you'll need
> to remove libwinpthread.dll.a from your toolchain directory. Your mileage
> may vary. Note my current builds only work with -static, I omitted the
> known fix for this issue from
2013/4/2 Baruch Burstein
> Just to clarify that I understand the process:
> The GCC implementation of and friends (part of the libc or libgcc
> or libstdc++ or whatever the GCC standard library is called) really uses
> pthread calls under the hood. Changing that would mean changing the code of
>
Just to clarify that I understand the process:
The GCC implementation of and friends (part of the libc or libgcc
or libstdc++ or whatever the GCC standard library is called) really uses
pthread calls under the hood. Changing that would mean changing the code of
the standard library implementation.
Op 2 apr. 2013 11:51 schreef "Kai Tietz" het
volgende:
>
> 2013/4/2 Ruben Van Boxem
>>
>> 2013/4/2 Baruch Burstein
>>>
>>> Can you explain the difference from your "regular" builds? Does
std::thread not work with them? If I use std::thread, do I need to
link/distribute any additional libraries?
Remove time/_time32 .c replacements
---
mingw-w64-crt/ChangeLog |7 +
mingw-w64-crt/Makefile.am|4 +-
mingw-w64-crt/Makefile.in| 1923 +-
mingw-w64-crt/lib32/msvcr100.def |3 +-
mingw-w64-crt/lib32/msvcr110.def |1 +
ming
2013/4/2 Ruben Van Boxem
> 2013/4/2 Baruch Burstein
>
>> Can you explain the difference from your "regular" builds? Does
>> std::thread not work with them? If I use std::thread, do I need to
>> link/distribute any additional libraries? Or are there special licenses
>> issues?
>> In short: Why 2
2013/4/2 Baruch Burstein
> Can you explain the difference from your "regular" builds? Does
> std::thread not work with them? If I use std::thread, do I need to
> link/distribute any additional libraries? Or are there special licenses
> issues?
> In short: Why 2 separate builds?
>
std::thread (an
Can you explain the difference from your "regular" builds? Does std::thread
not work with them? If I use std::thread, do I need to link/distribute
any additional libraries? Or are there special licenses issues?
In short: Why 2 separate builds?
On Tue, Mar 26, 2013 at 9:02 PM, Ruben Van Boxem
wrot
19 matches
Mail list logo
