From: JonY <10walls@gmail.com>
To: cygwin@cygwin.com
Subject: Re: converting from -mno-cygwin
Date: Wed, 27 Apr 2016 12:49:00 -0000 [thread overview]
Message-ID: <572091DE.7010800@gmail.com> (raw)
In-Reply-To: <CAD8GWsusQNP2g5=JbWuyu0L+YqZEOxkgh1TedZkKRxUV-VRZMQ@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2016-04-27 10:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-26 23:06 Lee
2016-04-27 0:32 ` JonY
2016-04-27 5:36 ` Lee
2016-04-27 12:49 ` JonY [this message]
2016-04-28 21:17 ` Lee
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=572091DE.7010800@gmail.com \
--to=10walls@gmail.com \
--cc=cygwin@cygwin.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).