From: Max G. <max...@we...> - 2002-05-19 20:54:35
|
Hello, I'm new to this list and have not got that much experience with Mingw either, although I have been playing around with it for some time. Recently I decided to try out the new 3.1 GCC beta for Mingw. As far as I can tell, it works well, but I experience a problem if I try to include as well the <list>-header from the C++ standard library as the header of Allegro, a C-library for gfx and such that I like to use. I get the following error: In file included from c:/prog/mingw/include/windows.h:111, from c:/prog/mingw/include/g++-v3/mingw32/bits/gthr-default.h:342, from c:/prog/mingw/include/g++-v3/mingw32/bits/gthr.h:98, from c:/prog/mingw/include/g++-v3/mingw32/bits/c++io.h:37, from c:/prog/mingw/include/g++-v3/bits/fpos.h:44, from c:/prog/mingw/include/g++-v3/iosfwd:46, from c:/prog/mingw/include/g++-v3/bits/stl_algobase.h:70, from c:/prog/mingw/include/g++-v3/list:67, from input.h:6, from input.cpp:3: c:/prog/mingw/include/wingdi.h:1183: conflicting types for `typedef struct tagBITMAP BITMAP' c:/prog/mingw/include/allegro/gfx.h:234: previous declaration as `typedef struct BITMAP BITMAP' Normal Termination Output completed (1 sec consumed). [input.cpp and .h are part of my project] It looks as if with the header for the standard lib container, I am forced to include a lot of win32 api stuff. Unfortunately, this prevents me from using Allegro and many other libraries in the same file, because the win32 api includes a lot of identifiers that are also used there. Apparently, the inclusion of that particular header is related to threading. Since you normally would not expect to be forced to deal with the windows api if you just use the STL, I would like to know if this problem is going to stay or if it could perhaps be avoided to include that windows.h in headers meant for everybody's usage. IIRC the problem did not occur in GCC 2.95.3-6. Furthermore I would appreciate if anybody could give me a hint how to work around the problem. TIA for your help. -- Max Gerlach ________________________________________________________________ Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13 |
From: <dan...@ya...> - 2002-05-19 21:18:34
|
--- Max Gerlach <max...@we...> wrote: > Hello, > > > I get the following error: > > > > In file included from c:/prog/mingw/include/windows.h:111, > from > c:/prog/mingw/include/g++-v3/mingw32/bits/gthr-default.h:342, > from > c:/prog/mingw/include/g++-v3/mingw32/bits/gthr.h:98, > from > c:/prog/mingw/include/g++-v3/mingw32/bits/c++io.h:37, > from c:/prog/mingw/include/g++-v3/bits/fpos.h:44, > from c:/prog/mingw/include/g++-v3/iosfwd:46, > from > c:/prog/mingw/include/g++-v3/bits/stl_algobase.h:70, > from c:/prog/mingw/include/g++-v3/list:67, > from input.h:6, > from input.cpp:3: > c:/prog/mingw/include/wingdi.h:1183: conflicting types for `typedef > struct > tagBITMAP BITMAP' > c:/prog/mingw/include/allegro/gfx.h:234: previous declaration as > `typedef > struct BITMAP BITMAP' > Normal Termination > Output completed (1 sec consumed). > > > [input.cpp and .h are part of my project] > > > It looks as if with the header for the standard lib container, I am > forced to include a lot of win32 api stuff. Unfortunately, this > prevents me from using Allegro and many other libraries in the same > file, because the win32 api includes a lot of identifiers that are > also used there. > > Apparently, the inclusion of that particular header is related to > threading. This is a known problem. I have tried to reduce the pollution a bit by this, in gthr-default.h, to only include necessary headers #if defined __MINGW32__ || defined __CYGWIN__ #include <w32api.h> #if ((__W32API_MAJOR_VERSION * 1000) \ + ( __W32API_MINOR_VERSION )) > 1003 #include <stdarg.h> #include <windef.h> #include <winbase.h> #ifdef __cplusplus extern "C" #endif DWORD WINAPI GetLastError(void); /* from winuser.h */ #else /* __W32API */ #include <windows.h> #endif /* __W32API */ #else #include <windows.h> #endif /* __MINGW32__ || __CYGWIN__ */ With a corresponding patch in windows.h and windef.h (in CVS w32api) to let that minimal inclusion of w32api headers work. You can get the CVS versions of windows.h and windef.h or wait for a new release of w32api. Danny http://briefcase.yahoo.com.au - Yahoo! Briefcase - Save your important files online for easy access! |
From: Earnie B. <ear...@ya...> - 2002-05-20 11:48:44
|
Danny Smith wrote: > > > With a corresponding patch in windows.h and windef.h (in CVS w32api) > to let that minimal inclusion of w32api headers work. > > You can get the CVS versions of windows.h and windef.h or wait for a > new release of w32api. > I see that it's time to publish 1.4. I'll try and get that out today. Earnie. |
From: Mumit K. <kh...@na...> - 2002-05-24 04:04:52
|
On Mon, 20 May 2002, Danny Smith wrote: > This is a known problem. I have tried to reduce the pollution a bit by > this, in gthr-default.h, to only include necessary headers > > #if defined __MINGW32__ || defined __CYGWIN__ > #include <w32api.h> > #if ((__W32API_MAJOR_VERSION * 1000) \ > + ( __W32API_MINOR_VERSION )) > 1003 > #include <stdarg.h> > #include <windef.h> > #include <winbase.h> > #ifdef __cplusplus > extern "C" > #endif > DWORD WINAPI GetLastError(void); /* from winuser.h */ > #else /* __W32API */ > #include <windows.h> > #endif /* __W32API */ > #else > #include <windows.h> > #endif /* __MINGW32__ || __CYGWIN__ */ > > With a corresponding patch in windows.h and windef.h (in CVS w32api) > to let that minimal inclusion of w32api headers work. This is a good start, however it still causes compilation failures in many C++ codes due to namespace pollution, and it's especially worrisome for codes that have no Windows API dependence. When I first worked on the gthr-win32 header, it was not designed to be user visible (and it wasn't, since it was only used by libgcc2), but all that's changed now with the libstdc++-v3. Long term solution may be to write up a set of interfaces that go into mingw runtime (stubs in libmingw32.a, and implementations in the thread helper library/DLL), and use those interfaces in gthr-win32.h so that user C++ code is not polluted by Windows API. Regards, Mumit |
From: <dan...@ya...> - 2002-05-24 04:17:22
|
--- Mumit Khan <kh...@na...> wrote: > On Mon, 20 May 2002, Danny Smith wrote: > > > This is a known problem. I have tried to reduce the pollution a bit by > > this, in gthr-default.h, to only include necessary headers > > > > #if defined __MINGW32__ || defined __CYGWIN__ > > #include <w32api.h> > > #if ((__W32API_MAJOR_VERSION * 1000) \ > > + ( __W32API_MINOR_VERSION )) > 1003 > > #include <stdarg.h> > > #include <windef.h> > > #include <winbase.h> > > #ifdef __cplusplus > > extern "C" > > #endif > > DWORD WINAPI GetLastError(void); /* from winuser.h */ > > #else /* __W32API */ > > #include <windows.h> > > #endif /* __W32API */ > > #else > > #include <windows.h> > > #endif /* __MINGW32__ || __CYGWIN__ */ > > > > With a corresponding patch in windows.h and windef.h (in CVS w32api) > > to let that minimal inclusion of w32api headers work. > > This is a good start, however it still causes compilation failures in many > C++ codes due to namespace pollution, and it's especially worrisome for > codes that have no Windows API dependence. When I first worked on the > gthr-win32 header, it was not designed to be user visible (and it wasn't, > since it was only used by libgcc2), but all that's changed now with the > libstdc++-v3. > > Long term solution may be to write up a set of interfaces that go into > mingw runtime (stubs in libmingw32.a, and implementations in the thread > helper library/DLL), and use those interfaces in gthr-win32.h so that > user C++ code is not polluted by Windows API. > Yes, I've started on that. Actually its fairly simple, but does require users to update mingw runtime. It would be nice to have those stubs in libsupc++.a so that they can be kept in sync with gthr-win32.h. Danny > Regards, > Mumit > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://briefcase.yahoo.com.au - Yahoo! Briefcase - Save your important files online for easy access! |
From: Mumit K. <kh...@na...> - 2002-05-24 04:23:17
|
On Fri, 24 May 2002, Danny Smith wrote: > Yes, I've started on that. Actually its fairly simple, but does require users > to update mingw runtime. It would be nice to have those stubs in libsupc++.a > so that they can be kept in sync with gthr-win32.h. I should've guessed that you're well on your way there! I must say that you, Earnie and others (my apologies for not naming names -- I've lived in a different world too long to know the newer co-maintainers, if any) have been running an incredible show, you should be proud of it. Regards, Mumit |
From: <dan...@ya...> - 2002-05-24 08:22:41
|
--- Mumit Khan <kh...@na...> wrote: > On Fri, 24 May 2002, Danny Smith wrote: > > > Yes, I've started on that. Actually its fairly simple, but does require > users > > to update mingw runtime. It would be nice to have those stubs in > libsupc++.a > > so that they can be kept in sync with gthr-win32.h. > > I should've guessed that you're well on your way there! I must say that > you, Earnie and others (my apologies for not naming names -- I've lived > in a different world too long to know the newer co-maintainers, if any) > have been running an incredible show, you should be proud of it. > As always, we stand on the shoulders of giants. Good to here from you. Did you ever think it would get this big? In the end, I think libgcc.a is the place for the stubs. That will make avail to other languages as well. Also the configure machinery is in place for that by simply defining LIB2FUNCS_EXTRA = $(srcdir)/config/i386/gthr-win32.c in config/i386/t-mingw32 and putting the stub src file in that directory. I've bootstrapped 3.1 with that and doing the testsuite now. Feel free to.... Danny > Regards, > Mumit > > > > _______________________________________________________________ > > Don't miss the 2002 Sprint PCS Application Developer's Conference > August 25-28 in Las Vegas -- http://devcon.sprintpcs.com/adp/index.cfm > > _______________________________________________ > MinGW-users mailing list > Min...@li... > > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users http://briefcase.yahoo.com.au - Yahoo! Briefcase - Save your important files online for easy access! |
From: Mumit K. <kh...@na...> - 2002-05-24 23:27:55
|
On Fri, 24 May 2002, Danny Smith wrote: > Did you ever think it would get this big? Nope, not even close. > In the end, I think libgcc.a is the place for the stubs. That will make avail > to other languages as well. Also the configure machinery is in place for that > by simply defining > LIB2FUNCS_EXTRA = $(srcdir)/config/i386/gthr-win32.c > in config/i386/t-mingw32 > and putting the stub src file in that directory. Perhaps also needed for Cygwin, since --enable-threads still defaults to win32 instead of posix, which is what it should default to IMO now that Cygwin pthreads implementation is definitely more than sufficient. > I've bootstrapped 3.1 with that and doing the testsuite now. Thanks! This solves a major problem. Regards, Mumit |