converting from -mno-cygwin

Thu Apr 28 21:17:00 GMT 2016

On 4/27/16, JonY  wrote:
> On 4/27/2016 08:32, Lee wrote:
>> On 4/26/16, JonY  wrote:
>>> On 4/27/2016 05:08, Lee wrote:
>>>> Questions:
  [.. snip ..]
>> and maybe it's a problem.  I haven't tracked it down yet, but
>> has
>> # PThreads library, if needed.
>> which, after running autoheader & autoconf, creates a GNUmakefile with
>> # PThreads library, if needed.
>> PTHREAD_LIB  = -lpthreadGC2
>> which doesn't work :(
> Fix your assumptions.

Done!  works now :)

>>>> Is there a standard way to figure out if the compiler is gcc-v3 with
>>>> the -mno-cygwin flag set?
>>> No, don't do this, it'd turn into a giant hairball fast.
>> Not really.. it's just a few places that I've had to change the source
>> code to deal with the differences between cygwin 1.5 + gcc v3 &
>> whatever the current cygwin is + i686-w64-mingw32-gcc
> You'd get into a bigger hairball when you involve 64bit Cygwin where
> long is 64bit unlike the rest of the Windows world.

I took a look at
I'm not sure I really want to go there.  But in any case, I think
you're right to not try to maintain compatibility with gcc -mno-cygwin

>>>> I had to make a few changes to the code to get this far & I'd prefer
>>>> to have the changes wrapped inside an #IFDEF or something.  For
>>>> example, I just commented out the include since it conflicts with
>>>> something
>>>> #ifdef __MINGW32__
>>>> /* -LR- #include "cygwin.h" */
>>>> /* -LR- const char cygwin_h_rcs[] = CYGWIN_H_VERSION; */
>>>> #endif
>>>> Under cygwin 1.5, gcc -mno-cygwin  requires cygwin.h to be included.
>>>> Using i686-w64-mingw32-gcc if cygwin.h is inculded gcc barfs with a
>>>> conflicting definition of [i don't remember].
>>>> It'd be nice if I could build using the old or new method without
>>>> having to change the source code, so I'm guessing I want some kind of
>>>> ifdef wrapper for the include??
>>> What are you even trying to do? You shouldn't mix different runtimes.
>> I'm not mixing runtimes.  I'm trying to keep it so that the program
>> continues to build under the old cygwin 1.5/gcc -mno-cygwin as well as
>> building under the current cygwin/i686-w64-mingw32-gcc cross-compiler.
>> Since I have to do different things depending on if I'm using the
>> cross compiler or the old gcc -mno-cygwin I'm hoping there's a flag or
>> something I can use so the exact same source code works with either
>> build system.
> Using Cygwin headers in purely win32 program is wrong.  I understand you
> are simply trying to get Cygwin version strings, it'll just end up as a
> compile error if the toolchain isn't Cygwin hosted. You can try using
> autoconf to run "uname -a" instead and grab that instead.

It looks like cygwin.h was included because it has the define for _RICHEDIT_VER
If I remove the include & build using gcc v3:
[1.5] Lee@twinky /cygdrive/c/cygwin/cvs/privoxy/current
$ make
gcc -c -pipe -O2 -DWINVER=0x501   -mwindows -mno-cygwin -Wall -Ipcre
w32log.c -o w32log.o
w32log.c:61: error: `CYGWIN_H_VERSION' undeclared here (not in a function)
w32log.c: In function `InitRichEdit':
w32log.c:774: error: `_RICHEDIT_VER' undeclared (first use in this function)
w32log.c:774: error: (Each undeclared identifier is reported only once
w32log.c:774: error: for each function it appears in.)
make: *** [w32log.o] Error 1

The include files for i686-w64-mingw32-gcc have been [changed?
fixed?] so that including cygwin.h now causes a warning:
$ make
i686-w64-mingw32-gcc -c -pipe -O2 -DWINVER=0x501   -mwindows -mwin32
-Wall -Ipcre  w32log.c -o w32log.o
In file included from w32log.c:60:0:
cygwin.h:43:0: warning: "_RICHEDIT_VER" redefined
 #define _RICHEDIT_VER 0x0300
In file included from w32log.c:45:0:
/usr/i686-w64-mingw32/sys-root/mingw/include/richedit.h:23:0: note:
this is the location of the previous definition
 #define _RICHEDIT_VER 0x0800

Thanks for your help!!


Problem reports:
Unsubscribe info:

More information about the Cygwin mailing list