* RE: duplicate regexec/regcomp functions detected [not found] <01df01c19259$1cbb8300$0200a8c0@lifelesswks> @ 2002-01-01 6:27 ` Ralf Habacker 2002-01-01 9:26 ` Christopher Faylor 0 siblings, 1 reply; 30+ messages in thread From: Ralf Habacker @ 2002-01-01 6:27 UTC (permalink / raw) To: Cygwin > 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2002-01-01 6:27 ` duplicate regexec/regcomp functions detected Ralf Habacker @ 2002-01-01 9:26 ` Christopher Faylor 2002-01-01 9:53 ` Corinna Vinschen 2002-01-01 13:56 ` Ralf Habacker 0 siblings, 2 replies; 30+ messages in thread From: Christopher Faylor @ 2002-01-01 9:26 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2002-01-01 9:26 ` Christopher Faylor @ 2002-01-01 9:53 ` Corinna Vinschen 2002-01-01 10:30 ` Christopher Faylor 2002-01-01 13:56 ` Ralf Habacker 1 sibling, 1 reply; 30+ messages in thread From: Corinna Vinschen @ 2002-01-01 9:53 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2002-01-01 9:53 ` Corinna Vinschen @ 2002-01-01 10:30 ` Christopher Faylor 0 siblings, 0 replies; 30+ messages in thread From: Christopher Faylor @ 2002-01-01 10:30 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: duplicate regexec/regcomp functions detected 2002-01-01 9:26 ` Christopher Faylor 2002-01-01 9:53 ` Corinna Vinschen @ 2002-01-01 13:56 ` Ralf Habacker 1 sibling, 0 replies; 30+ messages in thread From: Ralf Habacker @ 2002-01-01 13:56 UTC (permalink / raw) To: cygwin > -----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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* duplicate regexec/regcomp functions detected @ 2001-12-13 12:48 Ralf Habacker 2001-12-14 2:40 ` Corinna Vinschen 0 siblings, 1 reply; 30+ messages in thread From: Ralf Habacker @ 2001-12-13 12:48 UTC (permalink / raw) To: Cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2001-12-13 12:48 Ralf Habacker @ 2001-12-14 2:40 ` Corinna Vinschen 2001-12-27 10:20 ` Ralf Habacker 0 siblings, 1 reply; 30+ messages in thread From: Corinna Vinschen @ 2001-12-14 2:40 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: duplicate regexec/regcomp functions detected 2001-12-14 2:40 ` Corinna Vinschen @ 2001-12-27 10:20 ` Ralf Habacker 2001-12-27 10:21 ` Christopher Faylor 0 siblings, 1 reply; 30+ messages in thread From: Ralf Habacker @ 2001-12-27 10:20 UTC (permalink / raw) To: Corinna Vinschen [-- 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2001-12-27 10:20 ` Ralf Habacker @ 2001-12-27 10:21 ` Christopher Faylor 2001-12-28 5:21 ` Ralf Habacker 0 siblings, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2001-12-27 10:21 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: duplicate regexec/regcomp functions detected 2001-12-27 10:21 ` Christopher Faylor @ 2001-12-28 5:21 ` Ralf Habacker 2001-12-28 5:22 ` Robert Collins 2001-12-28 10:17 ` Christopher Faylor 0 siblings, 2 replies; 30+ messages in thread From: Ralf Habacker @ 2001-12-28 5:21 UTC (permalink / raw) To: cygwin > > 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2001-12-28 5:21 ` Ralf Habacker @ 2001-12-28 5:22 ` Robert Collins 2001-12-28 10:17 ` Christopher Faylor 1 sibling, 0 replies; 30+ messages in thread From: Robert Collins @ 2001-12-28 5:22 UTC (permalink / raw) To: Ralf Habacker, cygwin ----- 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2001-12-28 5:21 ` Ralf Habacker 2001-12-28 5:22 ` Robert Collins @ 2001-12-28 10:17 ` Christopher Faylor 2001-12-29 12:43 ` Ralf Habacker ` (2 more replies) 1 sibling, 3 replies; 30+ messages in thread From: Christopher Faylor @ 2001-12-28 10:17 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: duplicate regexec/regcomp functions detected 2001-12-28 10:17 ` Christopher Faylor @ 2001-12-29 12:43 ` Ralf Habacker 2001-12-30 5:03 ` Christopher Faylor 2001-12-29 14:15 ` Ralf Habacker 2001-12-29 16:40 ` Ralf Habacker 2 siblings, 1 reply; 30+ messages in thread From: Ralf Habacker @ 2001-12-29 12:43 UTC (permalink / raw) To: cygwin [-- 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2001-12-29 12:43 ` Ralf Habacker @ 2001-12-30 5:03 ` Christopher Faylor 2001-12-30 7:34 ` Ralf Habacker 0 siblings, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2001-12-30 5:03 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: duplicate regexec/regcomp functions detected 2001-12-30 5:03 ` Christopher Faylor @ 2001-12-30 7:34 ` Ralf Habacker 2001-12-30 11:56 ` Christopher Faylor 0 siblings, 1 reply; 30+ messages in thread From: Ralf Habacker @ 2001-12-30 7:34 UTC (permalink / raw) To: cygwin > -----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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2001-12-30 7:34 ` Ralf Habacker @ 2001-12-30 11:56 ` Christopher Faylor 2001-12-31 11:19 ` Ralf Habacker 0 siblings, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2001-12-30 11:56 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: duplicate regexec/regcomp functions detected 2001-12-30 11:56 ` Christopher Faylor @ 2001-12-31 11:19 ` Ralf Habacker 2002-01-01 7:07 ` Corinna Vinschen 0 siblings, 1 reply; 30+ messages in thread From: Ralf Habacker @ 2001-12-31 11:19 UTC (permalink / raw) To: cygwin > -----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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2001-12-31 11:19 ` Ralf Habacker @ 2002-01-01 7:07 ` Corinna Vinschen 2002-01-01 16:00 ` Ralf Habacker 0 siblings, 1 reply; 30+ messages in thread From: Corinna Vinschen @ 2002-01-01 7:07 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: duplicate regexec/regcomp functions detected 2002-01-01 7:07 ` Corinna Vinschen @ 2002-01-01 16:00 ` Ralf Habacker 2002-01-02 2:04 ` Corinna Vinschen 0 siblings, 1 reply; 30+ messages in thread From: Ralf Habacker @ 2002-01-01 16:00 UTC (permalink / raw) To: Cygwin > -----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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2002-01-01 16:00 ` Ralf Habacker @ 2002-01-02 2:04 ` Corinna Vinschen 2002-01-02 2:11 ` Ralf Habacker 0 siblings, 1 reply; 30+ messages in thread From: Corinna Vinschen @ 2002-01-02 2:04 UTC (permalink / raw) To: Cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: duplicate regexec/regcomp functions detected 2002-01-02 2:04 ` Corinna Vinschen @ 2002-01-02 2:11 ` Ralf Habacker 0 siblings, 0 replies; 30+ messages in thread From: Ralf Habacker @ 2002-01-02 2:11 UTC (permalink / raw) To: Corinna Vinschen > -----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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: duplicate regexec/regcomp functions detected 2001-12-28 10:17 ` Christopher Faylor 2001-12-29 12:43 ` Ralf Habacker @ 2001-12-29 14:15 ` Ralf Habacker 2001-12-29 16:40 ` Ralf Habacker 2 siblings, 0 replies; 30+ messages in thread From: Ralf Habacker @ 2001-12-29 14:15 UTC (permalink / raw) To: cygwin > 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: duplicate regexec/regcomp functions detected 2001-12-28 10:17 ` Christopher Faylor 2001-12-29 12:43 ` Ralf Habacker 2001-12-29 14:15 ` Ralf Habacker @ 2001-12-29 16:40 ` Ralf Habacker 2001-12-30 14:35 ` Christopher Faylor 2 siblings, 1 reply; 30+ messages in thread From: Ralf Habacker @ 2001-12-29 16:40 UTC (permalink / raw) To: cygwin [-- 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2001-12-29 16:40 ` Ralf Habacker @ 2001-12-30 14:35 ` Christopher Faylor 2001-12-30 16:42 ` Christopher Faylor 2001-12-31 2:42 ` Ralf Habacker 0 siblings, 2 replies; 30+ messages in thread From: Christopher Faylor @ 2001-12-30 14:35 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2001-12-30 14:35 ` Christopher Faylor @ 2001-12-30 16:42 ` Christopher Faylor 2001-12-31 1:16 ` Christopher Faylor 2001-12-31 2:42 ` Ralf Habacker 1 sibling, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2001-12-30 16:42 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2001-12-30 16:42 ` Christopher Faylor @ 2001-12-31 1:16 ` Christopher Faylor 0 siblings, 0 replies; 30+ messages in thread From: Christopher Faylor @ 2001-12-31 1:16 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: duplicate regexec/regcomp functions detected 2001-12-30 14:35 ` Christopher Faylor 2001-12-30 16:42 ` Christopher Faylor @ 2001-12-31 2:42 ` Ralf Habacker 2001-12-31 11:06 ` Christopher Faylor 1 sibling, 1 reply; 30+ messages in thread From: Ralf Habacker @ 2001-12-31 2:42 UTC (permalink / raw) To: cygwin > -----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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2001-12-31 2:42 ` Ralf Habacker @ 2001-12-31 11:06 ` Christopher Faylor 2001-12-31 12:04 ` Ralf Habacker 0 siblings, 1 reply; 30+ messages in thread From: Christopher Faylor @ 2001-12-31 11:06 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* RE: duplicate regexec/regcomp functions detected 2001-12-31 11:06 ` Christopher Faylor @ 2001-12-31 12:04 ` Ralf Habacker 2001-12-31 14:12 ` Christopher Faylor 0 siblings, 1 reply; 30+ messages in thread From: Ralf Habacker @ 2001-12-31 12:04 UTC (permalink / raw) To: cygwin > -----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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
* Re: duplicate regexec/regcomp functions detected 2001-12-31 12:04 ` Ralf Habacker @ 2001-12-31 14:12 ` Christopher Faylor 0 siblings, 0 replies; 30+ messages in thread From: Christopher Faylor @ 2001-12-31 14:12 UTC (permalink / raw) To: cygwin 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/ ^ permalink raw reply [flat|nested] 30+ messages in thread
end of thread, other threads:[~2002-01-02 10:11 UTC | newest] Thread overview: 30+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <01df01c19259$1cbb8300$0200a8c0@lifelesswks> 2002-01-01 6:27 ` duplicate regexec/regcomp functions detected Ralf Habacker 2002-01-01 9:26 ` Christopher Faylor 2002-01-01 9:53 ` Corinna Vinschen 2002-01-01 10:30 ` Christopher Faylor 2002-01-01 13:56 ` Ralf Habacker 2001-12-13 12:48 Ralf Habacker 2001-12-14 2:40 ` Corinna Vinschen 2001-12-27 10:20 ` Ralf Habacker 2001-12-27 10:21 ` Christopher Faylor 2001-12-28 5:21 ` Ralf Habacker 2001-12-28 5:22 ` Robert Collins 2001-12-28 10:17 ` Christopher Faylor 2001-12-29 12:43 ` Ralf Habacker 2001-12-30 5:03 ` Christopher Faylor 2001-12-30 7:34 ` Ralf Habacker 2001-12-30 11:56 ` Christopher Faylor 2001-12-31 11:19 ` Ralf Habacker 2002-01-01 7:07 ` Corinna Vinschen 2002-01-01 16:00 ` Ralf Habacker 2002-01-02 2:04 ` Corinna Vinschen 2002-01-02 2:11 ` Ralf Habacker 2001-12-29 14:15 ` Ralf Habacker 2001-12-29 16:40 ` Ralf Habacker 2001-12-30 14:35 ` Christopher Faylor 2001-12-30 16:42 ` Christopher Faylor 2001-12-31 1:16 ` Christopher Faylor 2001-12-31 2:42 ` Ralf Habacker 2001-12-31 11:06 ` Christopher Faylor 2001-12-31 12:04 ` Ralf Habacker 2001-12-31 14:12 ` Christopher Faylor
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).