Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com List-Subscribe: List-Archive: List-Post: List-Help: , Delivered-To: mailing list cygwin-apps AT sources DOT redhat DOT com Date: Sun, 18 Mar 2001 12:43:00 -0500 From: Christopher Faylor To: cygwin-apps AT cygwin DOT com Cc: Kees Zeelenberg , Paul Sokolovsky , Tor Lillqvist , mingw-users AT lists DOT sourceforge DOT net, "Charles S. Wilson" Subject: Re: [Mingw-users] HOWTO setup cygwin's 'gcc -mno-cygwin' using mingw Message-ID: <20010318124300.J12880@redhat.com> Reply-To: mingw-users AT lists DOT sourceforge DOT net, cygwin-apps AT cygwin DOT com Mail-Followup-To: cygwin-apps AT cygwin DOT com, Kees Zeelenberg , Paul Sokolovsky , Tor Lillqvist , mingw-users AT lists DOT sourceforge DOT net, "Charles S. Wilson" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.11i Paul Sokolovsky , Tor Lillqvist , mingw-users AT lists DOT sourceforge DOT net, "Charles S. Wilson" , cygwin-apps AT cygwin DOT com Cc: Bcc: Subject: Re: [Mingw-users] HOWTO setup cygwin's 'gcc -mno-cygwin' using mingw libs/headers Reply-To: cygwin-apps AT cygwin DOT com In-Reply-To: <3AB4DBCC DOT ED1CD2E1 AT ece DOT gatech DOT edu>; from cwilson AT ece DOT gatech DOT edu on Sun, Mar 18, 2001 at 11:01:16AM -0500 On Sun, Mar 18, 2001 at 11:01:16AM -0500, Charles S. Wilson wrote: >Earnie Boyd wrote: >> If any library that is downloaded from the Cygwin official site also has >> MinGW libraries then those libraries should go into /usr/lib/mingw/. > >I don't think this will happen -- Chris seems opposed to increasing the >size of "standard cygwin" packages by including mingw libs/binaries that >most cygwin users won't use. (And the truth is, I don't particularly >WANT to do extra work packing up my cygwin ports of various libs... :-) Right. I'm not against including mingw stuff with Cygwin but I don't want to be burdened with having to support it. So, if someone comes up with an acceptable method for ensuring that it is selectable and not downloaded by default then I have no objections. I just don't want to do the work. I really admire the work that the MinGW volunteers have done but this is not my project. If there are suitable volunteers straddleing both projects then this may get done, otherwise IMO discussion is fruitless. >> Libraries not on the official site that also include MinGW libraries >> should go into the /usr/local/lib/mingw/ directory. GCC-2.95.2-9 has >> been renovated to fit this model. > >How has -9 been renovated? The appropriate parts of cygwin.h are included below. For the most part, I've managed to isolate the mingw stuff from the cygwin stuff. The -mno-cygwin switch turns off scanning of /usr/include and /usr/local/include in favor of /usr/include/mingw and /usr/local/include/mingw. I'm not satisfied with the library separation, though. I think I'll need to put the w32api stuff in its own directory and somehow come up with a way for the linker to avoid loading cygwin libraries when -mno-cygwin is provided. I don't know any way of doing this currently but I haven't researched it much. I just figured out how to separate the g++ stuff recently... I was wondering the other day if all of the cygwin mingw stuff shouldn't be installed in its own completely separate /mingw directory as Earnie has suggested in another message. Then a person could drop in a mingw from mingw.org and have it work with cygwin -- and I could drop the mingw part of the cygwin distribution. cgf #ifdef CROSS_COMPILE #define CYGWIN_INCLUDES "-idirafter " CYGWIN_CROSS_DIR "/include" #define CYGWIN_CPP_INCLUDES "-isystem " CYGWIN_CROSS_DIR "/include/g++-3 "\ "-isystem " CYGWIN_CROSS_DIR "/include/g++" #define CYGWIN_W32API "-idirafter " CYGWIN_CROSS_DIR "/include/w32api" #define CYGWIN_LIB CYGWIN_CROSS_DIR "/lib" #define MINGW_LIBS "-L" CYGWIN_CROSS_DIR "/lib/mingw" #define MINGW_INCLUDES "-idirafter " CYGWIN_CROSS_DIR "/include/mingw" #define MINGW_CPP_INCLUDES "-isystem " CYGWIN_CROSS_DIR "/include/mingw/g++-3 "\ "-isystem " CYGWIN_CROSS_DIR "/include/mingw/g++" #else #define CYGWIN_INCLUDES "-isystem /usr/local/include "\ "-idirafter /usr/include" #define CYGWIN_CPP_INCLUDES "-isystem /usr/include/g++-3 "\ "-isystem /usr/include/g++" #define CYGWIN_W32API "-idirafter /usr/include/w32api" #define CYGWIN_LIB "/usr/lib" #define MINGW_LIBS "-L/usr/local/lib/mingw -L/usr/lib/mingw" #define MINGW_INCLUDES "-isystem /usr/local/include/mingw " \ "-idirafter /usr/include/mingw" #define MINGW_CPP_INCLUDES "-isystem /usr/include/mingw/g++-3 "\ "-isystem /usr/include/mingw/g++" #endif #undef CPP_PREDEFINES #define CPP_PREDEFINES "-D_X86_=1 -Asystem(winnt)" /* Support the __declspec keyword by turning them into attributes. We currently only support: dllimport and dllexport. Note that the current way we do this may result in a collision with predefined attributes later on. This can be solved by using one attribute, say __declspec__, and passing args to it. The problem with that approach is that args are not accumulated: each new appearance would clobber any existing args. */ #undef CPP_SPEC #define CPP_SPEC "%(cpp_cpu) %{posix:-D_POSIX_SOURCE} \ -D__stdcall=__attribute__((__stdcall__)) \ -D__cdecl=__attribute__((__cdecl__)) \ %{!ansi:-D_stdcall=__attribute__((__stdcall__)) \ -D_cdecl=__attribute__((__cdecl__))} \ -D__declspec(x)=__attribute__((x)) \ %{mno-win32: %{mno-cygwin: %emno-cygwin and mno-win32 are not compatible}} \ %{mno-cygwin:-D__MSVCRT__ -D__MINGW32__ %{mthreads:-D_MT} " MINGW_INCLUDES "} \ %{!mno-cygwin:-D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix "\ CYGWIN_INCLUDES "}\ %{mwin32|no-cygwin:-DWIN32 -D_WIN32 -D__WIN32 -D__WIN32__ -DWINNT}\ %{!mno-win32:" CYGWIN_W32API "}\ " #undef CPLUSPLUS_CPP_SPEC #define CPLUSPLUS_CPP_SPEC "\ %{!mno-cygwin:" CYGWIN_CPP_INCLUDES "}\ %{mno-cygwin:" MINGW_CPP_INCLUDES "}\