This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: autoconf & alternate libraries

----- Original Message -----
From: "Willem Konynenberg" <>
To: <>
Sent: Monday, April 16, 2001 7:44 PM
Subject: autoconf & alternate libraries

> Hello,
> I find myself in a situation where I try to autoconf a package
> with proper support for Cygwin.
> In the current non-autoconf situation, the package compiles under
> Cygwin using a special W32 version of the makefile, which sets an
> explicit path to an alternate pthreads library, because the default
> one in cygwin was found lacking in some details.
> I would like to avoid having to specify explicit library paths
> on the gcc command line, using all sorts of platform-specific hacks
> in my, so I was hoping there is some standard procedure
> to configure things so that gcc will automatically find the alternate
> pthreads library as appropriate.  That way, I could just provide
> appropriate instructions to configure cygwin (how to install the
> pthreads library) and forget about the issue in my autoconf setup.
> I tried to find some info on this issue on the Redhat cygwin web
> site, but I didn't find anything that helped.
> Since I don't have a Windows system, I have no way to test/check any
> of this myself, so I'm really in the dark.
> Pointers appreciated.  Thanks.

OK, here's some pointers :]

1) Cygwin now has (nearly) full pthreads support. Certain of the _r
functions are still missing, but that is something external threads
libraries don't supply anyway. To get the cygwin with pthreads support
your users need cygwin 1.3.0 (soon to be released) or until it's
released a daily snapshot (dated 14/4/2001 or later). The pthreads
support is contained in libcygwin.a (aka cygwin1.dll) which is
implicitly linked under cygwin so no extra libraries are needed on the
link line. Thus you should be able to get rid of your alternate makefile
and just use the existing configure script.

2) Using the alternate pthreads library may cause issues with cygwin -
specifically with fork(). I strongly suggest your users use the inbuilt
cygwin pthreads - I for one, and I suspect the rest of the cygwin
developers for two are not going to spend time debugging any issues that
arise from mixing cygwin with non-cygwin integrated thread support.

If you __really__ want to use the alternate pthreads library your users
can do something like
LDFLAGS="-L/path/to/libraries -laltpthread"
CFLAGS="-I/path/to/alt/headers" ./configure ...


> --
>      Willem Konynenberg <>
> I am not able rightly to apprehend the kind of confusion of ideas
> that could provoke such a question  --  Charles Babbage
> --
> Want to unsubscribe from this list?
> Check out:

Want to unsubscribe from this list?
Check out:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]