Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Date: Tue, 28 May 2002 14:35:15 +0400 From: egor duda Reply-To: egor duda Organization: deo X-Priority: 3 (Normal) Message-ID: <135849083517.20020528143515@logos-m.ru> To: Sven Sandberg CC: cygwin AT cygwin DOT com Subject: Re: direct.h + pthreads In-Reply-To: <3CF34EA0.B30AA0A8@student.uu.se> References: <3CF34EA0 DOT B30AA0A8 AT student DOT uu DOT se> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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 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 . 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> 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/