Re: w32api header problems
Hi! Wednesday, 09 January, 2002 Jean le Roux [EMAIL PROTECTED] wrote: JlR> On Wed, Jan 09, 2002 at 04:47:18PM +0300, egor duda wrote: >> JlR> I've done this but seems to leave my code in a tangle :) >> JlR> I suddenly have parse errors in my own header files, on normal >> JlR> function declerations. I can only deduce that windows.h is leaving an >> JlR> open ifdef or has unterminated strings or something silly. >> >> it's easy to find out what the reason is. gcc has a very useful option >> '--save-temps'. it instructs preprocessor, compiler and assembler to >> leave their temporary files in place, so if you compiling, say, zzz.c, >> you'll get zzz.i (output of preprocessor), zzz.s (assembly source -- >> output of compiler) and zzz.o (compiled binary object). You want to >> look into zzz.i it shows what your source file turns into, and it's >> almost always easy to see why. JlR> Fair enough.. but how do i turn it on with autotools.. configure does JlR> not seem to support such a flag. 1st way: redirect make output to file, cut'n'paste the failed command. then add the option and run resulting command. 2nd way: edit Makefile to add this option in the appropriate place (usually, CFLAGS or CXXFLAGS) then run 'make zzz.o' Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
Re: w32api header problems
On Wed, Jan 09, 2002 at 04:47:18PM +0300, egor duda wrote: ... > JlR> I've done this but seems to leave my code in a tangle :) > JlR> I suddenly have parse errors in my own header files, on normal > JlR> function declerations. I can only deduce that windows.h is leaving an > JlR> open ifdef or has unterminated strings or something silly. > > it's easy to find out what the reason is. gcc has a very useful option > '--save-temps'. it instructs preprocessor, compiler and assembler to > leave their temporary files in place, so if you compiling, say, zzz.c, > you'll get zzz.i (output of preprocessor), zzz.s (assembly source -- > output of compiler) and zzz.o (compiled binary object). You want to > look into zzz.i it shows what your source file turns into, and it's > almost always easy to see why. Fair enough.. but how do i turn it on with autotools.. configure does not seem to support such a flag. -- Jean le Roux Binary Entropy Catalyst Cellular: 083 505 6443 A sad spectacle. If they be inhabited, what a scope for misery and folly. If they be not inhabited, what a waste of space. -- Thomas Carlyle, looking at the stars -- 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/
Re: w32api header problems
Hi! Wednesday, 09 January, 2002 Jean le Roux [EMAIL PROTECTED] wrote: JlR> On Wed, Jan 09, 2002 at 01:07:47PM +0300, egor duda wrote: >> Hi! >> >> Wednesday, 09 January, 2002 Jean le Roux [EMAIL PROTECTED] wrote: >> >> JlR> I need to include /usr/include/w32api/winbase.h in order to use the >> JlR> GetVolumeInformation(...) system call under windows. >> >> JlR> However, as i metioned in an earlier mail, DWORD seems to not be >> JlR> defined. I tracked DWORD's definition down to windef.h.. but it seems >> JlR> the whole include chain is a bit funny.. there are lots of >> JlR> inter-dependencies which are not satisfied. >> >> JlR> Does anyone have any words of wisdom to make life a little easier, or >> JlR> do I simply have to test for, and include, all the headers in w32api ? >> >> you ought to >> >> #include >> JlR> I've done this but seems to leave my code in a tangle :) JlR> I suddenly have parse errors in my own header files, on normal JlR> function declerations. I can only deduce that windows.h is leaving an JlR> open ifdef or has unterminated strings or something silly. it's easy to find out what the reason is. gcc has a very useful option '--save-temps'. it instructs preprocessor, compiler and assembler to leave their temporary files in place, so if you compiling, say, zzz.c, you'll get zzz.i (output of preprocessor), zzz.s (assembly source -- output of compiler) and zzz.o (compiled binary object). You want to look into zzz.i it shows what your source file turns into, and it's almost always easy to see why. Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
RE: w32api header problems
Jean le Roux writes: >... >//this is where i include the header that make life hard :) > >#ifdef HAVE_WINDOWS_H >#include >#endif > >... > >//this is where the errors occur. >/*other*/ #ifndef max // or #ifndef _WIN32 >int max(const int value_a, const int value_b); //line 283 >int min(const int value_a, const int value_b); //line 284 #endif Norman -- 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/
Re: w32api header problems
Hi > To fix the min and max, define the following before including windows.h: > #define NOMINMAX added that... waiting for compile to complete (Working on a VM... takes forever :) and tada! It's happy and so am I! It still warns me about undefined symbols: make all-recursive make[1]: Entering directory /cygdrive/e/projects/multicast/pmfp' Making all in libsrc make[2]: Entering directory /cygdrive/e/projects/multicast/pmfp/libsrc' >>> /bin/sh ../libtool --mode=link c++ -g -O2 -o libpmfp.la -rpath /usr/local/lib --no-undefined libtool: link: warning: undefined symbols not allowed in i686-pc-cygwin shared libraries <<< rm -fr .libs/libpmfp.la .libs/libpmfp.* .libs/libpmfp.* ar cru .libs/libpmfp.a common.o pmfp.o pmfp_log.o crypto.o mckey.o ranlib .libs/libpmfp.a creating libpmfp.la (cd .libs && rm -f libpmfp.la && ln -s ../libpmfp.la libpmfp.la) [ -e .libs ] && cp -f .libs/libpmfp.so.0.0.0 ./libpmfp.so cp: cannot stat .libs/libpmfp.so.0.0.0': No such file or directory make[2]: *** [all] Error 1 make[2]: Leaving directory /cygdrive/e/projects/multicast/pmfp/libsrc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory /cygdrive/e/projects/multicast/pmfp' make: *** [all-recursive-am] Error 2 > > string itoa(const int value, const short fix=0); //line 285 > Have you included ? Yip... This whole thing works perfectly if I take out the #include bye -- 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/
RE: w32api header problems
> -Original Message- > From: Jean le Roux [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, January 09, 2002 1:38 PM > To: [EMAIL PROTECTED] > Subject: Re: w32api header problems > > > > int max(const int value_a, const int value_b); //line 283 > > int min(const int value_a, const int value_b); //line 284 > > string itoa(const int value, const short fix=0); //line 285 > ... > > > common.h:284: parse error before `const' > > common.h:285: parse error before `const' > > > Woops.. those line numbers are 1 out .. > > > int max(const int value_a, const int value_b); //line 283 > > should be 284 > > Appologies to all. #undef'ing min and max before declaring them is something I've been used to do due to several environments insisting to "#define min(a, b) ((a) < (b) ? (a) : (b))" and the like for max, instead of th ecustomary MIN and MAX names... :-) HTH Bernard Bernard Dautrevaux Microprocess Ingenierie 97 bis, rue de Colombes 92400 COURBEVOIE FRANCE Tel:+33 (0) 1 47 68 80 80 Fax:+33 (0) 1 47 88 97 85 e-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] -- 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/
Re: w32api header problems
Jean le Roux wrote: > On Wed, Jan 09, 2002 at 12:40:02PM +0100, Pavel Tsekov wrote: > >>Jean le Roux wrote: >> >> >>>On Wed, Jan 09, 2002 at 01:07:47PM +0300, egor duda wrote: >>> >>> Hi! Wednesday, 09 January, 2002 Jean le Roux [EMAIL PROTECTED] wrote: JlR> I need to include /usr/include/w32api/winbase.h in order to use the JlR> GetVolumeInformation(...) system call under windows. JlR> However, as i metioned in an earlier mail, DWORD seems to not be JlR> defined. I tracked DWORD's definition down to windef.h.. but it seems JlR> the whole include chain is a bit funny.. there are lots of JlR> inter-dependencies which are not satisfied. JlR> Does anyone have any words of wisdom to make life a little easier, or JlR> do I simply have to test for, and include, all the headers in w32api ? you ought to #include >>>I've done this but seems to leave my code in a tangle :) >>>I suddenly have parse errors in my own header files, on normal >>>function declerations. I can only deduce that windows.h is leaving an >>>open ifdef or has unterminated strings or something silly. >>> >>>Anybody encounter this before? Any suggestions ? >>>I can put the compiler output online if someone wants to take a look, >>>and ofcourse some code snippets. >>> >> >>It would be helpful :) >> > > Here it is: first the relevant snip from my header file (common.h), and then the > compilers pain. > > [common.h] > ... > //this is where i include the header that make life hard :) > > #ifdef HAVE_WINDOWS_H > #include > #endif > > ... > > //this is where the errors occur. > /*other*/ > intmax(const int value_a, const int value_b); //line 283 > intmin(const int value_a, const int value_b); //line 284 To fix the min and max, define the following before including windows.h: #define NOMINMAX > string itoa(const int value, const short fix=0); //line 285 > Have you included ? > ... > > [compiler output] > cd . \ > && CONFIG_FILES= CONFIG_HEADERS=config.h \ > /bin/sh ./config.status > creating config.h > config.h is unchanged > make all-recursive > make[1]: Entering directory `/cygdrive/e/projects/multicast/pmfp' > Making all in libsrc > make[2]: Entering directory `/cygdrive/e/projects/multicast/pmfp/libsrc' > /bin/sh ../libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -c >common.cc > rm -f .libs/common.lo > c++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wp,-MD,.deps/common.pp -c common.cc -DPIC >-o .libs/common.lo > In file included from common.cc:5: > common.h:284: parse error before `const' > common.h:285: parse error before `const' > common.cc:524: parse error before `const' > common.cc:529: parse error before `const' > make[2]: *** [common.lo] Error 1 > make[2]: Leaving directory `/cygdrive/e/projects/multicast/pmfp/libsrc' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/cygdrive/e/projects/multicast/pmfp' > make: *** [all-recursive-am] Error 2 -- 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/
Re: w32api header problems
> intmax(const int value_a, const int value_b); //line 283 > intmin(const int value_a, const int value_b); //line 284 > string itoa(const int value, const short fix=0); //line 285 ... > common.h:284: parse error before `const' > common.h:285: parse error before `const' Woops.. those line numbers are 1 out .. > int max(const int value_a, const int value_b); //line 283 should be 284 Appologies to all. -- 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/
Re: w32api header problems
On Wed, Jan 09, 2002 at 12:40:02PM +0100, Pavel Tsekov wrote: > Jean le Roux wrote: > > > On Wed, Jan 09, 2002 at 01:07:47PM +0300, egor duda wrote: > > > >>Hi! > >> > >>Wednesday, 09 January, 2002 Jean le Roux [EMAIL PROTECTED] wrote: > >> > >>JlR> I need to include /usr/include/w32api/winbase.h in order to use the > >>JlR> GetVolumeInformation(...) system call under windows. > >> > >>JlR> However, as i metioned in an earlier mail, DWORD seems to not be > >>JlR> defined. I tracked DWORD's definition down to windef.h.. but it seems > >>JlR> the whole include chain is a bit funny.. there are lots of > >>JlR> inter-dependencies which are not satisfied. > >> > >>JlR> Does anyone have any words of wisdom to make life a little easier, or > >>JlR> do I simply have to test for, and include, all the headers in w32api ? > >> > >>you ought to > >> > >>#include > >> > > > > I've done this but seems to leave my code in a tangle :) > > I suddenly have parse errors in my own header files, on normal > > function declerations. I can only deduce that windows.h is leaving an > > open ifdef or has unterminated strings or something silly. > > > > Anybody encounter this before? Any suggestions ? > > I can put the compiler output online if someone wants to take a look, > > and ofcourse some code snippets. > > > It would be helpful :) Here it is: first the relevant snip from my header file (common.h), and then the compilers pain. [common.h] ... //this is where i include the header that make life hard :) #ifdef HAVE_WINDOWS_H #include #endif ... //this is where the errors occur. /*other*/ int max(const int value_a, const int value_b); //line 283 int min(const int value_a, const int value_b); //line 284 string itoa(const int value, const short fix=0); //line 285 ... [compiler output] cd . \ && CONFIG_FILES= CONFIG_HEADERS=config.h \ /bin/sh ./config.status creating config.h config.h is unchanged make all-recursive make[1]: Entering directory `/cygdrive/e/projects/multicast/pmfp' Making all in libsrc make[2]: Entering directory `/cygdrive/e/projects/multicast/pmfp/libsrc' /bin/sh ../libtool --mode=compile c++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -c common.cc rm -f .libs/common.lo c++ -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -Wp,-MD,.deps/common.pp -c common.cc -DPIC -o .libs/common.lo In file included from common.cc:5: common.h:284: parse error before `const' common.h:285: parse error before `const' common.cc:524: parse error before `const' common.cc:529: parse error before `const' make[2]: *** [common.lo] Error 1 make[2]: Leaving directory `/cygdrive/e/projects/multicast/pmfp/libsrc' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/cygdrive/e/projects/multicast/pmfp' make: *** [all-recursive-am] Error 2 Hope this sheds some light. -- 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/
Re: w32api header problems
Jean le Roux wrote: > On Wed, Jan 09, 2002 at 01:07:47PM +0300, egor duda wrote: > >>Hi! >> >>Wednesday, 09 January, 2002 Jean le Roux [EMAIL PROTECTED] wrote: >> >>JlR> I need to include /usr/include/w32api/winbase.h in order to use the >>JlR> GetVolumeInformation(...) system call under windows. >> >>JlR> However, as i metioned in an earlier mail, DWORD seems to not be >>JlR> defined. I tracked DWORD's definition down to windef.h.. but it seems >>JlR> the whole include chain is a bit funny.. there are lots of >>JlR> inter-dependencies which are not satisfied. >> >>JlR> Does anyone have any words of wisdom to make life a little easier, or >>JlR> do I simply have to test for, and include, all the headers in w32api ? >> >>you ought to >> >>#include >> > > I've done this but seems to leave my code in a tangle :) > I suddenly have parse errors in my own header files, on normal > function declerations. I can only deduce that windows.h is leaving an > open ifdef or has unterminated strings or something silly. > > Anybody encounter this before? Any suggestions ? > I can put the compiler output online if someone wants to take a look, > and ofcourse some code snippets. It would be helpful :) -- 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/
Re: w32api header problems
On Wed, Jan 09, 2002 at 01:07:47PM +0300, egor duda wrote: > Hi! > > Wednesday, 09 January, 2002 Jean le Roux [EMAIL PROTECTED] wrote: > > JlR> I need to include /usr/include/w32api/winbase.h in order to use the > JlR> GetVolumeInformation(...) system call under windows. > > JlR> However, as i metioned in an earlier mail, DWORD seems to not be > JlR> defined. I tracked DWORD's definition down to windef.h.. but it seems > JlR> the whole include chain is a bit funny.. there are lots of > JlR> inter-dependencies which are not satisfied. > > JlR> Does anyone have any words of wisdom to make life a little easier, or > JlR> do I simply have to test for, and include, all the headers in w32api ? > > you ought to > > #include > I've done this but seems to leave my code in a tangle :) I suddenly have parse errors in my own header files, on normal function declerations. I can only deduce that windows.h is leaving an open ifdef or has unterminated strings or something silly. Anybody encounter this before? Any suggestions ? I can put the compiler output online if someone wants to take a look, and ofcourse some code snippets. bye -- Jean le Roux -- 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/
Re: w32api header problems
Hi! Wednesday, 09 January, 2002 Jean le Roux [EMAIL PROTECTED] wrote: JlR> I need to include /usr/include/w32api/winbase.h in order to use the JlR> GetVolumeInformation(...) system call under windows. JlR> However, as i metioned in an earlier mail, DWORD seems to not be JlR> defined. I tracked DWORD's definition down to windef.h.. but it seems JlR> the whole include chain is a bit funny.. there are lots of JlR> inter-dependencies which are not satisfied. JlR> Does anyone have any words of wisdom to make life a little easier, or JlR> do I simply have to test for, and include, all the headers in w32api ? you ought to #include Egor.mailto:[EMAIL PROTECTED] ICQ 5165414 FidoNet 2:5020/496.19 -- 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/
w32api header problems
Hi guys I need to include /usr/include/w32api/winbase.h in order to use the GetVolumeInformation(...) system call under windows. However, as i metioned in an earlier mail, DWORD seems to not be defined. I tracked DWORD's definition down to windef.h.. but it seems the whole include chain is a bit funny.. there are lots of inter-dependencies which are not satisfied. Does anyone have any words of wisdom to make life a little easier, or do I simply have to test for, and include, all the headers in w32api ? Thanx. -- Jean le Roux Binary Entropy Catalyst Cellular: 083 505 6443 What UNIVERSE is this, please?? -- 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/
