From: Earnie B. <ear...@ya...> - 2001-04-16 15:40:11
|
-------- Original Message -------- Subject: Re: [Fwd: w32api and gcc -pedantic]] Date: Mon, 16 Apr 2001 11:13:11 -0400 From: Christopher Faylor <cg...@re...> Reply-To: cyg...@cy... To: Cygwin Patches <cyg...@cy...> References: <3AD...@ya...> <116...@lo...> On Mon, Apr 16, 2001 at 06:25:20PM +0400, egor duda wrote: >Warnings should stay as long as we talk about user's code. But when it >comes to system header files, i believe (and my reading of various >existing standard headers make me believe so) that we should work >around such warnings. For example, many standard headers contain >fragments like this one: > >#if defined(__STDC__) || defined(__cplusplus) >#define SIG_DFL ((void (*)(int))0) >#define SIG_IGN ((void (*)(int))1) >#define SIG_ERR ((void (*)(int))-1) >#else >#define SIG_DFL ((void (*)())0) >#define SIG_IGN ((void (*)())1) >#define SIG_ERR ((void (*)())-1) >#endif > >so, it doesn't matter if we use compiler (or compile-time switch for >compiler) that doesn't support some feature or fires a warning seeing >it -- standard headers will compile cleanly. > >if running gcc with '-pedantic' define some macro that could be tested >in standard headers, we could use it. But, afaik, it doesn't define >anything like it. Instead, gcc info recommends marking such code fragments >explicitly as '__extension__'. > >My point is: standard headers shouldn't produce warnings whether you >compile them with new version of compiler or old one. It should matter for >user's code not for standard headers. I agree with this. I believe that there is actually code in gcc already that suppresses certain types of errors in system headers. I think we would be confusing the user unnecessarily if we warn them about something that the theoretically should have no control over. IMO, system headers should not produce warnings, ever. cgf _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: <dan...@ya...> - 2001-01-18 23:47:10
|
--- Mumit Khan <khan@NanoTech.Wisc.EDU> wrote: > On Thu, 18 Jan 2001, Earnie Boyd wrote: > > > Danny Smith has discovered that these functions as prototyped in > wchar.h > > aren't exported from msvcrt.dll they are instead exported from > > Microsoft's STL runtime which is currently msvcp60.dll. Actually msvcp60.dll is the iostream (templated version) lib. STL, per se, is collection of template definitions and lives in headers. >My > decision on > > this is to wrap the definition of these functions with a `#ifdef > > __cplusplus' since the msvcp60.dll is readily available from the > net for > > download. > > Could you or Danny please send me some more info. Evidently, I missed > the > earlier part of this thread, and don't quite know which exports > you're > talking about. > Mumit - This is the start of the thread: The following functions declared in wchar.h are not available in msvcrt.dll. They *are* in msvcp60.dll. btowc mbrlen mbrtowc mbsrtowcs wcrtomb wcsrtombs wctob The declarations should be removed from wchar.h. A patch to do that has been submitted. Note - These functions are all restartable (mb conversion states are s stored in mbstate_t argument,or static variable for subsequent calls) If we're not worried about locale support for mb, and only want C locale, they are very simple functions. Minimalist versions are avaialble in Doug Gwyn's Q8 package, which is PD. This package also contains wmemset, wmemcpy, wmemmove, et al which are also missing from msvcrt.dll and C99 functions strtoimax, strtoumax and wchar versions. I have built a static lib from these, done some very simple tests and no problems yet. If you do want locale support for the restartable mb functions, I have done a bit of work, using the WideChartoMultibyte Win32 API function. But very prelim at this stage. > > Yes I know that we have the stdc++3 library but in pure Minimalist > form > > we need to use the MSVC STL as the default and allow a -mstdc++ > switch > > to override it. Also in support of the MS STL I think we should > specs > > declare __MSVCP__=60. > > The only exports we can use are the C based ones, and GNU C++ runtime > library (v3) configuration will pick those out. We can't use MSVC STL > or any part of the C++ runtime library, but of course you already > know > that. > > > Danny, can you provide an exports .def file for msvcp60.dll? > Will do tonight. Its very hot and the kids are screaming at me to go for a swim. Danny Cheers _____________________________________________________________________________ http://au.classifieds.yahoo.com/au/car/ - Yahoo! Cars - Buy, sell or finance a car.. |
From: Mumit K. <khan@NanoTech.Wisc.EDU> - 2001-01-19 04:54:07
|
On Fri, 19 Jan 2001, Danny Smith wrote: > Mumit - This is the start of the thread: > > The following functions declared in wchar.h are not available in > msvcrt.dll. > They *are* in msvcp60.dll. > btowc > mbrlen > mbrtowc > mbsrtowcs > wcrtomb > wcsrtombs > wctob > > The declarations should be removed from wchar.h. A patch to do that has > been submitted. Thanks. I looked at MSDN after Earnie had sent me the digest archive and found the on these, and with your explanation, I finally understand what these really do. Restartable mb functions are nice, even if very few portable software will use it simply because these are platform- and compiler-specific. So, as I see it, here are our choices (I don't have strong feelings about this issue): 1. Remove the declarations and leave the rest as is. Can't use these anyway, so why have the decls. 2. Keep the decls and have a separate import library (or forward these from within libmingw*.a import library) so that users who need these will be happy. I've never used msvcpXX.dll, so don't know if it will work offhand. No reason why it should, of course we should keep out the C++ symbols out of the import library. 3. Take Danny's suggestion, after he's done with his swim of course ;-), and start looking at independent implementation. I do remember running across Gwyn's Q8, but don't remember any details. I guess if I were to ever use these restartable mb functions, I'd definitely want these to support locales. Since we already have the decls in the headers and we can in theory use these out of msvcpXX, looks like (2) is a good way to start and then see where things go from there. > Will do tonight. Its very hot and the kids are screaming at me to go > for a swim. Yeah, I think I'll go shovel some snow, and bust up the huge icicles that are hanging from the side of my house ... Regards, Mumit |
From: Paul G. <pga...@te...> - 2001-01-19 00:50:32
|
On 19 Jan 2001, at 12:47, the Illustrious Danny Smith wrote: > > > Danny, can you provide an exports .def file for msvcp60.dll? > > > > > Will do tonight. Its very hot and the kids are screaming at me to go > for a swim. Ahh, summertime in the Southern Hemisphere... Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |
From: <dan...@ya...> - 2001-04-16 20:59:59
|
--- Earnie Boyd <ear...@ya...> wrote: > > > -------- Original Message -------- > Subject: Re: [Fwd: w32api and gcc -pedantic]] > Date: Mon, 16 Apr 2001 11:13:11 -0400 > From: Christopher Faylor <cg...@re...> > Reply-To: cyg...@cy... > To: Cygwin Patches <cyg...@cy...> > References: <3AD...@ya...> > <116...@lo...> > > On Mon, Apr 16, 2001 at 06:25:20PM +0400, egor duda wrote: > >Warnings should stay as long as we talk about user's code. But when it > >comes to system header files, i believe (and my reading of various > >existing standard headers make me believe so) that we should work > >around such warnings. For example, many standard headers contain > >fragments like this one: > > > >#if defined(__STDC__) || defined(__cplusplus) > >#define SIG_DFL ((void (*)(int))0) > >#define SIG_IGN ((void (*)(int))1) > >#define SIG_ERR ((void (*)(int))-1) > >#else > >#define SIG_DFL ((void (*)())0) > >#define SIG_IGN ((void (*)())1) > >#define SIG_ERR ((void (*)())-1) > >#endif > > > >so, it doesn't matter if we use compiler (or compile-time switch for > >compiler) that doesn't support some feature or fires a warning seeing > >it -- standard headers will compile cleanly. > > > >if running gcc with '-pedantic' define some macro that could be tested > >in standard headers, we could use it. But, afaik, it doesn't define > >anything like it. Instead, gcc info recommends marking such code fragments > >explicitly as '__extension__'. > > > >My point is: standard headers shouldn't produce warnings whether you > >compile them with new version of compiler or old one. It should matter for > >user's code not for standard headers. > > I agree with this. I believe that there is actually code in gcc already > that suppresses certain types of errors in system headers. > > I think we would be confusing the user unnecessarily if we warn them > about > something that the theoretically should have no control over. > > IMO, system headers should not produce warnings, ever. > > cgf > I'm convinced, and withdraw my objection. The only thing that bothers me is that the sometimes, when it is convenient, the w32api is called "system". When it is not convenient, it is called other things which the rules of polite conversation prevent me from repeating. Danny _____________________________________________________________________________ http://movies.yahoo.com.au - Yahoo! Movies - Now showing: Dude Where's My Car, The Wedding Planner, Traffic.. |
From: Paul G. <pga...@qw...> - 2001-04-16 21:29:29
|
Hi folks, On 17 Apr 2001, at 6:59, the Illustrious Danny Smith wrote: > > --- Earnie Boyd <ear...@ya...> wrote: > > > > > -------- Original Message -------- > > Subject: Re: [Fwd: w32api and gcc -pedantic]] > > Date: Mon, 16 Apr 2001 11:13:11 -0400 > > From: Christopher Faylor <cg...@re...> > > Reply-To: cyg...@cy... > > To: Cygwin Patches <cyg...@cy...> > > References: <3AD...@ya...> > > <116...@lo...> > > > > On Mon, Apr 16, 2001 at 06:25:20PM +0400, egor duda wrote: > > >Warnings should stay as long as we talk about user's code. But when > > >it comes to system header files, i believe (and my reading of various > > >existing standard headers make me believe so) that we should work > > >around such warnings. For example, many standard headers contain > > >fragments like this one: > > > > > >#if defined(__STDC__) || defined(__cplusplus) > > >#define SIG_DFL ((void (*)(int))0) > > >#define SIG_IGN ((void (*)(int))1) > > >#define SIG_ERR ((void (*)(int))-1) > > >#else > > >#define SIG_DFL ((void (*)())0) > > >#define SIG_IGN ((void (*)())1) > > >#define SIG_ERR ((void (*)())-1) > > >#endif > > > > > >so, it doesn't matter if we use compiler (or compile-time switch for > > >compiler) that doesn't support some feature or fires a warning seeing > > >it -- standard headers will compile cleanly. > > > > > >if running gcc with '-pedantic' define some macro that could be > > >tested in standard headers, we could use it. But, afaik, it doesn't > > >define anything like it. Instead, gcc info recommends marking such > > >code fragments explicitly as '__extension__'. > > > > > >My point is: standard headers shouldn't produce warnings whether you > > >compile them with new version of compiler or old one. It should > > >matter for user's code not for standard headers. I agree, no sense in producing standard header warnings. I can think of only one possible exception having to do with win32api ACL (OS Specific) extensions...keeping the standard functions/headers transparent is the preferred approach, imho. > > IMO, system headers should not produce warnings, ever. > > The developer should, however, be made aware of the reasons for this in order to save time when it comes to meeting project deadlines. > > cgf > > > > I'm convinced, and withdraw my objection. > The only thing that bothers me is that the sometimes, when it is > convenient, the w32api is called "system". When it is not convenient, > it is called other things which the rules of polite conversation prevent > me from repeating. Danny I hear what you are saying Danny. Wish there were more abstraction between OS variations on the win32api. Such vagueness re: OS variations, I suppose, is another "feature" of the win32api (The "Ghost of Elvis Presley" walks in, and begins mindlessly repeating, "Thank you, Microsoft, thank you very much")... Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |
From: Paul G. <pga...@qw...> - 2001-05-05 19:51:35
|
Hi folks, On 4 May 2001, at 10:31, the Illustrious Earnie Boyd wrote: > Is this something that should be included in w32api? Technically, it is _not_ win32api. Do we really want to maintain it? Peace, Paul G. > > Earnie. > > -------- Original Message -------- > Subject: Using setupapi.lib/h/dll from cygwin > Date: Fri, 4 May 2001 15:11:45 +0200 > From: "Svein Erling Seldal" <Sve...@ed...> > To: <cy...@cy...> > > > Hi, > > I'm building a GNU program which is dependent on functions from the MS > library 'setupapi.lib' (which in turn loads 'setupapi.dll'). This > library is not included in the w32api package. > > How do I proceed to get this included into my program? I've successfully > compiled the program (using MS headers), but complete linking remains. > It misses and requires four functions which is exported in setupapi.dll. > > How do I include a custom dll into my program, like this? > > > Regard, > Svein Erling Seldal > > > -- > Want to unsubscribe from this list? > Check out: http://cygwin.com/ml/#unsubscribe-simple > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > http://lists.sourceforge.net/lists/listinfo/mingw-dvlpr > Nothing real can be threatened. Nothing unreal exists. |
From: <dan...@ya...> - 2001-05-05 22:13:15
|
--- Paul Garceau <pga...@qw...> wrote: > Hi folks, > > On 4 May 2001, at 10:31, the Illustrious Earnie Boyd wrote: > > > Is this something that should be included in w32api? > > Technically, it is _not_ win32api. Do we really want to maintain it? > Technically, what does it matter if we call it win32api or not? the setupapi is included in the file win32api.csv which lists functs, structs, message etc, in the PSDK. If it is useful, it should be maintained, by someone. Who else should maintain for mingw use if mingw doesn't? > Peace, > > Paul G. > > > > Earnie. > > > > -------- Original Message -------- > > Subject: Using setupapi.lib/h/dll from cygwin > > Date: Fri, 4 May 2001 15:11:45 +0200 > > From: "Svein Erling Seldal" <Sve...@ed...> > > To: <cy...@cy...> > > > > _____________________________________________________________________________ http://store.yahoo.com.au - Yahoo! Store - It's time you had your business online! |
From: Paul G. <pga...@qw...> - 2001-05-06 20:55:47
|
Hi folks, On 6 May 2001, at 8:13, the Illustrious Danny Smith wrote: > > --- Paul Garceau <pga...@qw...> wrote: > Hi folks, > > > > On 4 May 2001, at 10:31, the Illustrious Earnie Boyd wrote: > > > > > Is this something that should be included in w32api? > > > > Technically, it is _not_ win32api. Do we really want to maintain it? > > > > Technically, what does it matter if we call it win32api or not? I am only thinking of proprietary issues, especially given the latest MS philosophy re: licensing where something like XP is involved. > > the setupapi is included in the file win32api.csv which lists functs, > structs, message etc, in the PSDK. > > If it is useful, it should be maintained, by someone. > Who else should maintain for mingw use if mingw doesn't? I don't really have a problem with us maintaining it, I can barely find time to do what little (hardly noticeable stuff) that I already do. If we add setupapi to archive, then that would mean another revision to the proposed archive I posted to sourceforge for a single Mingw distribution (which, incidentally, I still haven't hear word one about from the developers; especially re: what seems to be a clear desire of folks on the mingw-user list to have a single distribution archive for Mingw available for download.) Peace, Paul G. Nothing real can be threatened. Nothing unreal exists. |
From: Earnie B. <ear...@ya...> - 2001-08-07 10:40:30
|
Mumit or Danny, Is this just gcc-3.0 issues? Earnie. Christopher Faylor wrote: > > This is an old problem that I never saw any reaction to. > > Does anyone understand what the problem may be here? > > cgf > > ----- Forwarded message from Paul Johnson <pau...@uk...> ----- > > From: Paul Johnson <pau...@uk...> > To: cy...@cy... > Subject: I believe this is a typo. > Date: Tue, 03 Jul 2001 16:22:30 -0500 > > When I try to compile things with gcc 3.0 against <window.h>, the build > ends in a crash like so: > > gcc -DHAVE_CONFIG_H -I. -I../../../swarm-2001-06-27/src/defobj -I../.. > -I../.. -I../../libobjc -I../../../swarm-2001-06-27/libobjc -I.. > -I../../../swarm-2001-06-27/src/defobj/.. > -I../../../swarm-2001-06-27/src/defobj/../collections > -I../../../swarm-2001-06-27/src/defobj/../misc -I//c/jdk1.3.1/include > -I//c/jdk1.3.1/include/win32 -I../../avcall -DBUILDING_SWARM -g -O2 > -Wall -Wno-import -Wno-protocol -Werror -Wno-unknown-pragmas > -Wno-unknown-pragmas -c -DDLL -DPIC > ../../../swarm-2001-06-27/src/defobj/Arguments.m -o .libs/Arguments.lo > In file included from /usr/include/w32api/winnt.h:144, > from /usr/include/w32api/windef.h:145, > from /usr/include/w32api/windows.h:98, > from > ../../../swarm-2001-06-27/src/defobj/Arguments.m:29: > /usr/include/w32api/basetsd.h:95: parse error before ',' token > > This file basetsd.h in current cygwin has the following at lines 94 and > 95: > > typedef __int64 LONG64, *PLONG64; > typedef __int64 INT64, *PINT64; > Followed by > typedef unsigned __int64 ULONG64, *PULONG64; > typedef unsigned __int64 DWORD64, *PDWORD64; > > If I comment lines 94-95, my programs compile, no trouble, and I stared > at your code a long time and started to think you would know how to fix > it, perhaps easily. I started to suspect there is some problem with the > typedef __int64 being used "bare", without a qualifier, such as "int" or > such. What do you think? > > Can you include my (pau...@uk...) in your cc line, because I'm not > a member of this list (yet) > > -- > Paul E. Johnson email: pau...@uk... > Dept. of Political Science http://lark.cc.ukans.edu/~pauljohn > University of Kansas Office: (785) 864-9086 > Lawrence, Kansas 66045 FAX: (785) 864-5700 > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ > > ----- End forwarded message ----- _________________________________________________________ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com |
From: <dan...@ya...> - 2001-08-07 21:07:12
|
--- Earnie Boyd <ear...@ya...> wrote: > Mumit or Danny, > > Is this just gcc-3.0 issues? > > Earnie. > Doesn't the #define __int64 long long in basetsd.h (added in CVS) fix this? > Christopher Faylor wrote: > > > > This is an old problem that I never saw any reaction to. > > > > Does anyone understand what the problem may be here? > > > > cgf > > > > ----- Forwarded message from Paul Johnson <pau...@uk...> > ----- > > > > From: Paul Johnson <pau...@uk...> > > To: cy...@cy... > > Subject: I believe this is a typo. > > Date: Tue, 03 Jul 2001 16:22:30 -0500 > > > > When I try to compile things with gcc 3.0 against <window.h>, the > build > > ends in a crash like so: > > > > gcc -DHAVE_CONFIG_H -I. -I../../../swarm-2001-06-27/src/defobj > -I../.. > > -I../.. -I../../libobjc -I../../../swarm-2001-06-27/libobjc -I.. > > -I../../../swarm-2001-06-27/src/defobj/.. > > -I../../../swarm-2001-06-27/src/defobj/../collections > > -I../../../swarm-2001-06-27/src/defobj/../misc > -I//c/jdk1.3.1/include > > -I//c/jdk1.3.1/include/win32 -I../../avcall -DBUILDING_SWARM -g -O2 > > -Wall -Wno-import -Wno-protocol -Werror -Wno-unknown-pragmas > > -Wno-unknown-pragmas -c -DDLL -DPIC > > ../../../swarm-2001-06-27/src/defobj/Arguments.m -o > .libs/Arguments.lo > > In file included from /usr/include/w32api/winnt.h:144, > > from /usr/include/w32api/windef.h:145, > > from /usr/include/w32api/windows.h:98, > > from > > ../../../swarm-2001-06-27/src/defobj/Arguments.m:29: > > /usr/include/w32api/basetsd.h:95: parse error before ',' token > > > > This file basetsd.h in current cygwin has the following at lines 94 > and > > 95: > > > > typedef __int64 LONG64, *PLONG64; > > typedef __int64 INT64, *PINT64; > > Followed by > > typedef unsigned __int64 ULONG64, *PULONG64; > > typedef unsigned __int64 DWORD64, *PDWORD64; > > > > If I comment lines 94-95, my programs compile, no trouble, and I > stared > > at your code a long time and started to think you would know how to > fix > > it, perhaps easily. I started to suspect there is some problem > with the > > typedef __int64 being used "bare", without a qualifier, such as > "int" or > > such. What do you think? > > > > Can you include my (pau...@uk...) in your cc line, because > I'm not > > a member of this list (yet) > > > > -- > > Paul E. Johnson email: pau...@uk... > > Dept. of Political Science > http://lark.cc.ukans.edu/~pauljohn > > University of Kansas Office: (785) 864-9086 > > Lawrence, Kansas 66045 FAX: (785) 864-5700 > > > > -- > > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > > Bug reporting: http://cygwin.com/bugs.html > > Documentation: http://cygwin.com/docs.html > > FAQ: http://cygwin.com/faq/ > > > > ----- End forwarded message ----- > > _________________________________________________________ > Do You Yahoo!? > Get your free @yahoo.com address at http://mail.yahoo.com > > > _______________________________________________ > MinGW-dvlpr mailing list > Min...@li... > http://lists.sourceforge.net/lists/listinfo/mingw-dvlpr _____________________________________________________________________________ http://messenger.yahoo.com.au - Yahoo! Messenger - Voice chat, mail alerts, stock quotes and favourite news and lots more! |
From: Earnie B. <ear...@ya...> - 2002-05-06 11:10:09
|
Let's keep these questions to the mingw-dvlpr list please. Prof Abimbola Olowofoyeku wrote: > On 5 May 2002 at 7:50, Earnie Boyd wrote: > > > You now have a right to upload your mingw gpc package. I just ask that > > you --prefix=/mingw, have a package name of > > package-version-mingw-sv.tar.gz for binary releasee and > > package-version-src-sv.tar.gz for the source release (sv is the > > subversion number, e.g. 1). Your release should be a release under the > > mingw-contrib package, the release name should simply be gpc. > > What about upload instructions? > ftp upload.sf.net user: anonymous password: cd incoming binary put package-version-mingw-1.tar.gz put package-version-src-1.tar.gz quit http://sf.net/my user: password: Choose the MinGW site. select Admin select Edit/Add File Releases Find the mingw-contrib release on that page select Edit Release to the left of the mingw-contrib release Find the GPC release and select Edit This Release Follow the instructoins on that page. Let me know when your done. > > Also, I presume that the source package should be the pristine GPC > sources, and that there is no need to include the "os-hacks" stuff > (most of which have to be in the system directories anyway). Right? This is what I want. > Or > should I release the "os-hacks" stuff separately? It is already > available on the GPC web site. Thanks. > You can include a differences file between the pristine package and your hack, however, it's not necessary. Earnie. |
From: Paul G. <pga...@at...> - 2002-09-10 01:30:49
|
I "think" it could eliminate a configuration/make step if we did. As it stands, at least with the packages I've been porting lately, it is pretty much required that (de facto) there be an easy, compiler/runtime bound reference to Windows or some such (win32, windows, winnt, etc.). Typically it has been _WIN32 which is used the most with the particular packages I am currently porting. If there is not such a predefine, then the configuration (configure/make) needs to determine, by reading environment variable stuff, whether it is using Windows based OS (9x, NT, 2k, xp) or not. Putting a WINDOWS32 in the list of predefined macros can only facilitate a more efficient and effective means of determining what the configure/make is actually supposed to be building for and how that build is to be completed. Paul G. > On 9 Sep 2002 at 14:15, Earnie Boyd wrote: > > Should we add WINDOWS32 to the list of predefined macros for RMS' sake? > > Earnie. > |
From: Paul G. <pga...@at...> - 2002-09-10 01:31:43
|
I agree. On 9 Sep 2002 at 22:42, Danny Smith wrote: ----- Original Message ----- From: "Earnie Boyd" <ear...@ya...> To: <min...@li...> Sent: Monday, 9 September 2002 19:15 Subject: [MinGW-dvlpr] [Fwd: Make configuration for Win32.] > Should we add WINDOWS32 to the list of predefined macros for RMS' sake? > > Earnie. I would prefer system-reserved __WINDOWS32__ or __WINDOWS32. Danny ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 _______________________________________________ MinGW-dvlpr mailing list Min...@li... https://lists.sourceforge.net/lists/listinfo/mingw-dvlpr |