This is the mail archive of the cygwin@cygwin.com 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]
Other format: [Raw text]

RE: duplicate regexec/regcomp functions detected


> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Christopher Faylor
> Sent: Friday, December 28, 2001 6:50 PM
> To: cygwin@cygwin.com
> Subject: Re: duplicate regexec/regcomp functions detected
>
>
> 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.

This was a real example, I've found in the qt library and has the intention to show that
>
> >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.
>
Of course, but it should be kept easy as it is possible.
But remember the above example
   gcc -o test -lpthread main.o [-lcygwin]
This isn't a good example, but it causes linkage errors seeming without any logic.
When I'm linking to libpthread, than I don't expect to have multiple "main" symbols and this
"don't do that", if have often heard in the past.
I think robust software, as this I have experienced open software, should as much as possible
should produc
predictable results and especially error messages.

> 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.
>
The patch for creating libpthread.a is appended. It contains a script names "speclib" and an
additional rule in the src/winsup/cygwin/Makefile.in.

The script exports symbols from an object file or lib and lookup the cygwin import library
for the related
object files, which are be extracted and are used to build the new archive.
The script allows to create any special lib like libc or libm, but I haven't checked this,
because currently I does not know enough about libc/m integration in cygwin to say, if this
work.
A snippet of the Makefile.in show how the script is called:

$(LIBPTHREAD_A): speclib new-$(DLL_NAME)
	/bin/sh ${word 1,$^} cygdll.a pthread.o $@ "$(NM)" "$(AR)" "$(RANLIB)" || exit 0
	@echo create $(LIBPTHREAD_A)

speclib <cygwinlib> <used lib or objectfile> <outputlib> <nm tool> <ar tool> <ranlib tool>

cygwinlib
- name of the basic cygwin import library, of which the nessesary objectfiles are used to
create the new import library

used lib or objectfile
- name of the library or objectfile of which the symbols (T or D) are used

outputlib
- the name of the created lib

nm tool - like rmsym script

ar tool - like rmsym script

ranlib tool - like rmsym script


Regards
Ralf

Attachment: Makefile.in.dif
Description: Binary data

Attachment: speclib
Description: Binary data

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

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