Re: [Mingw-w64-public] [patch] Avoiding __MSABI_LONG ;)

Hello Corinna, yeah, windowsx.h header is always a fun ... 2012/7/24 Corinna Vinschen : > Hi, > > in preparation of the upcoming __MSABI_LONG patch, I'm spending some > time trying to avoid the macro where it's not necessary. For instance, > constants which have a cast anyway don't have to use t

Re: [Mingw-w64-public] [patch] Avoiding __MSABI_LONG ;)

Corinna, patch is ok now. Thanks, Kai 2012/7/25 Corinna Vinschen : > Hi Kai, > > On Jul 25 11:57, Kai Tietz wrote: >> Hello Corinna, >> >> yeah, windowsx.h header is always a fun ... >> >> 2012/7/24 Corinna Vin

Re: [Mingw-w64-public] apparent "hang" using the experimental pthread library

Thanks for the patch, I will take a look. Hmm, by looking at this I see that the issue might be a raise-condition about spin-locking. Means too much threads try to get spinlock-lock repeatively. So that one (or more) waiting threads simply don't get a chance to get the lock. I saw that pthread-

Re: [Mingw-w64-public] [patch] add intrin.h to BASEHEAD_LIST

Patch is ok. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpo

Re: [Mingw-w64-public] [patch] Avoiding __MSABI_LONG, latst one

Hallo Corinna, 2012/7/26 Corinna Vinschen : > Hi, > > more avoidance of __MSABI_LONG below. > > Here's a question. I already had a look into the end result after > applying the bulk __MSABI_LONG patch. Apart from the fact that it > affects a 5 digit number of lines, it looks... ugly. The string

Re: [Mingw-w64-public] [patch] Avoiding __MSABI_LONG, latst one

Patch is ok. Please go ahead. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions

Re: [Mingw-w64-public] [patch/bulk] Use __MSABI_LONG throughout

Hello Corinna, The patch is ok. My eyes suffer pain ;) Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers

Re: [Mingw-w64-public] experimental/winpthreads/src/version.rc:36: syntax error

2012/7/27 niXman : > 2012/7/27 Kyle Schwarz: >> Hi, >> >> I'm getting a syntax error when trying to compile the latest winpthread. > > Hmm... This is strange. I've built winpthreads a hour ago. > > > -- > Regards, > niXman Hmm, no idea. You might have altered something? I don't have this issue o

Re: [Mingw-w64-public] apparent "hang" using the experimental pthread library

So, I made spinlocks "fair" by revision 5274. This means that no threads get *lost* on scheduling, if lock is requested. Please give this version a try. Thanks in advance, Kai -- Live Security Virtual Conference Exclusi

Re: [Mingw-w64-public] apparent "hang" using the experimental pthread library

2012/7/27 K. Frank : > Hi Kai! > > On Fri, Jul 27, 2012 at 4:09 PM, Kai Tietz wrote: >> So, I made spinlocks "fair" by revision 5274. This means that no >> threads get *lost* on scheduling, if lock is requested. > > This is purely a matter of multi-threadi

Re: [Mingw-w64-public] apparent "hang" using the experimental pthread library

Hi Roger, 2012/7/27 Roger Pack : >> So, I made spinlocks "fair" by revision 5274. This means that no >> threads get *lost* on scheduling, if lock is requested. >> >> Please give this version a try. > > I have tried it, thanks for the patch! > > Unfortunately it appears that (ffmpeg + libx264 usin

Re: [Mingw-w64-public] experimental/winpthreads/src/version.rc:36: syntax error

I found the cause for the failure. Please update headers to revision 5276. The issue was that winver.h is using __MSABI_LONG macro, but didn't included _mingw.h, which defines it. Thanks for reporting, Kai -- Live Secur

Re: [Mingw-w64-public] XP64 SP2 and MinGW-w64 v2.0.4: the procedure entry point _chsize_s could not be located in msvcrt.dll

2012/7/29 Ruben Van Boxem : > Hi, > > Since last week I have a XP64 VM laying around for ... fun. And > compatibility checking and bug hunting obviously. > > I built Clang on Windows 7 x64, and tried running the resultant executable > from a shared folder in the VM. It failed with the error in the

Re: [Mingw-w64-public] XP64 SP2 and MinGW-w64 v2.0.4: the procedure entry point _chsize_s could not be located in msvcrt.dll

2012/7/29 Ruben Van Boxem : > 2012/7/29 Kai Tietz >> >> 2012/7/29 Ruben Van Boxem : >> > Hi, >> > >> > Since last week I have a XP64 VM laying around for ... fun. And >> > compatibility checking and bug hunting obviously. >> > >>

Re: [Mingw-w64-public] [patch] Avoid __MSABI_{U?}LONG for some UL qualified constants

Hi Corinna, 2012/7/27 Corinna Vinschen : > Hi, > > in ndrtypes.h I dropped the UL qualifiers since the values are small > positive, and the C type conversion rules will make these expressions > unsigned long anyway. There's also no good reason to add UL to enum > and typed const values. Hope tha

Re: [Mingw-w64-public] [patch] Revert adding intrin.h to BASEHEAD_LIST

Corinna, patch is ok. Please apply. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discus

Re: [Mingw-w64-public] [patch] Use __MSABI_LONG for unsigned values, too

Hello Corinna, patch is ok. Please apply. Regards, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond.

Re: [Mingw-w64-public] [patch] Avoid collision with different definitions of u_long

Corinna, patch is ok. In future, if there might be more types conflicting, we still can move this header/footer into separate helper-headers and use them instead. Thanks, Kai -- Live Security Virtual Conference Exclusive

Re: [Mingw-w64-public] [patch] Avoid collision with different definitions of u_long

2012/7/30 Corinna Vinschen : > On Jul 30 16:35, Kai Tietz wrote: >> Corinna, >> >> patch is ok. > > Thanks, but I just realized that this won't work. Patch recalled. > > > Corinna Why it shouldn't work? With

Re: [Mingw-w64-public] [patch] Replace struct timeval usage with PTIMEVAL and define TIMEVAL differently on LP64

2012/7/30 Corinna Vinschen : > Hi, > > struct timeval uses long as types of their members. This is an > obvious problem on LP64. THe below patch works around this issue > by using PTIMEVAL in place of struct timeval * in the affected > headers, and by redefinining TIMEVAL, PTIMEVAL, and LPTIMEVAL

Re: [Mingw-w64-public] [patch]: Drop including stralign.h on Cygwin

Hello Corinna, patch is ok. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions wi

Re: [Mingw-w64-public] multilib winpthreads

2012/7/31 Ruben Van Boxem : > Hi, > > Is there a cool way to build winpthreads for a multilib compiler? Hmm, not that I am aware. But NightStrike might know. > I can of course install manually, but that wouldn't be "cool". > > BTW, are there any plans to move it into the main CRT by 3.x? Yes, t

Re: [Mingw-w64-public] XP64 SP2 and MinGW-w64 v2.0.4: the procedure entry point _chsize_s could not be located in msvcrt.dll

Hi Ozkan, 2012/7/29 Ozkan Sezer : > On 7/29/12, Kai Tietz wrote: >> 2012/7/29 Ruben Van Boxem : >>> 2012/7/29 Kai Tietz >>>> >>>> 2012/7/29 Ruben Van Boxem : >>>> > Hi, >>>> > >>>> > Since last week I have

Re: [Mingw-w64-public] XP64 SP2 and MinGW-w64 v2.0.4: the procedure entry point _chsize_s could not be located in msvcrt.dll

2012/7/31 Ozkan Sezer : > On 7/31/12, Kai Tietz wrote: >> Hi Ozkan, > [...] >> So, to avoid such issues in future I begun to abstract secure-API in >> our runtime. See revision 5290 as a start. Important here is that >> for msvcrt.dll we have to remove the s

Re: [Mingw-w64-public] [patch] oleacc.idl: Use ULONG

2012/8/1 Jacek Caban : > On 08/01/12 12:22, Corinna Vinschen wrote: >> On Aug 1 11:54, Jacek Caban wrote: >>> On 08/01/12 11:49, Corinna Vinschen wrote: Hi, the below patch changes oleacc.idl to use ULONG rather than unsigned long in all calls to the XXX_UserYYY automation func

Re: [Mingw-w64-public] Dev mails on mingw-w64-public

Hi Ruben, 2012/8/1 Ruben Van Boxem : > Hi, > > I don't want to sound cranky or anything, but I noticed a lot of strictly > development emails on Cygwin work by Corinna posted to mingw-w64-public. > > I'm sure it's not strictly off-topic, but there is mingw-w64-developer(s?), > which seems more sui

Re: [Mingw-w64-public] [patch] Fix types for XXX_UserSize, XXX_UserMarshal, XXX_UserUnmarshal, and XXX_UserFree functions

Hi Corinnna, patch looks ok to me. See if Jacek have any objections (I wouldn't assume so). Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat lands

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32

Hi Corinna, 2012/8/2 Corinna Vinschen : > Hi, > > below is about 5% of the entire patch introducing __LONG32. Reviewing > more than 4 lines is far from fun, so I made a break at this point. > Noticable are a couple of places wher I kept long, these are places > where the definitions are in an

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 2

Hello Corinna, 2012/8/2 Corinna Vinschen : > Hi, > > here's another about 5% of the patch introducing __LONG32... > > > Thanks, > Corinna the patch is ok. Thanks, Kai -- Live Security Virtual Conference Exclusive live

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32

2012/8/2 Ozkan Sezer : > On 8/2/12, Kai Tietz wrote: >> Hi Corinna, >> >> 2012/8/2 Corinna Vinschen : >>> Hi, >>> >>> below is about 5% of the entire patch introducing __LONG32. Reviewing >>> more than 4 lines is far from fun, so I

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 3

Hello Corinna, my eyes ... yes, patch looks ok. Please go ahead. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 4

Hello Corinna, patch is ok. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions wi

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 5

Hello Corinna, this patch is ok, too. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discu

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 6

Hi Corinna, patch is ok. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 7

Hi Corinna, this patch is ok, too. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussi

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 8

Corinna, this patch is fine. I hope that the transition to use of IDL-files makes progress. A lot of these changes are in fact in idl-generated headers. Thanks, Kai -- Live Security Virtual Conference Exclusive live ev

Re: [Mingw-w64-public] genidl ??

Hello Earnie, genidl is a way to make .tlb and .typeinfo resources V2 human readable. It is somewhat the same as old NT typelib-viewer (if some people remember about it). Sadly documentation about V1 typelib files is less good, so I mainly focused in that tool on Version 2 typelib format. Nevert

Re: [Mingw-w64-public] apparent "hang" using the experimental pthread library

2012/8/4 Kyle Schwarz : > On 7/27/2012 5:37 PM, Kai Tietz wrote: >> > I have tried it, thanks for the patch! >>> >>> Unfortunately it appears that (ffmpeg + libx264 using it at least) >>> appears to deadlock (?) after a few seconds. >>> >>>

Re: [Mingw-w64-public] SEH

2012/8/4 niXman : > 2012/8/4 Ruben Van Boxem: >> I do not see this failure. > > The same error: > gcc-trunk/libgcc/unwind-c.c: In function '__gcc_personality_seh0': > gcc-trunk/libgcc/unwind-c.c:242:14: error: '__gcc_personality_imp' > undeclared (first use in this function) > > > > -- > Regards, >

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 9

Corinna, patch is ok for apply. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 11

Hi Corinna, so this patch is ok, too. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discu

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 10

Hi, this patch is fine. Please go ahead. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. D

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 12

Patch is ok. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpo

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 12b

Corinna, the patch is ok. 12b? You got tired by simple increasing patch-numbers? ;) Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape ha

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 14

Hi Corinna, part 14 is ok. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions wil

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 15

Patch is ok. Please apply. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 17

Hi, patch is ok. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 17 3/4

Hi, :) Ok. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoi

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 16

Hi Corinna, this patch is ok. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 17 1/2

Hello Corinna, Patch is ok. Please apply. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. D

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 18

Hello Corinna, patch is ok. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions wi

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 19

Hello Corinna, patch is ok. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions wi

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 42

Hi Corinna, patch 42 is ok. Thanks, Kai PS: I think we are nearly through, aren't we? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed a

Re: [Mingw-w64-public] [patch/bulk] Introduce __LONG32, part 42

Great. The patch for strsafe.h is ok. Thanks for all this hard work, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT mana

Re: [Mingw-w64-public] apparent "hang" using the experimental pthread library

2012/8/6 Kyle : > On 8/4/2012 3:38 AM, Kai Tietz wrote: >> 2012/8/4 Kyle Schwarz : >>> On 7/27/2012 5:37 PM, Kai Tietz wrote: >>>>> I have tried it, thanks for the patch! >>>>> >>>>> Unfortunately it appears that (ffmpeg + libx2

Re: [Mingw-w64-public] apparent "hang" using the experimental pthread library

Another question I have. Which ff-tool is blocking for you? I tried ffplay, which didn't dead-locked on my Windows-box (i7 Windows 7 64-bit). Could you provide me with example film/stream, so that I am able to reproduce your dead-lock? Thanks in advance, Kai ---

Re: [Mingw-w64-public] apparent "hang" using the experimental pthread library

2012/8/6 Kyle : > On 8/6/2012 2:45 PM, Kai Tietz wrote: >> Another question I have. Which ff-tool is blocking for you? I tried >> ffplay, which didn't dead-locked on my Windows-box (i7 Windows 7 >> 64-bit). Could you provide me with example film/stream, so that I am

Re: [Mingw-w64-public] apparent "hang" using the experimental pthread library

2012/8/6 Kyle : > On 8/6/2012 1:59 PM, Kai Tietz wrote: >> 2012/8/6 Kyle : >>> On 8/4/2012 3:38 AM, Kai Tietz wrote: >>>> 2012/8/4 Kyle Schwarz : >>>>> On 7/27/2012 5:37 PM, Kai Tietz wrote: >>>>>>> I have tried it, thanks fo

Re: [Mingw-w64-public] apparent "hang" using the experimental pthread library

2012/8/7 Kyle Schwarz : > Hi Kai, > > On 8/6/2012 4:58 PM, Kai Tietz wrote: >> I have attached a modified version of winpthread (uncomress it and >> rename it back to .dll). It would be great if you could test this >> variant on your box, too. > > Thanks a lot for

Re: [Mingw-w64-public] genidl is not build, configured using --with-tools=all

Hallo, thanks for the patch. It is applied at rev 5347, just Makefile.in need to be regenerated. Thanks, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat

Re: [Mingw-w64-public] gcc-ranlib returns error code 53?

Roger, why you want to call gcc's LTO-stub for binutils' ranlib? You shouldn't call this application. Instead please use ranlib tool without gcc in name. Regards, Kai -- Live Security Virtual Conference Exclusive live

Re: [Mingw-w64-public] error: unknown type name 'char_t' in secapi/wmemcpy_s.c

Sorry, I made a typo. Of course it should be wchar_t and not char_t. Issue fixed at rev.5357. Regards, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat l

Re: [Mingw-w64-public] strtod("NAN", &endp) not return QNAN

2012/8/4 Earnie Boyd : > I need some math whiz help. So it seems to me that strtod("NAN", > NULL) should return the same as __builtin_nan(""). And G++ should > return the same result as GCC. For the GCC instance I believe that > the crt/gdtoa/strtodnrp.c code is wrong. For the G++ instance I >

Re: [Mingw-w64-public] Packing bug with "unsigned int" bitfields

Hi Simson, the issue isn't the bitfields here and isn't related to the type in first place. The issue is that the __attribute__((pack)) works now only on the outer structure alignment, but doesn't affect the padding between different fields. Please file a bug report to gcc's bugzilla about this.

Re: [Mingw-w64-public] Position independent code (-fPIC) on x86_64 Windows dll specially for Cygwin

2012/8/8 dashesy : > Reading the Wikipedia page > (http://en.wikipedia.org/wiki/Position-independent_code) , it seems > Windows supports PIC on x64, > Please correct me if I am wrong. > I was wondering if I can build PIC dlls on x64. > This would be specially useful with "--enable-cygwin" to elimin

Re: [Mingw-w64-public] strtod("NAN", &endp) not return QNAN

2012/8/8 Earnie Boyd : > On Wed, Aug 8, 2012 at 11:01 AM, Kai Tietz wrote: >> 2012/8/4 Earnie Boyd : >>> I need some math whiz help. So it seems to me that strtod("NAN", >>> NULL) should return the same as __builtin_nan(""). And G++ should

Re: [Mingw-w64-public] strtod("NAN", &endp) not return QNAN

Found the cause for this. This was caused by dg_qnan.h header ... I really should get rid of this gdtoa ... Revision 5361 fixes this problem. Thanks for reporting, Kai -- Live Security Virtual Conference Exclusive live

Re: [Mingw-w64-public] #include causes formatting problems with PRId64

This issue is caused by default of POSIX-printf/scanf for g++. The reason is that g++ applies to printf/scanf functions two times formatting rules. One time automagical as system-default, and secondly as specified by headers. So those warnings are occuring. This might be worth a bug report on g

Re: [Mingw-w64-public] Position independent code (-fPIC) on x86_64 Windows dll specially for Cygwin

2012/8/8 dashesy : > On Wed, Aug 8, 2012 at 11:37 AM, Earnie Boyd > wrote: >> On Wed, Aug 8, 2012 at 1:33 PM, dashesy wrote: >>> BTW, this is the line in Wikipedia "64-bit Windows has switched to >>> using position-independent code for DLLs as well and has abandoned >>> relocation" >>> And it refe

Re: [Mingw-w64-public] [patch] mingw-w64-crt/Makefile.am: Drop libdelayimp.a and libglut.a from w32api install

Patch is ok. libdelayimp isn't mingw specific. It is pe-coff specific. By it you can link and handle delayed-load-libraries. It might be worth to port this feature to cygwin, not sure about that. Kai -- Live Security

Re: [Mingw-w64-public] experimental 4.7 std::thread enabled build by rubenvb

No, please ignore this advice from Earnie. It is just partial true and also misleading. Indeed the decoration of symbols with an '@' is either caused by the stdcall-convention, or by the fastcall. Nevertheless there is a way to have in export-table no '@' decoration. Just use for 32-bit the --ki

Re: [Mingw-w64-public] experimental 4.7 std::thread enabled build by rubenvb

2012/8/11 Martin Mitáš : > > Dne 11.8.2012 19:06, Kai Tietz napsal(a): >> No, >> >> please ignore this advice from Earnie. It is just partial true and >> also misleading. Indeed the decoration of symbols with an '@' is >> either caused

Re: [Mingw-w64-public] Obtaining stacktraces within a Windows application

Hello, well, you have here different ways to achieve this. First thing to start about is the backtrace. You can find such sample code in our experimental tree (or at stackoverflow as you've shown). By those addresses you can either use binutils' addr2line tool to get more detailed information, o

Re: [Mingw-w64-public] [Mingw-users] x86_64-w64-mingw32-gcc: error: unrecognized option '-pthread'

Hi Wangfeng, you were asking your question on wrong mailing-list. I redirected you to mingw-w64's list. Please be aware that mingw.org and mingw-w64 are two different ventures, and you won't get support for mingw-w64 on mingw.org's ML. 2012/8/16 wangfeng wangfeng : > Hi, > I used x86_64-w64-min

Re: [Mingw-w64-public] [Mingw-users] building 64 bit

Hi Damon, I re-directed you to the mingw-w64 list. MinGW.org doesn't have 64-bit support. It might be that they will come up with some in future, but right now there is only mingw-w64 for 64-bit. By this reason you will get best answers by asking on our list. Also be aware that mingw.org and m

Re: [Mingw-w64-public] [Mingw-users] 64-bit or 32-bit gfortran/minGW

Hi Wayne, I redirected you to mingw-w64's ML. There is no support of 64-bit target on MinGW.org. So you don't need to wonder. If you want 64-bit target (or hosted) toolchain, you should use mingw-w64 based version. Please be aware that MinGW.org and mingw-w64 are two different ventures. Regar

Re: [Mingw-w64-public] Conflicting declaration of getcwd in io.h

Hallo Rainer, well, the issue is that msvcrt's getcwd has as second argument the pointer-length-argument typed as 'int'. You can check this also by seaching on msdn for getcwd. For 32-bit it is just a sign-difference of this argument, which is pretty unlikely to reach (0x7fffu + 1u). For 64-

Re: [Mingw-w64-public] GCC intrinsics headers and windows.h

Hello, the issue here about this problem is that gcc's *ntrin.h headers don't have C++-clauses. So you either can fix the issue by adding and 'extern "C" {' around the include. Or you are using intrin.h header directly. The intrin.h header is intended for this and is a C-runtime header. An ech

Re: [Mingw-w64-public] using libraries built with mingw in Visual C++

Well, Qt Creator should support also mingw-w64 for 64-bit (and 32-bit). On their support-page I didn't saw that. Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and

Re: [Mingw-w64-public] openmp/pthread debug test case

This test program is invalid. Your application tries to create an thread and afterwards immediately terminates (by returning from main). By add the line 'pthread_join (id, NULL);' after creation of the thread, you will see the message "I am a thread!" as expected. Regards, Kai -

Re: [Mingw-w64-public] how convert png/tif/jpg/gif to bmp?

Hi, AFAIR there is a way to do some of this with WIC-DCOM interfaces. See http://msdn.microsoft.com/en-us/library/windows/desktop/ee719655%28v=vs.85%29.aspx as reference. Nevertheless I would prefer something like imagemagic (or equivalent). Kai

Re: [Mingw-w64-public] how convert png/tif/jpg/gif to bmp? - no COM libs!

Hmm, I assume that in that library are just the GUIDs. Does our libuuid.a not contain the relevant GUIDs? Cheers, Kai -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and

Re: [Mingw-w64-public] -ffloat-store not needed with 64-bit compiler

2012/9/8 Sisyphus : > Hi, > > Attached is a small demo program (demo.c). > > With 32-bit mingw compilers (both mingw.org's 4.5.2 and mingw64's 4.6.3) the > output of that program differs, depending upon whether I build it with > -ffloat-store or not. > I've no problem with that - I think I understa

Re: [Mingw-w64-public] how convert png/tif/jpg/gif to bmp? - no COM libs!

Hi Jim, on our trunk-version we provide this library. We synchronized this library with Wine and Jacek told me on IRC that this library is present and is containing the CLSIDs. Is that the library you are missing, or does this library misses some exports for you? Regards, Kai --

Re: [Mingw-w64-public] Add VS2012 CRT support

Hello Dongsheng, patch looks ok. Just one nit I see. Within that patch also a change to testsuite's make is made. For that a changelog entry is missing. Regards, Kai 2012/9/12 Dongsheng Song : > On Wed, Sep 12, 2012 at 4:19 PM, Dongsheng Song > wrote: >> Hi all, >> >> These 2 attachments tr

Re: [Mingw-w64-public] UpdateLayeredWindowIndirect missing in lib32/user32.def

Hi, thanks for the information. Missing import is present on trunk at revision 5409, Maybe Ozkan wants to add it to 2.x branch too. Thanks, Kai -- Everyone hates slow websites. So do we. Make your web apps faster with

Re: [Mingw-w64-public] UpdateLayeredWindowIndirect missing in lib32/user32.def

Hi Ray, 2012/9/20 Ray Donnelly : > Hi guys, > > Is there any chance this minor fix could be put into the branches? > > http://sourceforge.net/tracker/?func=detail&aid=3533362&group_id=202880&atid=983356 > > Cheers, > > Ray. Well, I have no objections about this patch. I think it was a mistake to

Re: [Mingw-w64-public] Problem with mingw32-make and long commands (x86_64-w64-mingw32-gcc-4.7.2-release-win64_rubenvb)

Hi, yes this difference is caused - IIRC - by a change of process-spawning in mingw,org's make. Not sure if this patch is already upstream, but the limitted command-line-buffer o 8k can be extended to 32k buffer by using CreateProcess directly instead of using CMD.exe here. See for some details

Re: [Mingw-w64-public] SEH

2012/9/28 Earnie Boyd : > Please forgive my laziness as not having enough time yet to download > and format an environment with 4.8 GCC as yet. Is there a predefined > macro to indicate when I have SEH support? Yes, there is. Regards, Kai

Re: [Mingw-w64-public] [PATCH] Fix dynamic tls section injection via '.CRT$XD*'

Hi, the patch looks in general good to me. I have one nit about it, which needs to be resolved before it can be applied. As users might use older binutils-version without __xd_start/end symbol, it is necessary to probe for it in configure and use here a guard to make decision of new-linker-scrip

Re: [Mingw-w64-public] the compiler treats '__cdecl' & '__stdcall' as the same.

2012/10/10 niXman : > For example, this code work as expected: > > > template > struct is_same { > enum { value = 0 }; > }; > > template > struct is_same { > enum { value = 1 }; > }; > > int main() { > typedef void(__stdcall* stdcall_func_ptr)(); > typedef void(__cde

Re: [Mingw-w64-public] [patch] winternl.h: Add file and filesystem related functionality

Hi Corinna, patch is ok. Well, I am not opposed to replace WINAPI here in that header by NTAPI. Ozkan, any objections? Thanks, Kai 2012/10/11 Corinna Vinschen : > Hi, > > the below patch adds a bit of file and file system releated stuff > to winternl.h. This is quite useful functionality and

Re: [Mingw-w64-public] [patch] winternl.h: Add file and filesystem related functionality

2012/10/11 Corinna Vinschen : > On Oct 11 18:39, Rainer Emrich wrote: >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA1 >> >> This patch causes an issue compiling winpthreads! >> [...] >> D:/x86_64-w64-trunk/mingw/include/winternl.h:513:5: error: unknown type name >> 'DEVICE_TYPE' > > Sorry. I d

Re: [Mingw-w64-public] Detect mingw

2012/10/16 Antony Riakiotakis : > Usually __MINGW64__ is defined so you can check for that in the source. First, that define is only set for 64-bit mode, but mingw-w64 also supports 32-bit (old mingw.org) mode. Secondly that define is provided by the compiler and isn't runtime-specific at all. As

[Mingw-w64-public] RFC: How shall we plan releases of new major versions?

Hello everybody, I want to raise this discussion on public mailing-list, as mingw-w64's release-cycle might be also of interest to some of our users. Right now we do the major-release by gut feeling with a background plan about features new version shall include. Now I got the request to do maj

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

Helle Simson, this list seems to me more like good content to our FAQ-section in Wiki. Some of those points might be defining general goals we wanna to define, or decline for mingw-w64 in general. Most of those points are looking like something desirable, but on a technical POV it shows that some

Re: [Mingw-w64-public] Configure error tzset()

Hi, well this issue is caused by invalid, or better said inadequate testcase for windows. tzname is a imported variable provided by msvcr*.dll (C-runtime). So its decoration with the dllimport-attribute is correct. We could remove from our C-headers the dllimport-attribute for dll-imported vari

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major

Yes, you have to take care to provide a link to source-code or the source itself of the gcc libraries with runtime-exception you are using. It is not enough to point to somebody else, which might provide the sources. Btw this is the cause why mingw-w64 always does binary and source-package relea

Re: [Mingw-w64-public] Relative path linking

2012/10/26 Алексей Павлов : > Hi! > Can I link program with shared library that not in PATH by relative path on > windows? I have structure like below: > > ORIGIN > |- bin > | \-program.exe > |- opt > | |-lib > | | \-mylib.dll Yes, this is possible. But DLL loading mechanism wor

Re: [Mingw-w64-public] RFC: How shall we plan releases of new major versions?

2012/10/28 Erik van Pienbroek : > JonY schreef op zo 28-10-2012 om 19:08 [+0800]: >> On 10/28/2012 18:33, Erik van Pienbroek wrote: >> > JonY schreef op zo 28-10-2012 om 10:42 [+0800]: >> >> Does that include several large C++ programs? I need to test a patch for >> >> trunk headers. >> >> >> >> If

<    3   4   5   6   7   8   9   10   11   >