RE: File descriptor lossage during thread termination

> > However, I am encountering a situation when another thread (not > necessaraly > involved in the above communication) under the same process, terminates > (through return), some (or all) of the pipe (and possibly other) file > descriptors become unavailable. This leads to, such symptoms as 'sel

File descriptor lossage during thread termination

Hello, I am encountering the following problem : I have a multithreaded application. Some of the inter-thread communication is performed by pipes (pipe()).. One thread issues a 'select' and the other one writes to it.. However, I am encountering a situation when another thread (not necessaraly i

RE: Do you google?

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 > > > Nice, but I believe the attached approach will work better on this > > list. > :-D > > Unfortunately, that program has a bug. It will only print > one (rather long) line - not the 500 presumably intended :-). Hmm.. Not if you configure th

PE Linker and/or runtime error when importing data from DLL (was RE: getopt: ugly linker messages) - hopefully solved.

My apologies. I finally decided to look for myself in binutils.. And found a way to fix the issue. I proposed a patch to the binutils folks. --Ivan -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: h

RE: getopt: ugly linker messages

> > Are you not a native English speaker or are you just trolling now? > > This is what I said: > > "Apparently, no one knows the answer to your question and, > apparently, no one is interested in researching the problem for you." > > In this context, it is clear what I was saying. I was sayi

RE: getopt: ugly linker messages

> > Sigh. By "research", I meant dive into the binutils code and > figure out what is going wrong. Geez.. You kidding me ? I mean, I wouldn't mind doing that.. But it would probably take me a month or so to just figure out the basics of how it works... Not to mention I have but very little unde

RE: getopt: ugly linker messages

> > Bingo. Apparently, no one knows the answer to your question > and, apparently, no one is interested in researching the > problem for you. Also, as you noted, it has a trivially easy > workaround -- don't strip import libraries. Right.. - No one is interrested in researching the problem f

RE: getopt: ugly linker messages

> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Ivan Warren > Sent: Saturday, September 20, 2003 2:43 AM > To: [EMAIL PROTECTED] > Subject: RE: getopt: ugly linker messages > > > > And.. Hmmm.. > > > > I

RE: getopt: ugly linker messages

> And.. Hmmm.. > > I *think* auto import of data variables may be somewhat broken > (and declared > import of data variables too) if > > 1) The import library is stripped with --strip-unneeded >and/or > 2) The import is from another DLL (.exe -> .dll[func] -> .dll[data]) > > (See msg dated 9/17

RE: getopt: ugly linker messages

> > I'm willing to do this but I have the same reservations that I think > you're expressing above, Chuck. Also, the auto-import of > data variables > is slower than a normal dllimport so I don't feel real > comfortable about > making this the default. > > I don't feel really strongly about th

Library strip, automatic imports and specific imports

Hello, First of all, my apologies if this isssue has already been addressed. I searched the archive but couldn't find anything relevant. I am running into the following problem : If I issue a 'strip --strip-unneeded' to a DLL import library (created with --out-implib), Most .data and/or .bss ext