From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24109 invoked by alias); 30 Dec 2001 13:21:43 -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 24075 invoked from network); 30 Dec 2001 13:21:39 -0000 Received: from unknown (HELO mout0.freenet.de) (194.97.50.131) by sources.redhat.com with SMTP; 30 Dec 2001 13:21:39 -0000 Received: from [194.97.50.136] (helo=mx3.freenet.de) by mout0.freenet.de with esmtp (Exim 3.33 #3) id 16KfuD-0003kE-00 for cygwin@cygwin.com; Sun, 30 Dec 2001 14:21:37 +0100 Received: from acde6.pppool.de ([213.6.205.230] helo=BRAMSCHE) by mx3.freenet.de with smtp (Exim 3.33 #3) id 16KfuC-0000uJ-00 for cygwin@cygwin.com; Sun, 30 Dec 2001 14:21:36 +0100 From: "Ralf Habacker" To: Subject: RE: duplicate regexec/regcomp functions detected Date: Sun, 30 Dec 2001 07:34:00 -0000 Message-ID: <004101c19134$89eb4a30$0e6307d5@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 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: <20011230013908.GA1106@redhat.com> X-SW-Source: 2001-12/txt/msg01294.txt.bz2 > -----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/