From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5277 invoked by alias); 31 Dec 2001 18:56:11 -0000 Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Received: (qmail 5250 invoked from network); 31 Dec 2001 18:56:09 -0000 Received: from unknown (HELO mout1.freenet.de) (194.97.50.132) by sources.redhat.com with SMTP; 31 Dec 2001 18:56:09 -0000 Received: from [194.97.50.135] (helo=mx2.freenet.de) by mout1.freenet.de with esmtp (Exim 3.33 #3) id 16L7bU-0001zw-00 for cygwin@cygwin.com; Mon, 31 Dec 2001 19:56:08 +0100 Received: from b6538.pppool.de ([213.7.101.56] helo=BRAMSCHE) by mx2.freenet.de with smtp (Exim 3.33 #3) id 16L7bS-0002Nz-00 for cygwin@cygwin.com; Mon, 31 Dec 2001 19:56:07 +0100 From: "Ralf Habacker" To: Subject: RE: duplicate regexec/regcomp functions detected Date: Mon, 31 Dec 2001 11:19:00 -0000 Message-ID: <000a01c1922c$6f5d5b10$865c07d5@BRAMSCHE> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2173.0 In-Reply-To: <20011230184457.GA12386@redhat.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-SW-Source: 2001-12/txt/msg01328.txt.bz2 > -----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/