Mail Archives: cygwin/2002/05/28/06:36:18
Hi!
Tuesday, 28 May, 2002 Sven Sandberg svsa1977 AT student DOT uu DOT se wrote:
SS> I'm trying to compile a program that #includes <direct.h> and links with
SS> pthreads, and keep running into problems:
You're trying to mix two unmixable things. I'll try to explain what
-mno-cygwin flag does and hope it will help you answer all those
questions yourself.
When you compile a program with gcc, it is supposed to run in some
environment called "platform". This environment includes a processor
(intel x86, sparc, alpha, etc), operating system that runs on your
machine (windows, linux, solaris, etc.) and runtime libraries that are
not themselves part of OS, but which are needed by your program to
run.
Gcc binary that produces an executable for some platform is said
to be targeted at that platform. That is, gcc distributed with cygwin
is cygwin-targeted. The resulting binary is expected to run on x86
processor + win32 OS + cygwin1.dll runtime library. Actually, there
are other platforms based on win32 OSes, but with different runtime
libraries. One of them is MinGW -- a platform which uses Microsoft's
runtime libraries -- MSVCRT.DLL or CRTDLL.DLL. Of course, different
platforms have different APIs -- for instance, linux have aio_read()
function and cygwin haven't, cygwin have GetCurrentProcessId()
function and linux haven't. So, each platform have its own set of
header files and libraries that represent a set of APIs available on
this platform. It's important to understand that cygwin and mingw is
different platforms, even though they're both based on win32 OS. For
example, cygwin platform have fork() API which is not available on
MinGW.
Incidentally, gcc distributed with cygwin is actually multi-targeted --
it can produce binaries for two different platforms -- cygwin and
mingw. By default the resulting binary is supposed to be run on cygwin
platform, but if you add -mno-cygwin switch to command line, it switch
to MinGW target, i.e. produce a binary to be run on MinGW platform.
When switching to other target, compiler should also switch to the
headers and libraries appropriate for this target. When you install
cygwin, those headers and libraries are put to /usr/include/mingw and
/usr/lib/mingw directories, while cygwin headers and libraries are put
in /usr/include and /usr/lib.
One shouldn't mix headers and libraries for different platforms (just
like you can't build cygwin program using, say, linux header files).
So, when you #include something to your code or link some library to
your object files you should ask yourself first: "Are those header or
library files for the platform that i want my program to be run on?"
If the answer is "yes" then you can safely use a particular header or
library. Otherwise, you should try to find some analog or substitution
for them.
As for direct.h and libpthread.a files that you're using the problem
is exactly in that: The former is MinGW header, while libpthread.a is
a cygwin library. You can't mix them. Actually, you can't include
direct.h if you're building cygwin executable and you can't link with
cygwin version of libpthread.a if you're building mingw executable.
So you should either try to find mingw version of pthread library and
build mingw program, or find a way to replace the occurrences of
functions from direct.h in your code to some code that does the same,
but uses only APIs available on cygwin platform.
SS> 1. It appears that all programs linked with pthreads crash even before
SS> invoking WinMain() if you compile with the -mno-cygwin flag. So I have
SS> to link without it, right?
SS> My command line is now:
SS> gcc -Wall -o tmp tmp.c -lpthread
SS> 2. direct.h seems to be in the include path only if -mno-cygwin is
SS> specified (why?), so I have to add -I/usr/include/mingw to the command
SS> line.
SS> My command line is now:
SS> gcc -I/usr/include/mingw -Wall -o tmp tmp.c
SS> 3. My program also accesses errno. After I added -I/usr/include/mingw
SS> to the command line, it gives undefined references to errno. For some
SS> reason which I don't understand, this goes away if I add -I/usr/include
SS> before -I/usr/include/mingw. (Is this normal?)
SS> My command line is now:
SS> gcc -I/usr/include -I/usr/include/mingw -Wall -o tmp tmp.c
SS> 4. My program also #includes <stdio.h>. With -I/usr/include, I get
SS> several errors like this:
SS> /usr/include/stdio.h:162: parse error before `__gnuc_va_list'
SS> /usr/include/stdio.h:163: parse error before `__gnuc_va_list'
SS> /usr/include/stdio.h:164: parse error before `__gnuc_va_list'
SS> etc.
SS> __VALIST expands to __gnuc_va_list, and as far as grep can see,
SS> __gnuc_va_list is not defined in any header file on my disk. Sure, I can
SS> do '#define __gnuc_va_list va_list', but this is hardly the way it's
SS> intended to be done? (Plus, my program is really a library and it
SS> doesn't seem nice to users to do this.)
SS> Am I doing something wrong? Is there a better way to both #include
SS> <direct.h> and use pthreads?
Egor. mailto:deo AT logos-m DOT ru 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/
- Raw text -