Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Date: Fri, 28 Dec 2001 12:49:56 -0500
From: Christopher Faylor <cgf AT redhat DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: duplicate regexec/regcomp functions detected
Message-ID: <20011228174956.GA30625@redhat.com>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <20011227174239 DOT GA24897 AT redhat DOT com> <000d01c18f90$c37bfd30$0e6307d5 AT BRAMSCHE>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <000d01c18f90$c37bfd30$0e6307d5@BRAMSCHE>
User-Agent: Mutt/1.3.23.1i

On Fri, Dec 28, 2001 at 12:14:04PM +0100, Ralf Habacker wrote:
>> >gcc -o test -lpthread main.o [-lcygwin]
>> >
>> >This will result in multiple defined symbols for WinMain (expected that
>> >main.o contains a main function).  You can say don't do this, but what
>> >about bigger packages like qt.  The qt configuring process does only
>> >allow like the above link line.
>>
>> The above link line makes no sense.  It is wrong.  It should be
>> corrected.
>
>May be, but I think you know some combinations that are real.  what is
>with this ?

The above command line is just bogus.  The -lpthread before the main.o
is wrong.  If you are going to choose an example choose one that makes
sense.

>Assume main.o needs to be linked to the pcreposix lib.
>
>gcc -o test main.o -lpthread -lpcreposix
>
>or this if main needs to be linked to the regex lib.
>
>gcc -o test main.o -lpthread -lregex
>
>This will fail and the users have to figure out deeply why this does
>not work.  Isn't it ?

I assume that by "fail" you mean that the functions from the regex
library will not be used.  Well, the good news is that this won't be an
issue for cygwin 1.3.7.  The newer regex functions will be part of
the cygwin DLL.  libregex.a will either be nonexistent or it will
be an empty stub.

The inclusion of the pthread library in the cygwin distribution was
recent.  It solved some configuration issues.  It is no different
from the libm.a "problem".  I'm not going to remove libpthread.a any
more than I am going to remove libm.a.

If you want to implement your idea of a libpthread.a with specific
pthread imports, then I'm willing to look at a patch.  Otherwise, there
will be no changes in cygwin 1.3.7.

>The result of this is, that the packager of the pcre and the regex
>package have to add a note in their documentation that their lib must
>be the first lib before -lg or -lpthread and perhaps more libs in the
>future.  Make this sense ?

That people should document system dependencies?  Sure.

Why do you think libm.a, libg.a, libc.a, libpthread.a are even in the
cygwin distribution?  Does it make sense to *you* that they are there to
solve some problems?

There are many many compromises in cygwin.  Every single time we make
a decision to do something one way, someone will step forward to tell
us how it screwed them up and suggest that we revert to the previous
behavior.  Rarely is there any indication that anyone is thinking about
the big picture, however.  Is your problem more generic than the problem
that the inclusion of libpthread.a was meant to solve?  I don't think
it is.

I could be wrong, but I think this is the first complaint I've heard
about libpthread.a.  The same complaint could be levelled at libm.a.
The simple fact of life is that library inclusion order does matter.
Cygwin is not the only system that suffers from issues like this.

However, luckily, if this matters to you, you can submit a patch to fix
it.  I think that the place to start would be winsup/Makefile.in.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/