duplicate regexec/regcomp functions detected

duplicate regexec/regcomp functions detected

[Ralf Habacker]

Hi all,

kde needs the regexp functions regexec and regcomp.

The cygwin lib contains the System V8 function call style, while the pcre package (pcreposix)
provides another style (the system V style I guess). The problem is now, that both libs
supports the same names for regexec and regcomp but with different parameter/return types.
This results sometimes in execution failures if the libs are not in the right order like
shown in the following example.

pcre regexp wanted

$ gcc ... -lpcreposix -lcygwin   -> okay

$ gcc ... -lpthreads|-lm|-lc -lpcreposix -lcygwin   -> failure: the functions in cygwin lib
are used

Especially in libtool related environment with many dependency libs like kde this causes much
trouble.

Should it not be better, to remove the regexp support from cygwin into a seperate lib, so
that users has an easier possibility to choose which regexp style they want ?

Regards

Ralf









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

Re: duplicate regexec/regcomp functions detected

[Corinna Vinschen]

On Thu, Dec 13, 2001 at 09:18:39PM +0100, Ralf Habacker wrote:
> Hi all,
> 
> kde needs the regexp functions regexec and regcomp.
> 
> The cygwin lib contains the System V8 function call style, while the pcre package (pcreposix)
> provides another style (the system V style I guess). The problem is now, that both libs
> supports the same names for regexec and regcomp but with different parameter/return types.
> This results sometimes in execution failures if the libs are not in the right order like
> shown in the following example.
> 
> pcre regexp wanted
> 
> $ gcc ... -lpcreposix -lcygwin   -> okay
> 
> $ gcc ... -lpthreads|-lm|-lc -lpcreposix -lcygwin   -> failure: the functions in cygwin lib
> are used

But that order should never happen EXCEPT you're making the big
mistake to give `-lm' or `-lc' on the command line explicitly.
Since -lcygwin is appended automagically and libc.a and libm.a
are the same library anyway, the answer is simply, "Don't do that."

> Especially in libtool related environment with many dependency libs like kde this causes much
> trouble.
> 
> Should it not be better, to remove the regexp support from cygwin into a seperate lib, so
> that users has an easier possibility to choose which regexp style they want ?

We didn't want that for compatibility reasons.  We often already
discussed to trash the V8 implementation in favor of a POSIX
implementation but that would break older applications which we're
trying to avoid.

Btw., we have another POSIX regex library besides pcreposix: -lregex.
It's somewhat smaller and it's also DLLized.  OpenSSH's configure.ac
file has a special check to see if a regex lib exists and if the base
regexp implementation in the std C lib is POSIX compliant.  We added
that to the OpenSSH configury a few weeks ago to make Cygwin happy.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

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

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

[-- Attachment #1: Type: text/plain, Size: 3758 bytes --]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Corinna Vinschen
> Sent: Friday, December 14, 2001 11:36 AM
> To: cygwin
> Subject: Re: duplicate regexec/regcomp functions detected
>
>
> On Thu, Dec 13, 2001 at 09:18:39PM +0100, Ralf Habacker wrote:
> > Hi all,
> >
> > kde needs the regexp functions regexec and regcomp.
> >
> > The cygwin lib contains the System V8 function call style, while the pcre
> package (pcreposix)
> > provides another style (the system V style I guess). The problem is now, that both libs
> > supports the same names for regexec and regcomp but with different
> parameter/return types.
> > This results sometimes in execution failures if the libs are not in the right order like
> > shown in the following example.
> >
> > pcre regexp wanted
> >
> > $ gcc ... -lpcreposix -lcygwin   -> okay
> >
> > $ gcc ... -lpthreads|-lm|-lc -lpcreposix -lcygwin   -> failure: the functions in
> cygwin lib
> > are used
>
> But that order should never happen EXCEPT you're making the big
> mistake to give `-lm' or `-lc' on the command line explicitly.
> Since -lcygwin is appended automagically and libc.a and libm.a
> are the same library anyway, the answer is simply, "Don't do that."

This may be for -lm and -lc, but what about libpthread

Think about this link line:

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.

anyway, saying don't do this is a way, but solving this problem is another.

A general possible solution for this, is not to make several links to cygwin, but to create
linkage libraries with only special symbols used for each cygwin derivated lib, like pthread.
The appended script does exactly this for libpthread. It extracts the pthread relating object
files from libcygwin.a and create a new archive libpthread.a. Using this technology removes
any ordering problems with pthread and other libs on the input line.

> > Especially in libtool related environment with many dependency libs like kde
> this causes much
> > trouble.
> >
> > Should it not be better, to remove the regexp support from cygwin into a seperate lib, so
> > that users has an easier possibility to choose which regexp style they want ?
>
> We didn't want that for compatibility reasons.  We often already
> discussed to trash the V8 implementation in favor of a POSIX
> implementation but that would break older applications which we're
> trying to avoid.

I understand, but what about to cast the function to another name (like _prefix or so) in the
headerfiles.
This would prevent some debugging sessions for people, who are not very confirm with this
issue.

Another solution may be the concept of creating extracted linking libraries desribed above.

> Btw., we have another POSIX regex library besides pcreposix: -lregex.
> It's somewhat smaller and it's also DLLized.  OpenSSH's configure.ac
> file has a special check to see if a regex lib exists and if the base
> regexp implementation in the std C lib is POSIX compliant.  We added
> that to the OpenSSH configury a few weeks ago to make Cygwin happy.

Thanks for this hint.

> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Developer                                mailto:cygwin@cygwin.com
> Red Hat, Inc.
>
> --
> 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/
>
>

[-- Attachment #2: make_libpthread --]
[-- Type: application/octet-stream, Size: 747 bytes --]

#!/bin/sh
#
# create specific link library for libpthread to avoid some linkage problems like double defined WinMain
#
# for example in "gcc -o test -lpthread main.o" WinMain is double defined 
# 

LIB_CYGWIN=/lib/libcygwin.a 
LIB_PTHREAD=/lib/libpthread.a 

# awk script for extracing gawk related object files 
GAWK='
$1 ~ /^d00/ { file = $1; gsub(":","",file); }
$3 ~ /^_pthread/ { print file; }
'

# make backup of pthread link library 
cp -f $LIB_PTHREAD $LIB_PTHREAD.org
rm -f $LIB_PTHREAD 

# extract pthread related object files 
nm $LIB_CYGWIN | gawk "$GAWK" | xargs ar x $LIB_CYGWIN 

# create new link library for pthread
ar cru $LIB_PTHREAD *.o
ranlib $LIB_PTHREAD 

# remove temporay files 
rm -f *.o



[-- Attachment #3: Type: text/plain, Size: 214 bytes --]

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

Re: duplicate regexec/regcomp functions detected

[Christopher Faylor]

On Thu, Dec 27, 2001 at 06:22:43PM +0100, Ralf Habacker wrote:
>> -----Original Message-----
>> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
>> Of Corinna Vinschen
>> Sent: Friday, December 14, 2001 11:36 AM
>> To: cygwin
>> Subject: Re: duplicate regexec/regcomp functions detected
>>
>>
>> On Thu, Dec 13, 2001 at 09:18:39PM +0100, Ralf Habacker wrote:
>> > Hi all,
>> >
>> > kde needs the regexp functions regexec and regcomp.
>> >
>> > The cygwin lib contains the System V8 function call style, while the pcre
>> package (pcreposix)
>> > provides another style (the system V style I guess). The problem is now, that both libs
>> > supports the same names for regexec and regcomp but with different
>> parameter/return types.
>> > This results sometimes in execution failures if the libs are not in the right order like
>> > shown in the following example.
>> >
>> > pcre regexp wanted
>> >
>> > $ gcc ... -lpcreposix -lcygwin   -> okay
>> >
>> > $ gcc ... -lpthreads|-lm|-lc -lpcreposix -lcygwin   -> failure: the functions in
>> cygwin lib
>> > are used
>>
>> But that order should never happen EXCEPT you're making the big
>> mistake to give `-lm' or `-lc' on the command line explicitly.
>> Since -lcygwin is appended automagically and libc.a and libm.a
>> are the same library anyway, the answer is simply, "Don't do that."
>
>This may be for -lm and -lc, but what about libpthread
>
>Think about this link line:
>
>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.

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/

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

>
> On Thu, Dec 27, 2001 at 06:22:43PM +0100, Ralf Habacker wrote:
> >> -----Original Message-----
> >> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> >> Of Corinna Vinschen
> >> Sent: Friday, December 14, 2001 11:36 AM
> >> To: cygwin
> >> Subject: Re: duplicate regexec/regcomp functions detected
> >>
> >>
> >> On Thu, Dec 13, 2001 at 09:18:39PM +0100, Ralf Habacker wrote:
> >> > Hi all,
> >> >
> >> > kde needs the regexp functions regexec and regcomp.
> >> >
> >> > The cygwin lib contains the System V8 function call style, while the pcre
> >> package (pcreposix)
> >> > provides another style (the system V style I guess). The problem is now, that
> both libs
> >> > supports the same names for regexec and regcomp but with different
> >> parameter/return types.
> >> > This results sometimes in execution failures if the libs are not in the right
> order like
> >> > shown in the following example.
> >> >
> >> > pcre regexp wanted
> >> >
> >> > $ gcc ... -lpcreposix -lcygwin   -> okay
> >> >
> >> > $ gcc ... -lpthreads|-lm|-lc -lpcreposix -lcygwin   -> failure: the functions in
> >> cygwin lib
> >> > are used
> >>
> >> But that order should never happen EXCEPT you're making the big
> >> mistake to give `-lm' or `-lc' on the command line explicitly.
> >> Since -lcygwin is appended automagically and libc.a and libm.a
> >> are the same library anyway, the answer is simply, "Don't do that."
> >
> >This may be for -lm and -lc, but what about libpthread
> >
> >Think about this link line:
> >
> >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 ?

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 ?

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 ?

Regards
Ralf

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


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

Re: duplicate regexec/regcomp functions detected

[Robert Collins]

----- Original Message -----
From: "Ralf Habacker" <Ralf.Habacker@freenet.de>

> > >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 ?
>
> Assume main.o needs to be linked to the pcreposix lib.
>
> gcc -o test main.o -lpthread -lpcreposix

Don't use -lpthread. Chris, can we please trash this symlink?

Rob


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

Re: duplicate regexec/regcomp functions detected

[Christopher Faylor]

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/

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

[-- Attachment #1: Type: text/plain, Size: 5200 bytes --]

> -----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 #2: Makefile.in.dif --]
[-- Type: application/octet-stream, Size: 2728 bytes --]

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/Makefile.in,v
retrieving revision 1.75
diff -u -b -B -p -r1.75 Makefile.in
--- Makefile.in 2001/12/26 05:02:07     1.75
+++ Makefile.in 2001/12/29 18:54:24
@@ -100,6 +100,9 @@ DLL_ENTRY:=@DLL_ENTRY@
 LIBGMON_A:=libgmon.a
 GMON_START:=gcrt0.o

+LIBPTHREAD_A:=libpthread.a
+
+
 # Some things want these from libc, but they have their own static
 # data which apps can get to, which is a pain in the dll, so we
 # include them directly into the library.
@@ -152,7 +155,7 @@ install_host=@install_host@

 all: all_target $(all_host)

-all_target: $(LIB_NAME) automode.o binmode.o textmode.o $(LIBGMON_A)
+all_target: $(LIB_NAME) automode.o binmode.o textmode.o $(LIBGMON_A) $(LIBPTHREAD_A)

 all_host: new-$(LIB_NAME) cygrun.exe

@@ -160,9 +163,9 @@ force:

 install: install-libs install-headers install-man $(install_host) $(install_target)

-install-libs: $(LIB_NAME)
+install-libs: $(LIB_NAME) $(LIBPTHREAD_A)
        $(INSTALL_DATA) new-$(DLL_NAME) $(bindir)/$(DLL_NAME); \
-       for i in $(LIB_NAME) $(GMON_START) $(LIBGMON_A) automode.o binmode.o textmode.o ; do \
+       for i in $(LIB_NAME) $(LIBPTHREAD_A) $(GMON_START) $(LIBGMON_A) automode.o binmode.o textmode.o; do \
            $(INSTALL_DATA) $$i $(tooldir)/lib/$$i ; \
        done

@@ -202,7 +205,8 @@ maintainer-clean realclean: clean


 # Rule to build cygwin.dll
-new-$(DLL_NAME): $(LDSCRIPT) $(DLL_OFILES) $(DEF_FILE) $(DLL_IMPORTS) $(LIBC) $(LIBM) Makefile winver_stamp
+new-$(DLL_NAME): $(LDSCRIPT) $(DLL_OFILES) $(DEF_FILE) $(DLL_IMPORTS) $(LIBC) $(LIBM) winver_stamp
+#new-$(DLL_NAME): $(LDSCRIPT) $(DLL_OFILES) $(DEF_FILE) $(DLL_IMPORTS) $(LIBC) $(LIBM) Makefile winver_stamp
        $(CXX) $(CXXFLAGS) -nostdlib -Wl,-T$(firstword $^) -Wl,--out-implib,cygdll.a -shared -o $@ \
        -e $(DLL_ENTRY) $(DEF_FILE) $(DLL_OFILES) version.o winver.o \
        $(DLL_IMPORTS) $(MALLOC_OBJ) $(LIBM) $(LIBC) \
@@ -213,6 +217,11 @@ $(LIB_NAME): rmsym newsym new-$(DLL_NAME
        /bin/sh ${word 1,$^} ./cygdll.a "$(NM)" "$(AR)" "$(RANLIB)" $(OBSOLETE_FUNCTIONS) || exit 0
        /bin/sh ${word 2,$^} ./cygdll.a "$(AS)" "$(AR)" "$(RANLIB)" $(NEW_FUNCTIONS) || exit 0
        (echo create $(LIB_NAME); echo addmod $(LIBCOS); echo addlib cygdll.a; echo save) | $(AR) -M
+
+# Rule to build lib_pthread.a
+$(LIBPTHREAD_A): speclib new-$(DLL_NAME)
+       /bin/sh ${word 1,$^} cygdll.a pthread.o $@ "$(NM)" "$(AR)" "$(RANLIB)" || exit 0
+       @echo create $(LIBPTHREAD_A)

 # Rule to make stub library used by testsuite
 # dependency set to $(LIB_NAME) to accommodate make -j2.

[-- Attachment #3: speclib --]
[-- Type: application/octet-stream, Size: 760 bytes --]

#!/bin/sh
#
# create specific link library for libpthread using symbols from libcygwin.a
# 
inlib=$1; shift
reflib=$1; shift
outlib=$1; shift
nm=$1; shift
ar=$1; shift
ranlib=$1; shift

tmpdir=slibtmp.dir

# awk script for extracing related object files 
SYMBOLS=`nm $reflib | grep "[TD] _" | gawk '{ print $3 }'`

SCRIPT='$1 ~ /^d00/ { file = $1; gsub(":","",file); }'

for i in $SYMBOLS; do 
	SCRIPT="$SCRIPT \$3 ~ /^$i/ { print file; }"
done

# remove previous link library 
rm -f $outlib

# extract related object files 
FILES=`$nm $PWD/$inlib | gawk "$SCRIPT"`
mkdir $tmpdir
cd $tmpdir
$ar x $PWD/$inlib $FILES
cd ..

# create new link library for pthread
$ar cru $PWD/$outlib $tmpdir/*.o
$ranlib $PWD/$outlib 

# remove temporay files 
rm -fr $tmpdir




[-- Attachment #4: Type: text/plain, Size: 214 bytes --]

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

Re: duplicate regexec/regcomp functions detected

[Christopher Faylor]

On Sat, Dec 29, 2001 at 07:58:49PM +0100, Ralf Habacker wrote:
>> 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.

So, complain to the qt authors.  You have done that, right?

Again, the above link line does not make sense.

I'm not going to waste my time making cygwin into an artifical
intelligence engine capable of figuring out every gaffe made by every
programmer in the world.

When you are porting software you often have to figure out system
dependencies.  Cygwin is no different from AIX, HP/UX, or linux in that
respect.

This is the one simple fact that seems to escape most of the people who
port software to cygwin.  Every variation of UNIX has its own quirks.
If one of Cygwin's quirks is that nonsensical gcc command lines don't
just silently do nothing, I think that's actually a good thing.

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

Thanks.  I'll look into this ASAP.

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/

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Christopher Faylor
> Sent: Sunday, December 30, 2001 2:39 AM
> To: cygwin@cygwin.com
> Subject: Re: duplicate regexec/regcomp functions detected
>
>
> On Sat, Dec 29, 2001 at 07:58:49PM +0100, Ralf Habacker wrote:
> >> 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.
>
> So, complain to the qt authors.  You have done that, right?

It will be in the next time, when I'm sure the qt release with threading supports works.

> Again, the above link line does not make sense.

It's a faulty example. It should look like this:

     gcc -o test main.o -lpthread [-lcygwin]

> I'm not going to waste my time making cygwin into an artifical
> intelligence engine capable of figuring out every gaffe made by every
> programmer in the world.
> When you are porting software you often have to figure out system
> dependencies.  Cygwin is no different from AIX, HP/UX, or linux in that
> respect.
> This is the one simple fact that seems to escape most of the people who
> port software to cygwin.  Every variation of UNIX has its own quirks.

Of course, but the things, that are in agreement with many os should be used, if this is
maintainable.
So providing a true pthread c and m lib should for me be such a way. Isn't it ?
Additional not only compilation tools things, but also api relevant things are relevant. KDE
2 is ported to the following os:

Caldera OpenLinux
Compaq Tru64
Conectiva Linux
Debian GNU/Linux
FreeBSD
Gentoo Linux
HPUX
IBM AIX
Mandrake Linux
LinuxFromScratch
LinuxPPC
MS Windows NT, 2000
NetBSD
OpenBSD
Polish(ed) Linux Distribution
RedHat Linux
Redmond Linux
SGI Irix
Slackware Linux
Sun Solaris
SuSE Linux
TurboLinux
Yellow Dog Linux

I have recognized some minor issues, that are handled not usually in cygwin. I will tell you
some examples:

- ':' in filenames - Many unix systems supports ':' in filenames, Windows not, this means
that every x11 related application, that uses the display environment var for creating
filenames has to be patched. This could be done in cygwin and this problem is solved forever.

- unix domain socket - The above mentioned os supports creating unix domain sockets with
previous existing files. On cygwin the unix domain sockets couldn't be bound on existing
files, so it has to be removed first.

- timezone variable
  Normaly the timezone variable can be referenced with "timezone" directly, in cygwin it must
be called
  "_timezone".

- In mostly os the third parameter of the ioctl call could be optionally left, in cygwin not.

  +#ifdef __CYGWIN__
  +    ioctl(seqfd,SNDCTL_SEQ_RESET,0);
  +#else
       ioctl(seqfd,SNDCTL_SEQ_RESET);
  +#endif

There may be some reasons not doing like this, I currently don't know, but I have recognized
this and now I'm telling about this :-)

> If one of Cygwin's quirks is that nonsensical gcc command lines don't
> just silently do nothing, I think that's actually a good thing.

I agree.
>
Ralf


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

Re: duplicate regexec/regcomp functions detected

[Christopher Faylor]

On Sun, Dec 30, 2001 at 02:18:56PM +0100, Ralf Habacker wrote:
>>Again, the above link line does not make sense.
>
>It's a faulty example. It should look like this:
>
>     gcc -o test main.o -lpthread [-lcygwin]

Ok.  I'm officially tired of this discussion now.  If we've been
arguing for three mail messages because you've botched an example
then I am bowing out after this.

>Of course, but the things, that are in agreement with many os should be
>used, if this is maintainable.  So providing a true pthread c and m lib
>should for me be such a way.  Isn't it ?  Additional not only
>compilation tools things, but also api relevant things are relevant.
>KDE 2 is ported to the following os:
>
>Caldera OpenLinux
>Compaq Tru64
>Conectiva Linux
>Debian GNU/Linux
>FreeBSD
>Gentoo Linux
>HPUX
>IBM AIX
>Mandrake Linux
>LinuxFromScratch
>LinuxPPC
>MS Windows NT, 2000
>NetBSD
>OpenBSD
>Polish(ed) Linux Distribution
>RedHat Linux
>Redmond Linux
>SGI Irix
>Slackware Linux
>Sun Solaris
>SuSE Linux
>TurboLinux
>Yellow Dog Linux

Don't you think that many of the above needed to have the configuration
tweaked before they worked?  Of course they did.  (And, also note that
the majority of the above examples are actually "linux".  That's not
a really inspiring accomplishment.)

If you modify the configuration and source code for KDE so that Cygwin
works then it will be added to the list.  That doesn't mean that you
should lobby Caldera to change SCO when you attempt an SCO UNIX port.

I'm not saying that we won't fix bugs in Cygwin but, again, I'm not
going to bend over backwards to make cygwin work better with broken
usages.  Now that you've apparently changed the whole basis for my
argument against qt's configury, there is little more that needs to
be said about this.

>I have recognized some minor issues, that are handled not usually in
>cygwin.  I will tell you some examples:
>
>- ':' in filenames - Many unix systems supports ':' in filenames,
>Windows not, this means that every x11 related application, that uses
>the display environment var for creating filenames has to be patched.
>This could be done in cygwin and this problem is solved forever.

Snort.  Sure, I'll fix this.  While I'm at it, I'll implement a true
fork() call, eliminate all of the CRLF line mode ending problems and
make programs recognize Windows syntax automatically.

>- unix domain socket - The above mentioned os supports creating unix
>domain sockets with previous existing files.  On cygwin the unix domain
>sockets couldn't be bound on existing files, so it has to be removed
>first.

Sounds like a bug.  Submit a patch.

>- timezone variable
>  Normaly the timezone variable can be referenced with "timezone" directly, in cygwin it must
>be called
>  "_timezone".

Why?  'timezone' is exported.

>- In mostly os the third parameter of the ioctl call could be optionally left, in cygwin not.
>
>  +#ifdef __CYGWIN__
>  +    ioctl(seqfd,SNDCTL_SEQ_RESET,0);
>  +#else
>       ioctl(seqfd,SNDCTL_SEQ_RESET);
>  +#endif
>
>There may be some reasons not doing like this, I currently don't know, but I have recognized
>this and now I'm telling about this :-)

Sounds like a bug.  Submit a patch.

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/

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Christopher Faylor
> Sent: Sunday, December 30, 2001 7:45 PM
> To: cygwin@cygwin.com
> Subject: Re: duplicate regexec/regcomp functions detected
>
>
> On Sun, Dec 30, 2001 at 02:18:56PM +0100, Ralf Habacker wrote:
> >>Again, the above link line does not make sense.
> >
> >It's a faulty example. It should look like this:
> >
> >     gcc -o test main.o -lpthread [-lcygwin]
>
> Ok.  I'm officially tired of this discussion now.  If we've been
> arguing for three mail messages because you've botched an example
> then I am bowing out after this.

I'm thinking about, what you are meaning. Could it be, that you don't recognized the [..] as
optional part ?
So the real line could be
    gcc -o test main.o -lpthread
or
    gcc -o test main.o -lpthread  -lcygwin


> >Of course, but the things, that are in agreement with many os should be
> >used, if this is maintainable.  So providing a true pthread c and m lib
> >should for me be such a way.  Isn't it ?  Additional not only
> >compilation tools things, but also api relevant things are relevant.
> >KDE 2 is ported to the following os:
> >
> >Caldera OpenLinux
> >Compaq Tru64
> >Conectiva Linux
> >Debian GNU/Linux
> >FreeBSD
> >Gentoo Linux
> >HPUX
> >IBM AIX
> >Mandrake Linux
> >LinuxFromScratch
> >LinuxPPC
> >MS Windows NT, 2000
> >NetBSD
> >OpenBSD
> >Polish(ed) Linux Distribution
> >RedHat Linux
> >Redmond Linux
> >SGI Irix
> >Slackware Linux
> >Sun Solaris
> >SuSE Linux
> >TurboLinux
> >Yellow Dog Linux
>
> Don't you think that many of the above needed to have the configuration
> tweaked before they worked?  Of course they did.  (And, also note that
> the majority of the above examples are actually "linux".  That's not
> a really inspiring accomplishment.)

I see about 8 or 9 real different os. Isn't this nothing ?
>
> If you modify the configuration and source code for KDE so that Cygwin
> works then it will be added to the list.  That doesn't mean that you
> should lobby Caldera to change SCO when you attempt an SCO UNIX port.
>
> I'm not saying that we won't fix bugs in Cygwin but, again, I'm not
> going to bend over backwards to make cygwin work better with broken
> usages.  Now that you've apparently changed the whole basis for my
> argument against qt's configury, there is little more that needs to
> be said about this.
>
> >I have recognized some minor issues, that are handled not usually in
> >cygwin.  I will tell you some examples:
> >
> >- ':' in filenames - Many unix systems supports ':' in filenames,
> >Windows not, this means that every x11 related application, that uses
> >the display environment var for creating filenames has to be patched.
> >This could be done in cygwin and this problem is solved forever.
>
> Snort.  Sure, I'll fix this.  While I'm at it, I'll implement a true
> fork() call, eliminate all of the CRLF line mode ending problems and
> make programs recognize Windows syntax automatically.
>
> >- unix domain socket - The above mentioned os supports creating unix
> >domain sockets with previous existing files.  On cygwin the unix domain
> >sockets couldn't be bound on existing files, so it has to be removed
> >first.
>
> Sounds like a bug.  Submit a patch.
>
I don't know, who has initial written this code. I think it was good, that someone with more
knowledge as I'm should  look at this for preventing side effects, I don't can see.

--- net.cc.orig Mon Dec 31 16:56:45 2001
+++ net.cc      Mon Dec 31 16:57:04 2001
@@ -1307,18 +1307,9 @@ cygwin_bind (int fd, const struct sockad
          sin.sin_port = ntohs (sin.sin_port);
          debug_printf ("AF_UNIX: socket bound to port %u", sin.sin_port);

-         /* bind must fail if file system socket object already exists
-            so _open () is called with O_EXCL flag. */
          fd = _open (un_addr->sun_path,
-                     O_WRONLY | O_CREAT | O_EXCL | O_BINARY,
+                     O_WRONLY | O_CREAT | O_BINARY,
                      0);
-
-         if (fd < 0)
-           {
-             if (get_errno () == EEXIST)
-               set_errno (EADDRINUSE);
-             goto out;
-           }

          sock->set_connect_secret ();


> >- timezone variable
> >  Normaly the timezone variable can be referenced with "timezone" directly, in
> cygwin it must
> >be called
> >  "_timezone".
>
> Why?  'timezone' is exported.
>
This is a part from /usr/include/time.h

#if timezonevar
#ifndef timezone
#define timezone ((long int) _timezone)
#endif
#else
char *_EXFUN(timezone, (void));
#endif

timezonevar is normally not defined, so timezone is a function with a char * return type,
which is not the expected return type (long int).

> >- In mostly os the third parameter of the ioctl call could be optionally left, in
> cygwin not.
> >
> >  +#ifdef __CYGWIN__
> >  +    ioctl(seqfd,SNDCTL_SEQ_RESET,0);
> >  +#else
> >       ioctl(seqfd,SNDCTL_SEQ_RESET);
> >  +#endif
> >
> >There may be some reasons not doing like this, I currently don't know, but I have
> recognized
> >this and now I'm telling about this :-)
>
> Sounds like a bug.  Submit a patch.
>
Later
> 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/
>
>


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

Re: duplicate regexec/regcomp functions detected

[Corinna Vinschen]

On Mon, Dec 31, 2001 at 07:53:28PM +0100, Ralf Habacker wrote:
> > >- unix domain socket - The above mentioned os supports creating unix
> > >domain sockets with previous existing files.  On cygwin the unix domain
> > >sockets couldn't be bound on existing files, so it has to be removed
> > >first.
> >
> > Sounds like a bug.  Submit a patch.

It's not a bug, it's Linux compliant behaviour.  Try the following
code on Linux and Cygwin:

================================== SNIP ==============================
#include <stdio.h>
#include <errno.h>
#include <sys/socket.h>
#include <sys/un.h>

int
main(int argc, char **argv)
{
  int sockfd;
  socklen_t len;
  struct sockaddr_un addr1, addr2;

  if (argc != 2)
    {
      fprintf (stderr, "Idiot\n");
      return 1;
    }
  sockfd = socket (AF_LOCAL, SOCK_STREAM, 0);
  if (sockfd < 0)
    {
      fprintf (stderr, "socket: %d, %s\n", errno, strerror (errno));
      return 1;
    }
  memset (&addr1, 0, sizeof addr1);
  addr1.sun_family = AF_LOCAL;
  strncpy (addr1.sun_path, argv[1], sizeof addr1.sun_path - 1);
  if (bind (sockfd, (struct sockaddr *) &addr1, SUN_LEN (&addr1)) < 0)
    {
      fprintf (stderr, "bind: %d, %s\n", errno, strerror (errno));
      return 1;
    }
  len = sizeof addr2;
  if (getsockname (sockfd, (struct sockaddr *) &addr2, &len) < 0)
    {
      fprintf (stderr, "getsockname: %d, %s\n", errno, strerror (errno));
      return 1;
    }
  printf ("bound name = %s, returned len = %d\n", addr2.sun_path, len);
  return 0;
}
================================== SNAP ==============================

Linux:
------
$ gcc -o uds uds.c
$ ./uds /tmp/foo.bar
bound name = /tmp/foo.bar, returned len = 15
$ ./uds /tmp/foo.bar
bind: 98, Address already in use

Cygwin:
-------
$ gcc -o uds uds.c
$ ./uds /tmp/foo.bar
bound name = <some random string here>, returned len = 16
$ ./uds /tmp/foo.bar
bind: 112, Address already in use

That shows that Cygwin's getsockname() doesn't return a correct
sockname for unix domain sockets but the bind() call behaves
correct.  An application that depends on (actually undocumented)
behaviour that a unix domain socket can be rebound is doing something
wrong.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

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

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Corinna Vinschen
> Sent: Tuesday, January 01, 2002 4:07 PM
> To: cygwin@cygwin.com
> Subject: Re: duplicate regexec/regcomp functions detected
>
>
> On Mon, Dec 31, 2001 at 07:53:28PM +0100, Ralf Habacker wrote:
> > > >- unix domain socket - The above mentioned os supports creating unix
> > > >domain sockets with previous existing files.  On cygwin the unix domain
> > > >sockets couldn't be bound on existing files, so it has to be removed
> > > >first.
> > >
> > > Sounds like a bug.  Submit a patch.
>
> It's not a bug, it's Linux compliant behaviour.  Try the following
> code on Linux and Cygwin:
>
> ================================== SNIP ==============================
> #include <stdio.h>
> #include <errno.h>
> #include <sys/socket.h>
> #include <sys/un.h>
>
> int
> main(int argc, char **argv)
> {
>   int sockfd;
>   socklen_t len;
>   struct sockaddr_un addr1, addr2;
>
>   if (argc != 2)
>     {
>       fprintf (stderr, "Idiot\n");
>       return 1;
>     }
>   sockfd = socket (AF_LOCAL, SOCK_STREAM, 0);
>   if (sockfd < 0)
>     {
>       fprintf (stderr, "socket: %d, %s\n", errno, strerror (errno));
>       return 1;
>     }
>   memset (&addr1, 0, sizeof addr1);
>   addr1.sun_family = AF_LOCAL;
>   strncpy (addr1.sun_path, argv[1], sizeof addr1.sun_path - 1);
>   if (bind (sockfd, (struct sockaddr *) &addr1, SUN_LEN (&addr1)) < 0)
>     {
>       fprintf (stderr, "bind: %d, %s\n", errno, strerror (errno));
>       return 1;
>     }
>   len = sizeof addr2;
>   if (getsockname (sockfd, (struct sockaddr *) &addr2, &len) < 0)
>     {
>       fprintf (stderr, "getsockname: %d, %s\n", errno, strerror (errno));
>       return 1;
>     }
>   printf ("bound name = %s, returned len = %d\n", addr2.sun_path, len);
>   return 0;
> }
> ================================== SNAP ==============================
>
> Linux:
> ------
> $ gcc -o uds uds.c
> $ ./uds /tmp/foo.bar
> bound name = /tmp/foo.bar, returned len = 15
> $ ./uds /tmp/foo.bar
> bind: 98, Address already in use
>
> Cygwin:
> -------
> $ gcc -o uds uds.c
> $ ./uds /tmp/foo.bar
> bound name = <some random string here>, returned len = 16
> $ ./uds /tmp/foo.bar
> bind: 112, Address already in use
>
> That shows that Cygwin's getsockname() doesn't return a correct
> sockname for unix domain sockets but the bind() call behaves
> correct.  An application that depends on (actually undocumented)
> behaviour that a unix domain socket can be rebound is doing something
> wrong.

Thanks for this hints. While porting kdelibs I have had to explicity closed and delete the
socket file before I can bound to it (which wasn't used under other ported os) and as I found
the decribed code in the bind() function, the first thoughts was that this may be the
problem. After this correction I will look at the kde code to identify the called functions.
Perhaps the problem is the getsockname().

After looking in the code I have an additional question. Does cygwin and linux differs in the
possibilites of deleting of open files ? This could be a difference, because I have found
that before binding an unlink() is made, but fails.

Ralf



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

Re: duplicate regexec/regcomp functions detected

[Corinna Vinschen]

On Wed, Jan 02, 2002 at 12:57:25AM +0100, Ralf Habacker wrote:
> Thanks for this hints. While porting kdelibs I have had to explicity closed and delete the
> socket file before I can bound to it (which wasn't used under other ported os) and as I found
> the decribed code in the bind() function, the first thoughts was that this may be the
> problem. After this correction I will look at the kde code to identify the called functions.
> Perhaps the problem is the getsockname().

I have checked in a fix to getsockname() to return the correct result
for AF_LOCAL/AF_UNIX sockets as well.  You can find it in the current
sources from CVS.

> After looking in the code I have an additional question. Does cygwin and linux differs in the
> possibilites of deleting of open files ? This could be a difference, because I have found
> that before binding an unlink() is made, but fails.

The usual Win32/Posix difference:  You can't unlink a file on Win32
which is still in use.

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

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

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Corinna Vinschen
> Sent: Wednesday, January 02, 2002 11:05 AM
> To: Cygwin
> Subject: Re: duplicate regexec/regcomp functions detected
>
>
> On Wed, Jan 02, 2002 at 12:57:25AM +0100, Ralf Habacker wrote:
> > Thanks for this hints. While porting kdelibs I have had to explicity closed and
> delete the
> > socket file before I can bound to it (which wasn't used under other ported os)
> and as I found
> > the decribed code in the bind() function, the first thoughts was that this may be the
> > problem. After this correction I will look at the kde code to identify the
> called functions.
> > Perhaps the problem is the getsockname().
>
> I have checked in a fix to getsockname() to return the correct result
> for AF_LOCAL/AF_UNIX sockets as well.  You can find it in the current
> sources from CVS.
>
> > After looking in the code I have an additional question. Does cygwin and linux
> differs in the
> > possibilites of deleting of open files ? This could be a difference, because I have found
> > that before binding an unlink() is made, but fails.
>
> The usual Win32/Posix difference:  You can't unlink a file on Win32
> which is still in use.

That's it. Thanks

> Corinna
>
> --
> Corinna Vinschen                  Please, send mails regarding Cygwin to
> Cygwin Developer                                mailto:cygwin@cygwin.com
> Red Hat, Inc.
>
> --
> 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/
>
>


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

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

 
> 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 
		... ups, this sentence should have an end  .... 
that the error message was not expected. :-) 

Regards 
Ralf 


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

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

[-- Attachment #1: Type: text/plain, Size: 768 bytes --]

Ralf Habacker wrote
>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.

I have recognized yet a little problem with the speclib script. I have checked this from the
cygwin build dir without any errors. If someone was in the winsup dir and does a make cygwin
or make, than some command in speclib does not found the input files. The problem is that ar
does not have an -o option for an output dir, so the hack to emulate that does not work.
Perhaps it is better to use the absolute path of the input library, but currently I have no
idea, how to solve this. :-(
Perhaps anyone else have an idea ?

speclib

...
cd $tmpdir
$ar x $PWD/$inlib $FILES
cd ..
...

Regards
Ralf

[-- Attachment #2: Makefile.in.dif --]
[-- Type: application/octet-stream, Size: 2728 bytes --]

Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/winsup/cygwin/Makefile.in,v
retrieving revision 1.75
diff -u -b -B -p -r1.75 Makefile.in
--- Makefile.in 2001/12/26 05:02:07     1.75
+++ Makefile.in 2001/12/29 18:54:24
@@ -100,6 +100,9 @@ DLL_ENTRY:=@DLL_ENTRY@
 LIBGMON_A:=libgmon.a
 GMON_START:=gcrt0.o

+LIBPTHREAD_A:=libpthread.a
+
+
 # Some things want these from libc, but they have their own static
 # data which apps can get to, which is a pain in the dll, so we
 # include them directly into the library.
@@ -152,7 +155,7 @@ install_host=@install_host@

 all: all_target $(all_host)

-all_target: $(LIB_NAME) automode.o binmode.o textmode.o $(LIBGMON_A)
+all_target: $(LIB_NAME) automode.o binmode.o textmode.o $(LIBGMON_A) $(LIBPTHREAD_A)

 all_host: new-$(LIB_NAME) cygrun.exe

@@ -160,9 +163,9 @@ force:

 install: install-libs install-headers install-man $(install_host) $(install_target)

-install-libs: $(LIB_NAME)
+install-libs: $(LIB_NAME) $(LIBPTHREAD_A)
        $(INSTALL_DATA) new-$(DLL_NAME) $(bindir)/$(DLL_NAME); \
-       for i in $(LIB_NAME) $(GMON_START) $(LIBGMON_A) automode.o binmode.o textmode.o ; do \
+       for i in $(LIB_NAME) $(LIBPTHREAD_A) $(GMON_START) $(LIBGMON_A) automode.o binmode.o textmode.o; do \
            $(INSTALL_DATA) $$i $(tooldir)/lib/$$i ; \
        done

@@ -202,7 +205,8 @@ maintainer-clean realclean: clean


 # Rule to build cygwin.dll
-new-$(DLL_NAME): $(LDSCRIPT) $(DLL_OFILES) $(DEF_FILE) $(DLL_IMPORTS) $(LIBC) $(LIBM) Makefile winver_stamp
+new-$(DLL_NAME): $(LDSCRIPT) $(DLL_OFILES) $(DEF_FILE) $(DLL_IMPORTS) $(LIBC) $(LIBM) winver_stamp
+#new-$(DLL_NAME): $(LDSCRIPT) $(DLL_OFILES) $(DEF_FILE) $(DLL_IMPORTS) $(LIBC) $(LIBM) Makefile winver_stamp
        $(CXX) $(CXXFLAGS) -nostdlib -Wl,-T$(firstword $^) -Wl,--out-implib,cygdll.a -shared -o $@ \
        -e $(DLL_ENTRY) $(DEF_FILE) $(DLL_OFILES) version.o winver.o \
        $(DLL_IMPORTS) $(MALLOC_OBJ) $(LIBM) $(LIBC) \
@@ -213,6 +217,11 @@ $(LIB_NAME): rmsym newsym new-$(DLL_NAME
        /bin/sh ${word 1,$^} ./cygdll.a "$(NM)" "$(AR)" "$(RANLIB)" $(OBSOLETE_FUNCTIONS) || exit 0
        /bin/sh ${word 2,$^} ./cygdll.a "$(AS)" "$(AR)" "$(RANLIB)" $(NEW_FUNCTIONS) || exit 0
        (echo create $(LIB_NAME); echo addmod $(LIBCOS); echo addlib cygdll.a; echo save) | $(AR) -M
+
+# Rule to build lib_pthread.a
+$(LIBPTHREAD_A): speclib new-$(DLL_NAME)
+       /bin/sh ${word 1,$^} cygdll.a pthread.o $@ "$(NM)" "$(AR)" "$(RANLIB)" || exit 0
+       @echo create $(LIBPTHREAD_A)

 # Rule to make stub library used by testsuite
 # dependency set to $(LIB_NAME) to accommodate make -j2.

[-- Attachment #3: speclib --]
[-- Type: application/octet-stream, Size: 760 bytes --]

#!/bin/sh
#
# create specific link library for libpthread using symbols from libcygwin.a
# 
inlib=$1; shift
reflib=$1; shift
outlib=$1; shift
nm=$1; shift
ar=$1; shift
ranlib=$1; shift

tmpdir=slibtmp.dir

# awk script for extracing related object files 
SYMBOLS=`nm $reflib | grep "[TD] _" | gawk '{ print $3 }'`

SCRIPT='$1 ~ /^d00/ { file = $1; gsub(":","",file); }'

for i in $SYMBOLS; do 
	SCRIPT="$SCRIPT \$3 ~ /^$i/ { print file; }"
done

# remove previous link library 
rm -f $outlib

# extract related object files 
FILES=`$nm $PWD/$inlib | gawk "$SCRIPT"`
mkdir $tmpdir
cd $tmpdir
$ar x $PWD/$inlib $FILES
cd ..

# create new link library for pthread
$ar cru $PWD/$outlib $tmpdir/*.o
$ranlib $PWD/$outlib 

# remove temporay files 
rm -fr $tmpdir




[-- Attachment #4: Type: text/plain, Size: 214 bytes --]

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

Re: duplicate regexec/regcomp functions detected

[Christopher Faylor]

On Sat, Dec 29, 2001 at 08:21:43PM +0100, Ralf Habacker wrote:
>Ralf Habacker wrote
>>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.
>
>I have recognized yet a little problem with the speclib script. I have checked this from the
>cygwin build dir without any errors. If someone was in the winsup dir and does a make cygwin
>or make, than some command in speclib does not found the input files. The problem is that ar
>does not have an -o option for an output dir, so the hack to emulate that does not work.
>Perhaps it is better to use the absolute path of the input library, but currently I have no
>idea, how to solve this. :-(
>Perhaps anyone else have an idea ?
>
>speclib
>
>...
>cd $tmpdir
>$ar x $PWD/$inlib $FILES
>cd ..
>...

I don't know if this helps bug can I suggest an alternate approach?  Use
cygwin.din to derive your list of files and do something like:

$(LIBPTHREAD_A): speclib new-$(DLL_NAME) cygwin.din pthread.o thread.o
	/bin/sh ${word 1,$^} $@  "$(NM)" "$(AR)" "$(RANLIB)" ${wordlist 3, 99, $^}

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/

Re: duplicate regexec/regcomp functions detected

[Christopher Faylor]

On Sun, Dec 30, 2001 at 02:37:23PM -0500, Christopher Faylor wrote:
>On Sat, Dec 29, 2001 at 08:21:43PM +0100, Ralf Habacker wrote:
>>Ralf Habacker wrote
>>>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.
>>
>>I have recognized yet a little problem with the speclib script. I have checked this from the
>>cygwin build dir without any errors. If someone was in the winsup dir and does a make cygwin
>>or make, than some command in speclib does not found the input files. The problem is that ar
>>does not have an -o option for an output dir, so the hack to emulate that does not work.
>>Perhaps it is better to use the absolute path of the input library, but currently I have no
>>idea, how to solve this. :-(
>>Perhaps anyone else have an idea ?
>>
>>speclib
>>
>>...
>>cd $tmpdir
>>$ar x $PWD/$inlib $FILES
>>cd ..
>>...
>
>I don't know if this helps bug can I suggest an alternate approach?  Use
>cygwin.din to derive your list of files and do something like:
>
>$(LIBPTHREAD_A): speclib new-$(DLL_NAME) cygwin.din pthread.o thread.o
                                          ^^^^^^^^^^
                                          cygwin.def

cgf

>	/bin/sh ${word 1,$^} $@  "$(NM)" "$(AR)" "$(RANLIB)" ${wordlist 3, 99, $^}

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

Re: duplicate regexec/regcomp functions detected

[Christopher Faylor]

On Sun, Dec 30, 2001 at 02:56:43PM -0500, Christopher Faylor wrote:
>On Sun, Dec 30, 2001 at 02:37:23PM -0500, Christopher Faylor wrote:
>>On Sat, Dec 29, 2001 at 08:21:43PM +0100, Ralf Habacker wrote:
>>>Ralf Habacker wrote
>>>>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.
>>>
>>>I have recognized yet a little problem with the speclib script. I have checked this from the
>>>cygwin build dir without any errors. If someone was in the winsup dir and does a make cygwin
>>>or make, than some command in speclib does not found the input files. The problem is that ar
>>>does not have an -o option for an output dir, so the hack to emulate that does not work.
>>>Perhaps it is better to use the absolute path of the input library, but currently I have no
>>>idea, how to solve this. :-(
>>>Perhaps anyone else have an idea ?
>>>
>>>speclib
>>>
>>>...
>>>cd $tmpdir
>>>$ar x $PWD/$inlib $FILES
>>>cd ..
>>>...
>>
>>I don't know if this helps bug can I suggest an alternate approach?  Use
>>cygwin.din to derive your list of files and do something like:
>>
>>$(LIBPTHREAD_A): speclib new-$(DLL_NAME) cygwin.din pthread.o thread.o
>                                          ^^^^^^^^^^
>                                          cygwin.def

I've actually adapted a shell script to do what I mentioned above.  It
seemed simpler than waiting for the timezone communication lag.  Thanks
for the initial idea and implementation.

I'll have something in tonight's snapshot.

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/

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Christopher Faylor
> Sent: Sunday, December 30, 2001 8:37 PM
> To: cygwin@cygwin.com
> Subject: Re: duplicate regexec/regcomp functions detected
>
>
> On Sat, Dec 29, 2001 at 08:21:43PM +0100, Ralf Habacker wrote:
> >Ralf Habacker wrote
> >>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.
> >
> >I have recognized yet a little problem with the speclib script. I have checked
> this from the
> >cygwin build dir without any errors. If someone was in the winsup dir and does a
> make cygwin
> >or make, than some command in speclib does not found the input files. The problem
> is that ar
> >does not have an -o option for an output dir, so the hack to emulate that does not work.
> >Perhaps it is better to use the absolute path of the input library, but currently
> I have no
> >idea, how to solve this. :-(
> >Perhaps anyone else have an idea ?
> >
> >speclib
> >
> >...
> >cd $tmpdir
> >$ar x $PWD/$inlib $FILES
> >cd ..
> >...
>
> I don't know if this helps bug can I suggest an alternate approach?  Use
> cygwin.din to derive your list of files and do something like:
>
> $(LIBPTHREAD_A): speclib new-$(DLL_NAME) cygwin.din pthread.o thread.o
> 	/bin/sh ${word 1,$^} $@  "$(NM)" "$(AR)" "$(RANLIB)" ${wordlist 3, 99, $^}
>
>
That means, that libpthread contains all symbols of cygwin.dll and not only the symbols from
pthread, which are published in pthread.h ? Does libpthread should only contain pthread
relates symbols ?

Ralf


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

Re: duplicate regexec/regcomp functions detected

[Christopher Faylor]

On Mon, Dec 31, 2001 at 10:28:52AM +0100, Ralf Habacker wrote:
>> -----Original Message-----
>> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
>> Of Christopher Faylor
>> Sent: Sunday, December 30, 2001 8:37 PM
>> To: cygwin@cygwin.com
>> Subject: Re: duplicate regexec/regcomp functions detected
>>
>>
>> On Sat, Dec 29, 2001 at 08:21:43PM +0100, Ralf Habacker wrote:
>> >Ralf Habacker wrote
>> >>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.
>> >
>> >I have recognized yet a little problem with the speclib script. I have checked
>> this from the
>> >cygwin build dir without any errors. If someone was in the winsup dir and does a
>> make cygwin
>> >or make, than some command in speclib does not found the input files. The problem
>> is that ar
>> >does not have an -o option for an output dir, so the hack to emulate that does not work.
>> >Perhaps it is better to use the absolute path of the input library, but currently
>> I have no
>> >idea, how to solve this. :-(
>> >Perhaps anyone else have an idea ?
>> >
>> >speclib
>> >
>> >...
>> >cd $tmpdir
>> >$ar x $PWD/$inlib $FILES
>> >cd ..
>> >...
>>
>> I don't know if this helps bug can I suggest an alternate approach?  Use
>> cygwin.din to derive your list of files and do something like:
>>
>> $(LIBPTHREAD_A): speclib new-$(DLL_NAME) cygwin.din pthread.o thread.o
>> 	/bin/sh ${word 1,$^} $@  "$(NM)" "$(AR)" "$(RANLIB)" ${wordlist 3, 99, $^}
>>
>>
>That means, that libpthread contains all symbols of cygwin.dll and not only the symbols from
>pthread, which are published in pthread.h ? Does libpthread should only contain pthread
>relates symbols ?

Why would you infer that?  You ran 'nm' over cygdll.a.  Does that mean that all of the
symbols from cygdll.a were part of libpthread.a?

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/

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Christopher Faylor
> Sent: Monday, December 31, 2001 6:18 PM
> To: cygwin@cygwin.com
> Subject: Re: duplicate regexec/regcomp functions detected
> 
> 
> On Mon, Dec 31, 2001 at 10:28:52AM +0100, Ralf Habacker wrote:
> >> -----Original Message-----
> >> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> >> Of Christopher Faylor
> >> Sent: Sunday, December 30, 2001 8:37 PM
> >> To: cygwin@cygwin.com
> >> Subject: Re: duplicate regexec/regcomp functions detected
> >>
> >>
> >> On Sat, Dec 29, 2001 at 08:21:43PM +0100, Ralf Habacker wrote:
> >> >Ralf Habacker wrote
> >> >>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.
> >> >
> >> >I have recognized yet a little problem with the speclib script. I have checked
> >> this from the
> >> >cygwin build dir without any errors. If someone was in the winsup dir and does a
> >> make cygwin
> >> >or make, than some command in speclib does not found the input files. The problem
> >> is that ar
> >> >does not have an -o option for an output dir, so the hack to emulate that does 
> not work.
> >> >Perhaps it is better to use the absolute path of the input library, but currently
> >> I have no
> >> >idea, how to solve this. :-(
> >> >Perhaps anyone else have an idea ?
> >> >
> >> >speclib
> >> >
> >> >...
> >> >cd $tmpdir
> >> >$ar x $PWD/$inlib $FILES
> >> >cd ..
> >> >...
> >>
> >> I don't know if this helps bug can I suggest an alternate approach?  Use
> >> cygwin.din to derive your list of files and do something like:
> >>
> >> $(LIBPTHREAD_A): speclib new-$(DLL_NAME) cygwin.din pthread.o thread.o
> >> 	/bin/sh ${word 1,$^} $@  "$(NM)" "$(AR)" "$(RANLIB)" ${wordlist 3, 99, $^}
> >>
> >>
> >That means, that libpthread contains all symbols of cygwin.dll and not only the 
> symbols from
> >pthread, which are published in pthread.h ? Does libpthread should only contain pthread
> >relates symbols ?
> 
> Why would you infer that?  You ran 'nm' over cygdll.a.  Does that mean that all of the
> symbols from cygdll.a were part of libpthread.a?
> 
No, only the symbols, which are defined in pthread.o, called the "reflib" in speclib. 

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

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

Re: duplicate regexec/regcomp functions detected

[Christopher Faylor]

On Mon, Dec 31, 2001 at 07:59:15PM +0100, Ralf Habacker wrote:
>> Why would you infer that?  You ran 'nm' over cygdll.a.  Does that mean that all of the
>> symbols from cygdll.a were part of libpthread.a?
>> 
>No, only the symbols, which are defined in pthread.o, called the "reflib" in speclib. 

And why couldn't you do the same thing with cygwin.din?

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/

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

> From: "Ralf Habacker" <Ralf.Habacker@freenet.de>
> >
> > No, only the symbols, which are defined in pthread.o, called the
> "reflib" in speclib.
>
> That will be an incomplete list of symbols then, as I've been removing
> them from pthread.o - there is (a minor) performance hit with the
> redirection, and the pthread functions tend to be part of the critical
> performance path when they are used.
>
No I'm recognized, that we are speaking about two different things. May be that I have
doesn't told clearly enough, so I like to resume.

At first I'm stumbled about the curious link line with the multiple defined main in the qt
lib, chris and I have spoken over.

After thinking about this problem a while I had an idea how to solve such problems instead of
using simple links from libcygwin.a to libpthread.a and other.
The idea was to use the cygwin1.dll as used currently, but to build only several import libs
(!) for special libs like libpthread and may me libm and libc.

The advantage of doing this is, this allows a very flexible way of using. Someone could use
the libcygwin.a for all needs functions regardless if they original belongs to libc libm or
libpthread.
Someone how like to use libpthread, libm, libc and may be other can use the belonging import
libraries (remember not the function or vars, the functions are located in cygwin1.dll) and
can link.

A second advantage of this concept is, that if there is a future need to split some functions
from cygwin1.dll to a seperate dll or static lib, the import libraries, which the users are
link to, are the same as now.  Only the backend was changed. This simplificates further
development of the whole emulation layer without and noticable changes to the user (except an
new compiling)

So the concept has a two level structure. The top level are the import libraries, the bottom
level are one or more dll's and perhaps static lib.

The task for doing so (for libpthread) is to look which functions of the pthread library are
exported (decribed in pthread.h and relating headers, but I think it is only the one). This
is done by scanning  pthread.o with nm for every exported symbol. (The consequence for this
is, that only this symbols are has to be exported)

Then search cygdll.a after those symbols and extract only the relevant d000xxx.o from
cygdll.a to a newly created import library named libpthread.a or other revelant name.

Doing like this (extraxting d000xxx-files from cygdll) has an extra advantage relating to the
auto-import feature. If cygwin1.dll perhaps contains auto-imported vars, than using the
d0000xxx files extract the import thunks too and there is no need to change this concept.

The patch I have supplied, does exactly this and seems to me ready with the on exception of
locating file dirs (identifiable on "$PWD.."), i have told about.

speclib
-----------------------------------------------------------------------------
#!/bin/sh
#
# create specific link library for libpthread using symbols from libcygwin.a
#
inlib=$1; shift		# cygdll.a
reflib=$1; shift		# pthread.o
outlib=$1; shift		# libpthread.a
nm=$1; shift
ar=$1; shift
ranlib=$1; shift

tmpdir=slibtmp.dir

# collect needed symbols
SYMBOLS=`nm $reflib | grep "[TD] _" | gawk '{ print $3 }'`

# build awk script to extract d000xxx files
SCRIPT='$1 ~ /^d00/ { file = $1; gsub(":","",file); }'

for i in $SYMBOLS; do
	SCRIPT="$SCRIPT \$3 ~ /^$i/ { print file; }"
done

# remove previous link library
rm -f $outlib

# collect all d000xxx files from $inlib (cygdll.a)
FILES=`$nm $PWD/$inlib | gawk "$SCRIPT"`

# extract related object files
mkdir $tmpdir
cd $tmpdir
$ar x $PWD/$inlib $FILES
cd ..

# create new link library for pthread
$ar cru $PWD/$outlib $tmpdir/*.o
$ranlib $PWD/$outlib

# remove temporay files
rm -fr $tmpdir
-----------------------------------------------------------------------------

I hope I have written clearly enough and I'm sorry for an confusion, I'm responsible. So if
there an questions, please let me know.

BTW: I wish you all a happy new year.

Regards
Ralf



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

Re: duplicate regexec/regcomp functions detected

[Christopher Faylor]

On Tue, Jan 01, 2002 at 03:24:49PM +0100, Ralf Habacker wrote:
>After thinking about this problem a while I had an idea how to solve
>such problems instead of using simple links from libcygwin.a to
>libpthread.a and other.  The idea was to use the cygwin1.dll as used
>currently, but to build only several import libs (!) for special libs
>like libpthread and may me libm and libc.

Yes.  I had misgivings about this idea when you first mentioned it but
on reflection, I really think that this is a very good idea and, so,
have implemented it.  The change is in CVS, as I've mentioned.  As I
mentioned, I used roughly your technique to accomplish this goal.

>The task for doing so (for libpthread) is to look which functions of
>the pthread library are exported (decribed in pthread.h and relating
>headers, but I think it is only the one).  This is done by scanning
>pthread.o with nm for every exported symbol.  (The consequence for this
>is, that only this symbols are has to be exported)
>
>Then search cygdll.a after those symbols and extract only the relevant
>d000xxx.o from cygdll.a to a newly created import library named
>libpthread.a or other revelant name.

And, here is where I don't understand your confusion.  You don't need to
search cygdll.a.  You already have a text file available to you which
contains all of the exports from the cygwin DLL -- cygwin.def.

I was suggesting that you could use this.

I guess if this still isn't clear we'll just have to move on since it's
already implemented.

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/

Re: duplicate regexec/regcomp functions detected

[Corinna Vinschen]

On Tue, Jan 01, 2002 at 11:59:21AM -0500, Chris Faylor wrote:
> On Tue, Jan 01, 2002 at 03:24:49PM +0100, Ralf Habacker wrote:
> >Then search cygdll.a after those symbols and extract only the relevant
> >d000xxx.o from cygdll.a to a newly created import library named
> >libpthread.a or other revelant name.
> 
> And, here is where I don't understand your confusion.  You don't need to
> search cygdll.a.  You already have a text file available to you which
> contains all of the exports from the cygwin DLL -- cygwin.def.

Which results in some missing symbols in libc.a, namely the symbols
from $(LIBCOS).  The change to have different link libs have let me
think that we could drop -lcygwin from the gcc specs file in favour
of -lc.  But that's impossible w/o $(LIBCOS) linked to libc.a.  Did
I missunderstood something here?

Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Developer                                mailto:cygwin@cygwin.com
Red Hat, Inc.

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

Re: duplicate regexec/regcomp functions detected

[Christopher Faylor]

On Tue, Jan 01, 2002 at 06:52:07PM +0100, Corinna Vinschen wrote:
>On Tue, Jan 01, 2002 at 11:59:21AM -0500, Chris Faylor wrote:
>> On Tue, Jan 01, 2002 at 03:24:49PM +0100, Ralf Habacker wrote:
>> >Then search cygdll.a after those symbols and extract only the relevant
>> >d000xxx.o from cygdll.a to a newly created import library named
>> >libpthread.a or other revelant name.
>> 
>> And, here is where I don't understand your confusion.  You don't need to
>> search cygdll.a.  You already have a text file available to you which
>> contains all of the exports from the cygwin DLL -- cygwin.def.
>
>Which results in some missing symbols in libc.a, namely the symbols
>from $(LIBCOS).  The change to have different link libs have let me
>think that we could drop -lcygwin from the gcc specs file in favour
>of -lc.  But that's impossible w/o $(LIBCOS) linked to libc.a.  Did
>I missunderstood something here?

Yes.  We're not dropping libcygwin.a in favor of libc.a.

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/

RE: duplicate regexec/regcomp functions detected

[Ralf Habacker]

> -----Original Message-----
> From: cygwin-owner@cygwin.com [mailto:cygwin-owner@cygwin.com]On Behalf
> Of Christopher Faylor
> Sent: Tuesday, January 01, 2002 5:59 PM
> To: cygwin@cygwin.com
> Subject: Re: duplicate regexec/regcomp functions detected
>
>
> On Tue, Jan 01, 2002 at 03:24:49PM +0100, Ralf Habacker wrote:
> >After thinking about this problem a while I had an idea how to solve
> >such problems instead of using simple links from libcygwin.a to
> >libpthread.a and other.  The idea was to use the cygwin1.dll as used
> >currently, but to build only several import libs (!) for special libs
> >like libpthread and may me libm and libc.
>
> Yes.  I had misgivings about this idea when you first mentioned it but
> on reflection, I really think that this is a very good idea and, so,
> have implemented it.  The change is in CVS, as I've mentioned.  As I
> mentioned, I used roughly your technique to accomplish this goal.
>
> >The task for doing so (for libpthread) is to look which functions of
> >the pthread library are exported (decribed in pthread.h and relating
> >headers, but I think it is only the one).  This is done by scanning
> >pthread.o with nm for every exported symbol.  (The consequence for this
> >is, that only this symbols are has to be exported)
> >
> >Then search cygdll.a after those symbols and extract only the relevant
> >d000xxx.o from cygdll.a to a newly created import library named
> >libpthread.a or other revelant name.
>
> And, here is where I don't understand your confusion.  You don't need to
> search cygdll.a.  You already have a text file available to you which
> contains all of the exports from the cygwin DLL -- cygwin.def.

There is a difference. How does the process for integrating libs in cygwin goes on ?
Let me explain this for example with the libm. From anywhere (in this case from newlib) there
comes a static lib named libm.a build of several object files . The symbols of this lib were
used in cxgwin.din/def to export symbol in cygwin1.dll. But this file contains all symbols
from every lib, which is integrated in the cygwin dll. So if one uses the cygwin.def as
symbol list to extract the relating d000xxx files from cygdll.a to create for example the
libm import library, the import library contains all exported symbols and not only the ones
from the original libm.a.

But I think the libm import library should only contains the libm related symbols and this
seems to me true for all other in this way builded libs.

Because of this strategy I'm using the second parameter ($reflib) in speclib to the original
static lib like libm.a or for example objectfile pthread.o to get only the lib relating
symbols.

Thats the reason why I'm using speclib in the below mentioned way.

Makefile.in:
...
/bin/sh speclib cygdll.a ../newlib/libm.a libm.a "$(NM)" "$(AR)" "$(RANLIB)" || exit 0

In words: scan ../newlib/libm.a to get all exported symbols and than extract all object files
from cygdll.a to create the partially import library libm.a

for libpthread.a

/bin/sh speclib cygdll.a pthread.o libpthread.a "$(NM)" "$(AR)" "$(RANLIB)" || exit 0

In words: scan pthread.o (it contains all pthread relating symbols) to get all exported
symbols and than extract all object files from cygdll.a to create the partially import
library libpthread.a

and so on.

You see, that the cygwin.din isn't nessessary for doing this (Isn't it real ? Are there some
exceptions ?)

With this, it is quite easy to integrate additional libs into cygwin. What is not handled
currently are exceptions from this rule, so if some symbols must not exported, although they
are public in the static lib.

Ralf



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