converting from -mno-cygwin

converting from -mno-cygwin

[Lee]

I'm trying to get privoxy (https://sourceforge.net/projects/ijbswa/)
to build under the current cygwin.
It works using cygwin 1.5 + gcc v3 -mno-cygwin & I was hoping it would
be relatively easy to get it working using the cross-compiler
toolchain. But I keep getting stuck :(

$ make
i686-w64-mingw32-gcc  -mwindows -mwin32  -o privoxy.exe actions.o
cgi.o cgiedit.o cgisimple.o deanimate.o encode.o errlog.o filters.o
gateway.o jbsockets.o jcc.o list.o loadcfg.o loaders.o miscutil.o
parsers.o ssplit.o urlmatch.o client-tags.o w32log.o w32taskbar.o
win32.o w32svrapi.o w32.res pcrs.o pcre/get.o pcre/maketables.o
pcre/study.o pcre/pcre.o pcre/pcreposix.o -lws2_32  -lz -lwsock32
-lcomctl32  -lpthreadGC2
/usr/lib/gcc/i686-w64-mingw32/4.9.2/../../../../i686-w64-mingw32/bin/ld:
cannot find -lpthreadGC2
collect2: error: ld returned 1 exit status
GNUmakefile:727: recipe for target 'privoxy.exe' failed
make: *** [privoxy.exe] Error 1


I tried changing the make file to

# PThreads library, if needed.
PTHREAD_LIB  = -lpthread

and it builds without error, but run it and it complains about
This application has failed to start because libwinpthread-1.dll was not found.

So copy libwinpthread-1.dll & zlib1.dll to the directory where I've
got privoxy.exe and it actually works!  Or at least hasn't crashed yet
:)


Questions:

How to tell if I should be using libwinpthread or pthread?  I had no
idea so installed both:
/usr/i686-w64-mingw32/sys-root/mingw/bin
$ ls -l *hread*
-rwxr-xr-x 1 root None 47635 Apr  7 08:54 libwinpthread-1.dll
-rwxr-xr-x 1 root None 65024 Jul  6  2013 pthreadGC2.dll


If I should be using the pthread library, what's the correct library
name to give GCC - ie. in the make file,
PTHREAD_LIB  = ??what??


Is there a way to get the libraries included as part of the
executable?  I'd rather not have to include libwinpthread-1.dll &
zlib1.dll in the distribution package.


Is there a standard way to figure out if the compiler is gcc-v3 with
the -mno-cygwin flag set?
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??

TIA,
Lee

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: converting from -mno-cygwin

[JonY]

[-- Attachment #1: Type: text/plain, Size: 1766 bytes --]

On 4/27/2016 05:08, Lee wrote:
> Questions:
> 
> How to tell if I should be using libwinpthread or pthread?  I had no
> idea so installed both:
> /usr/i686-w64-mingw32/sys-root/mingw/bin
> $ ls -l *hread*
> -rwxr-xr-x 1 root None 47635 Apr  7 08:54 libwinpthread-1.dll
> -rwxr-xr-x 1 root None 65024 Jul  6  2013 pthreadGC2.dll
> 
> 

pthreadGC2 is a compatibility left over.

> If I should be using the pthread library, what's the correct library
> name to give GCC - ie. in the make file,
> PTHREAD_LIB  = ??what??
> 
> 

Just use -lpthread like everyone on *nix does.

> Is there a way to get the libraries included as part of the
> executable?  I'd rather not have to include libwinpthread-1.dll &
> zlib1.dll in the distribution package.
> 
> 

-static? ymmv.

> 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.

> 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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: converting from -mno-cygwin

[Lee]

On 4/26/16, JonY  wrote:
> On 4/27/2016 05:08, Lee wrote:
>> Questions:
>>
>> How to tell if I should be using libwinpthread or pthread?  I had no
>> idea so installed both:
>> /usr/i686-w64-mingw32/sys-root/mingw/bin
>> $ ls -l *hread*
>> -rwxr-xr-x 1 root None 47635 Apr  7 08:54 libwinpthread-1.dll
>> -rwxr-xr-x 1 root None 65024 Jul  6  2013 pthreadGC2.dll
>>
>>
>
> pthreadGC2 is a compatibility left over.

So I should uninstall it?  I have both installed now:
mingw64-i686-pthreads                 20100619-5                    OK
mingw64-i686-winpthreads              4.0.6-1                       OK

and maybe it's a problem.  I haven't tracked it down yet, but GNUmakefile.in has
# PThreads library, if needed.
PTHREAD_LIB  = @PTHREAD_ONLY@@PTHREAD_LIB@

which, after running autoheader & autoconf, creates a GNUmakefile with
# PThreads library, if needed.
PTHREAD_LIB  = -lpthreadGC2

which doesn't work :(

>> If I should be using the pthread library, what's the correct library
>> name to give GCC - ie. in the make file,
>> PTHREAD_LIB  = ??what??
>>
>>
>
> Just use -lpthread like everyone on *nix does.

OK - I just have to figure out how to get autoheader/autoconf to do that.

>> Is there a way to get the libraries included as part of the
>> executable?  I'd rather not have to include libwinpthread-1.dll &
>> zlib1.dll in the distribution package.
>>
>>
>
> -static? ymmv.

Yes!  that's the magic needed.

$ make
i686-w64-mingw32-gcc  -mwindows -mwin32  -o privoxy.exe actions.o
cgi.o cgiedit.o cgisimple.o deanimate.o encode.o errlog.o filters.o
gateway.o jbsockets.o jcc.o list.o loadcfg.o loaders.o miscutil.o
parsers.o ssplit.o urlmatch.o client-tags.o w32log.o w32taskbar.o
win32.o w32svrapi.o w32.res pcrs.o pcre/get.o pcre/maketables.o
pcre/study.o pcre/pcre.o pcre/pcreposix.o -lws2_32  -lz -static
-lwsock32 -lcomctl32  -lpthread

and I don't need the DLLs any more :)


>> 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

>> 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.

Thanks,
Lee

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple

Re: converting from -mno-cygwin

[JonY]

[-- Attachment #1: Type: text/plain, Size: 3345 bytes --]

On 4/27/2016 08:32, Lee wrote:
> On 4/26/16, JonY  wrote:
>> On 4/27/2016 05:08, Lee wrote:
>>> Questions:
>>>
>>> How to tell if I should be using libwinpthread or pthread?  I had no
>>> idea so installed both:
>>> /usr/i686-w64-mingw32/sys-root/mingw/bin
>>> $ ls -l *hread*
>>> -rwxr-xr-x 1 root None 47635 Apr  7 08:54 libwinpthread-1.dll
>>> -rwxr-xr-x 1 root None 65024 Jul  6  2013 pthreadGC2.dll
>>>
>>>
>>
>> pthreadGC2 is a compatibility left over.
> 
> So I should uninstall it?  I have both installed now:
> mingw64-i686-pthreads                 20100619-5                    OK
> mingw64-i686-winpthreads              4.0.6-1                       OK
> 

Sure, its there because pthreadGC was around longer than winpthreads.
Notice there is no import library for pthreadGC, it is only provided for
compatibility with any app that still use it.

> and maybe it's a problem.  I haven't tracked it down yet, but GNUmakefile.in has
> # PThreads library, if needed.
> PTHREAD_LIB  = @PTHREAD_ONLY@@PTHREAD_LIB@
> 
> which, after running autoheader & autoconf, creates a GNUmakefile with
> # PThreads library, if needed.
> PTHREAD_LIB  = -lpthreadGC2
> 
> which doesn't work :(
> 

Fix your configure.ac assumptions.

>>> 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 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.




[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: converting from -mno-cygwin

[Lee]

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
>> GNUmakefile.in has
>> # PThreads library, if needed.
>> PTHREAD_LIB  = @PTHREAD_ONLY@@PTHREAD_LIB@
>>
>> which, after running autoheader & autoconf, creates a GNUmakefile with
>> # PThreads library, if needed.
>> PTHREAD_LIB  = -lpthreadGC2
>>
>> which doesn't work :(
>>
>
> Fix your configure.ac 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 https://cygwin.com/faq/faq.html#faq.programming.64bitporting
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:
/source/privoxy/current
$ 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!!

Lee

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple