From: <JSO...@ao...> - 2001-07-02 20:44:53
|
I am trying to compile a program that uses a third-party library. This library utizilizes __int64, yet when I try to compile in C++ with nothing but iostream and the 3rd party header included, I get a parse error from using __int64. If I include _mingw.h, problem leaves. Yet, when I look through all the iostream includes, _mingw.h is included in the file stdarg.h, which is included from several files if _G_NEED_STDARG_H is defined. Do I need to include _mingw.h manually, or define _G_NEED_STDARG_H myself, and if so, why? If neither of these is the correct solution, what is? Using GCC-2.95.2 release. --Jason Craig |
From: Mikael A. <mik...@ma...> - 2001-07-03 08:15:09
|
Use long long instead. Mikael ----- Original Message -----=20 From: JSO...@ao...=20 To: min...@li...=20 Sent: Monday, July 02, 2001 9:44 PM Subject: [Mingw-users] __int64 in c++? I am trying to compile a program that uses a third-party library. = This=20 library utizilizes __int64, yet when I try to compile in C++ with = nothing but=20 iostream and the 3rd party header included, I get a parse error from = using=20 __int64. If I include _mingw.h, problem leaves. Yet, when I look = through=20 all the iostream includes, _mingw.h is included in the file stdarg.h, = which=20 is included from several files if _G_NEED_STDARG_H is defined. Do I = need to=20 include _mingw.h manually, or define _G_NEED_STDARG_H myself, and if = so, why?=20 If neither of these is the correct solution, what is?=20 Using GCC-2.95.2 release.=20 --Jason Craig=20 |
From: Mumit K. <khan@NanoTech.Wisc.EDU> - 2001-07-03 13:21:54
|
On Mon, 2 Jul 2001 JSO...@ao... wrote: > I am trying to compile a program that uses a third-party library. This > library utizilizes __int64, yet when I try to compile in C++ with nothing but > iostream and the 3rd party header included, I get a parse error from using > __int64. If I include _mingw.h, problem leaves. Yet, when I look through > all the iostream includes, _mingw.h is included in the file stdarg.h, which > is included from several files if _G_NEED_STDARG_H is defined. Do I need to > include _mingw.h manually, or define _G_NEED_STDARG_H myself, and if so, why? > If neither of these is the correct solution, what is? > My preferred solutions are to use either of the following: (1) typedef before use by any other 3rd party includes. #if defined(_WIN32) && defined(__GNUC__) typedef long long __int64; #endif #include <all_3rd_party_includes_here> (2) Create a "port" header and include that before all other includes with the -imacros or -include switch. $ gcc -imacros port.h -c foo.cc $ cat port.h #define __int64 long long $ GCC will include the file "port.h" before the other files are processed. If you use -imacros, then file can only have cpp macros; if you use -include, it can have C/C++ constructs as well. See GCC manual for details. The _mingw.h file is not meant to be user visible. Ideally, it should be included in all Mingw supplied files, but since iostream comes from a different source, we can never guarantee that it will include a file that will in turn include _mingw.h. Cost of doing business, sorry. One of the reasons we don't use -imacros/-include to automagically include _mingw.h by defaults is that either switch requires full or relative pathname, and won't look it up using the normal include path lookup algorithm. Regards, Mumit |
From: Paul G. <pga...@qw...> - 2001-07-03 21:37:00
|
On 3 Jul 2001, at 8:21, the Illustrious Mumit Khan wrote: > On Mon, 2 Jul 2001 JSO...@ao... wrote: > > > I am trying to compile a program that uses a third-party library. > > This library utizilizes __int64, yet when I try to compile in C++ with > > nothing but iostream and the 3rd party header included, I get a parse > > error from using __int64. If I include _mingw.h, problem leaves. > > Yet, when I look through all the iostream includes, _mingw.h is > > included in the file stdarg.h, which is included from several files if > > _G_NEED_STDARG_H is defined. Do I need to include _mingw.h manually, > > or define _G_NEED_STDARG_H myself, and if so, why? > > If neither of these is the correct solution, what is? > > > > My preferred solutions are to use either of the following: > > (1) typedef before use by any other 3rd party includes. > > #if defined(_WIN32) && defined(__GNUC__) > typedef long long __int64; > #endif > > #include <all_3rd_party_includes_here> > > (2) Create a "port" header and include that before all other includes > with the -imacros or -include switch. > > $ gcc -imacros port.h -c foo.cc > $ cat port.h > #define __int64 long long > $ > > GCC will include the file "port.h" before the other files are processed. > If you use -imacros, then file can only have cpp macros; if you use > -include, it can have C/C++ constructs as well. See GCC manual for > details. > > The _mingw.h file is not meant to be user visible. Ideally, it should be > included in all Mingw supplied files, but since iostream comes from a > different source, we can never guarantee that it will include a file > that will in turn include _mingw.h. Cost of doing business, sorry. > > One of the reasons we don't use -imacros/-include to automagically > include _mingw.h by defaults is that either switch requires full or > relative pathname, and won't look it up using the normal include path > lookup algorithm. Just out of curiosity, where is this algorithm located? Peace, Paul G. |
From: Mumit K. <khan@NanoTech.Wisc.EDU> - 2001-07-03 21:48:22
|
On Tue, 3 Jul 2001, Paul Garceau wrote: > > > > One of the reasons we don't use -imacros/-include to automagically > > include _mingw.h by defaults is that either switch requires full or > > relative pathname, and won't look it up using the normal include path > > lookup algorithm. > > Just out of curiosity, where is this algorithm located? > [ please trim when quoting ] The include path is controlled by the following: 1. -I switch supplied by the user. Highest priority. 2. Environment variables -- C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, and OBJC_INCLUDE_PATH, for 3 different languages, 3. Built in search path. This one first looks at paths that are configured in compile time (eg., /usr/include on most Unix boxes), and then relative pathname lookup given its current installation directory. If Mingw gcc is installed in c:/gcc-2.95.2/bin/gcc.exe, then it will also look in c:/gcc-2.95.2/i386-mingw32/include for example. Just use the -v option when compiling a file and you'll see where all it searches. Regards, Mumit |
From: <dan...@ya...> - 2001-07-04 00:26:59
|
--- Mumit Khan <khan@NanoTech.Wisc.EDU> wrote: > On Tue, 3 Jul 2001, Paul Garceau wrote: > > > [ please trim when quoting ] > > The include path is controlled by the following: > > 1. -I switch supplied by the user. Highest priority. > 2. Environment variables -- C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, > and OBJC_INCLUDE_PATH, for 3 different languages, > 3. Built in search path. This one first looks at paths that are > configured in compile time (eg., /usr/include on most Unix boxes), > and then relative pathname lookup given its current installation > directory. If Mingw gcc is installed in c:/gcc-2.95.2/bin/gcc.exe, > > then it will also look in c:/gcc-2.95.2/i386-mingw32/include for > example. > > Just use the -v option when compiling a file and you'll see where all > it searches. > That's how I thought it's supposed to work too. However, the C_INCLUDE_PATH and friends are actually searched *after* the built in path. CPATH works as I expected it to Recent GCC 2.95.3 gives same result. $ set C_INCLUDE_PATH=d:\usr\local\include $ set CPATH=d:\usr\include $ touch test.c $ gcc -I. -v -c test.c Reading specs from d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\specs gcc version 2.95.2 19991024 (release) d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\cpp.exe -lang-c -v -I. -iprefix d:\mingw-2.95.2\bin\..\lib/gcc-lib/i386-mingw32msvc\2.95.2\ -D__GNUC__=2 -D__GNUC_MINOR__=95 -Di386 -D_WIN32 -DWIN32 -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -DWINNT -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D_stdcall=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386__ -D_WIN32 -D__WIN32__ -D__WIN32__ -D__MINGW32__=0.2 -D__MSVCRT__ -D__WINNT__ -D_X86_=1 -D__STDC__=1 -D__stdcall=__attribute__((__stdcall__)) -D___stdcall__=__attribute__((__stdcall__)) -D__cdecl=__attribute__((__cdecl__)) -D__declspec(x)=__attribute__((x)) -D__i386 -D__WIN32 -D__WINNT -D___stdcall=__attribute__((__stdcall__)) -Asystem(winnt) -Acpu(i386) -Amachine(i386) -remap -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ test.c D:\TEMP\ccDbaaaa.i GNU CPP version 2.95.2 19991024 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: . d:\usr\include d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\include d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\include d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\include d:\usr\local\include End of search list. Danny _____________________________________________________________________________ http://messenger.yahoo.com.au - Yahoo! Messenger - Voice chat, mail alerts, stock quotes and favourite news and lots more! |
From: Mumit K. <khan@NanoTech.Wisc.EDU> - 2001-07-04 03:22:50
|
On Wed, 4 Jul 2001, Danny Smith wrote: > > That's how I thought it's supposed to work too. However, the > C_INCLUDE_PATH and friends are actually searched *after* the built in > path. CPATH works as I expected it to Huh, you're absolutely right. Looks like it's the relative pathname lookup code that's doing it. Fortunately, the reltive lookup is undocumented, so the docs aren't exactly incorrect ;-) Thanks for your correction. Regards, Mumit |
From: Kai R. <kai...@lu...> - 2001-07-05 17:17:30
|
On Wed, 4 Jul 2001 10:26:58 +1000 (EST) Danny Smith <dan...@ya...> wrote: > > The include path is controlled by the following: > > > > 1. -I switch supplied by the user. Highest priority. > > 2. Environment variables -- C_INCLUDE_PATH, CPLUS_INCLUDE_PATH, > > and OBJC_INCLUDE_PATH, for 3 different languages, > > 3. Built in search path. This one first looks at paths that are > > configured in compile time (eg., /usr/include on most Unix boxes), > > and then relative pathname lookup given its current installation > > directory. If Mingw gcc is installed in c:/gcc-2.95.2/bin/gcc.exe, > > then it will also look in c:/gcc-2.95.2/i386-mingw32/include for > > example. > > > > Just use the -v option when compiling a file and you'll see where all > > it searches. > That's how I thought it's supposed to work too. However, the > C_INCLUDE_PATH and friends are actually searched *after* the built in > path. CPATH works as I expected it to > > Recent GCC 2.95.3 gives same result. > > $ set C_INCLUDE_PATH=d:\usr\local\include > $ set CPATH=d:\usr\include > > GNU CPP version 2.95.2 19991024 (release) (80386, BSD syntax) > #include "..." search starts here: > #include <...> search starts here: > . > d:\usr\include > d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\include > d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\..\..\..\..\i386-mingw32msvc\include > d:\mingw-2.95.2\bin\..\lib\gcc-lib\i386-mingw32msvc\2.95.2\include > d:\usr\local\include > End of search list. I got quite different results from my self-built gcc-2.95.3-1 : -------------------- clip ------------------------------- E:\usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1>set C_INCLUDE_PATH=e:/usr/local/my_include E:\usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1>md \usr\local\my_include E:\usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1>cpp0 -v GNU CPP version 2.95.3-1 20010315 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: e:\usr\local\my_include \usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1\..\..\..\..\include \usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1\include \usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1\..\..\..\..\i386-mingw32msvc\sys-include \usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1\..\..\..\..\i386-mingw32msvc\include End of search list. The following default directories have been omitted from the search path: /usr/local/lib/gcc-lib/i386-mingw32msvc/2_95.3-1/../../../../include/g++-3 End of omitted list. ^C E:\usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1>md \usr\local\my_include2 E:\usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1>set CPATH=e:/usr/local/my_include2 E:\usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1>cpp0 -v GNU CPP version 2.95.3-1 20010315 (release) (80386, BSD syntax) #include "..." search starts here: #include <...> search starts here: e:\usr\local\my_include2 e:\usr\local\my_include \usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1\..\..\..\..\include \usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1\include \usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1\..\..\..\..\i386-mingw32msvc\sys-include \usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1\..\..\..\..\i386-mingw32msvc\include End of search list. The following default directories have been omitted from the search path: /usr/local/lib/gcc-lib/i386-mingw32msvc/2_95.3-1/../../../../include/g++-3 End of omitted list. ^C -------------------- clip ------------------------------- The directories given in the environment will be searched before the built-in ones... Unfortunately the environment settings are followed by all GCCs in the system, so for instance a Linux-targeted GCC has the same directories in the same place: -------------------- clip ------------------------------- E:\usr\local\lib\gcc-lib\i486-linux-gnu\2_95.3-1>cpp0 -v GNU CPP version 2.95.3-1 20010315 (release) (i386 Linux/ELF) #include "..." search starts here: #include <...> search starts here: e:\usr\local\my_include2 e:\usr\local\my_include \usr\local\lib\gcc-lib\i486-linux-gnu\2_95.3-1\..\..\..\..\include \usr\local\lib\gcc-lib\i486-linux-gnu\2_95.3-1\include \usr\local\lib\gcc-lib\i486-linux-gnu\2_95.3-1\..\..\..\..\i486-linux-gnu\sys-include \usr\local\lib\gcc-lib\i486-linux-gnu\2_95.3-1\..\..\..\..\i486-linux-gnu\include End of search list. The following default directories have been omitted from the search path: /usr/local/lib/gcc-lib/i486-linux-gnu/2_95.3-1/../../../../include/g++-3 End of omitted list. ^C -------------------- clip ------------------------------- So I have stayed using only the GCC_EXEC_PREFIX and the built-in search directories, but wishing there would be more of them... As seen the '$prefix/include' ('/usr/local/include' in my case) is common for the previous compilers (although seeing this from the '/../../../../' stuff isn't very obvious), and this is my local addition. The local headers like the tcl/tk/itcl/tix-ones are normally installed into this 'LOCAL_INCLUDE_DIR' while the standard headers are installed into the 'STANDARD_INCLUDE_DIR' or 'TOOL_INCLUDE_DIR' ('/usr/include' or '$prefix/$target/include'). Also the 'SYSTEM_INCLUDE_DIR' or 'CROSS_INCLUDE_DIR' ('What on earth is used for a native GCC ???' or '$prefix/$target/sys-include') is enabled in the search paths of my local builds. With Mingw I keep the Win32-API 'system' headers there, separated from the 'standard' C-headers for Mingw... The influence of the GCC_EXEC_PREFIX is not seen in the 'cpp0' output because only the 'gcc's read it and use the : -iprefix e:\usr\local\lib\gcc-lib\i386-mingw32msvc\2_95.3-1\ or equivalent in the options given to 'cpp0' during compile... I am quite sure that I haven't done anything else weird than only enabled the LOCAL_INCLUDE_DIR for my cross-compilers. And of course... My Mingw-target compiler doesn't differ in any way from the tens of other Mingw-hosted ones I have. Not wanting to risk any changes a native-GCC could produce, I built the Mingw-targeted one using : --host=i386-mingw32 --target=i386-mingw32msvc Then it was produced as 'i386-mingw32'-hosted and 'i386-mingw32msvc'-targeted cross-compiler using the same rules as the others. Whether I compiled the bins using a 'i386-mingw32' or 'i386-mingw32msvc' targeted compiler didn't matter, the important thing was that I got it as a cross-compiler... Cheers, Kai PS. Generally spoken the Cygwin seems to have taken the title of the "Native GCC for Windows", using '/usr/include', '/usr/lib' etc., so Mingw naturally should be a cross-compiler under Windows -- their '-mno-cygwin' tries to implement a built-in cross-compiler to Mingw too ;-) Or should the Mingw-people fight back and try to convice people to think that the CRTDLL and MSVCRT DLLs are more 'native' in the Windows-world than the CYGWIN1.DLL is ? Then Mingw could be the 'Native GCC' there and could use the '/usr/include' and '/usr/lib'. Or perhaps there shouldn't be a native-GCC at all under Windows, my Cygwin- targeted GCC is also a Mingw-hosted cross-compiler under Windows just as the DJGPP2-targeted GCC is too. If we widen the host-selection a little more and consider Linux etc., the Mingw-targeted GCC is a cross-compiler there. Why shouldn't the Mingw-compiler be identical on every host ? Using '/mingw' as the install-root under Linux doesn't sound 'standard-conforming' though... My use of '/usr/local' has made my Windows and Linux hosted GCCs to use quite the same install directories, besides that '2_95.3-1' instead of a '2.95.3-1', which forces my DOS and Win32 hosted tools into the 8+3 rule. |