This is the mail archive of the mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

RE: duplicate regexec/regcomp functions detected

> -----Original Message-----
> From: []On Behalf
> Of Christopher Faylor
> Sent: Sunday, December 30, 2001 2:39 AM
> To:
> 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
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
Gentoo Linux
Mandrake Linux
MS Windows NT, 2000
Polish(ed) Linux Distribution
RedHat Linux
Redmond Linux
SGI Irix
Slackware Linux
Sun Solaris
SuSE Linux
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

- 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);

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.

Unsubscribe info:
Bug reporting:

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