This is the mail archive of the
mailing list for the Cygwin project.
Re: converting from -mno-cygwin
- From: Lee <ler762 at gmail dot com>
- To: cygwin at cygwin dot com
- Date: Tue, 26 Apr 2016 20:32:36 -0400
- Subject: Re: converting from -mno-cygwin
- Authentication-results: sourceware.org; auth=none
- References: <CAD8GWsuVECqpUX6_BDnKq+ueU8svKXqzG9BWHNOCj4P=e4aDyQ at mail dot gmail dot com> <571FF46E dot 6050603 at gmail dot com>
On 4/26/16, JonY wrote:
> On 4/27/2016 05:08, Lee wrote:
>> How to tell if I should be using libwinpthread or pthread? I had no
>> idea so installed both:
>> $ 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.
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
>> #ifdef __MINGW32__
>> /* -LR- #include "cygwin.h" */
>> /* -LR- const char cygwin_h_rcs = CYGWIN_H_VERSION; */
>> 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
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple