Re: cygwin Digest 1 Apr 2003 17:20:50 -0000 Issue 2699 -- re BIG BROTHER
> > Message-ID: <[EMAIL PROTECTED]> > > Date: Tue, 01 Apr 2003 11:38:15 -0500 > From: Fred Ma <[EMAIL PROTECTED]> > MIME-Version: 1.0 > To: [EMAIL PROTECTED] > S> ubject: Re: Big Brother is Real > Content-Type: text/plain; charset=us-ascii > Content-Transfer-Encoding: 7bit > > > > OH. MY. GOD. > > > > I installed SP3 on my Win2K. Ignorance is NOT bliss. > > > > I guess it really is time to move to Linux. > > > > > > > > Randall Schulz > > > > Any comments on whether a firewall helps? I don't use office, just > Win2K (and even then, mostly on cygwin). I recall a time Kerio > and ZoneAlarm kept asking for server rights for some Win2K > service programs. Internet access didn't work without granting > these rights. So I granted them. > > Fred > > -- > Fred Ma, [EMAIL PROTECTED] > Carleton University, Dept. of Electronics > 1125 Colonel By Drive, Ottawa, Ontario > Canada, K1S 5B6 Won't help, Fred. Haven't you seen: http://yro.slashdot.org/article.pl?sid=03/03/30/0524244&mode=thread&tid=158 &tid=103&tid=193 or "Use a Firewall, Go To Jail" http://www.freedom-to-tinker.com/archives/000336.html It's only a matter of time before the piracy-nazis reacy up thre to canada and make it illegal for you to exert your internet privacy rights. -- 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/
pthreads
ERROR in my original posting: Below wher eit says "pthread_timed_wait()" it should say "pthread_cond_timedwait(). -- Forwarded by Fred Smith/Computrition on 10/09/2002 04:19 PM --- Fred Smith 10/09/2002 04:18 PM Sent by: Fred Smith To: [EMAIL PROTECTED] cc: Subject: pthreads Gang: I've got a body of code that is running successfully on Linux. It's mostly also working fine with Cygwin, but am having a problem in one area: It starts up several threads (pthread_create), all detached. One of them blocks on pthread_timed_wait(), the rest do not. Later on when exiting, it cancels all those threads, and the one that is blocking on pthread_timed_wait() gets back a return value of 3 (ESRCH) with errno=0, the rest are fine. I've verified that the pthread_t value I'm using for the cancel is the same one we got back from pthread_create. Can anybody help shed a little illumination on this for me? Thanks! Fred -- 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/
pthreads
Gang: I've got a body of code that is running successfully on Linux. It's mostly also working fine with Cygwin, but am having a problem in one area: It starts up several threads (pthread_create), all detached. One of them blocks on pthread_timed_wait(), the rest do not. Later on when exiting, it cancels all those threads, and the one that is blocking on pthread_timed_wait() gets back a return value of 3 (ESRCH) with errno=0, the rest are fine. I've verified that the pthread_t value I'm using for the cancel is the same one we got back from pthread_create. Can anybody help shed a little illumination on this for me? Thanks! Fred -- 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/
re: pthreads
Following up on my two messages of yesterday, I've narrowed down a bit the
problem I am having with pthread_cancel(), to the point where the thread
I'm trying to cancel doesn't do ANYTHING but loop. No calls to any other
functions at all, just an endless loop..
When I call pthread_cancel() I get back a return code of 3, and the thread
is not cancelled. (If the thread loops, printing out some distinct text
once per loop, the text keeps right on printing beyond the cancel call, up
until the app actually exits).
The value of the thread ID (pthread_t) is the same all the way through the
program from the moment the thread is created up to and in fact after the
pthread_cancel call fails.
I'm stumped.
Here's some little bits of code
The thread creation:
sys_parms.gc_parms.gc_tid = (pthread_t) 0;
rc = start_gc((void *) &sys_parms);
printf ("sys_parms.gc_parms.gc_tid=%x\n", sys_parms.gc_parms.gc_tid);
and in start_gc:
pthread_t gc_id;
...
if (pthread_create (&gc_id , &sys_parms->gc_parms.gc_thr_attr, thr_gc,
sys_parms) != 0)
{ /* pthread_create failure */
rc = CANNOT_CREATE_GC_THREAD;
}
printf ("gc_id=%x\n", gc_id);
sys_parms->gc_parms.gc_tid = gc_id;
printf ("sys_parms->gc_parms.gc_tid=%x\n",
sys_parms->gc_parms.gc_tid);
then later when we cancel it:
printf ("sys_parms.gc_parms.gc_tid=%x, rc=%d\n",
sys_parms.gc_parms.gc_tid, rc);
if (sys_parms.gc_parms.gc_tid != (pthread_t) 0)
{
if ((rc = pthread_cancel (sys_parms.gc_parms.gc_tid)) != 0)
{
uif_print (uif_fd, "%s%s %s%d%s %s%x%s %d%s",
"ERROR: in function ", __FUNCTION__,
"Cannot cancel Garbage Collection thread,
rc = ",
rc, ".\n", "gc_tid = ",
sys_parms.gc_parms.gc_tid,
" errno = ", errno, "\n");
return EXIT_FAILURE;
}
Am I out in left field here in some way that I'm too blind to see?
--
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/
trouble using a PTY
I'm trying to run some very simple code that uses ptys. The
code is from W. Richard Stevens APUE book. The only change is
the printf you see below. In this routine:
int
ptym_open(char *pts_name)
{
int fdm;
char*ptr1, *ptr2;
strcpy(pts_name, "/dev/ptyXY");
/* array index: 0123456789 (for references in following code) */
for (ptr1 = "pqrstuvwxyzPQRST"; *ptr1 != 0; ptr1++) {
pts_name[8] = *ptr1;
for (ptr2 = "0123456789abcdef"; *ptr2 != 0; ptr2++) {
pts_name[9] = *ptr2;
/* try to open master */
if ( (fdm = open(pts_name, O_RDWR)) < 0) {
printf ("ptym_open, open returned errno of: %d, pts_name=%s\n",
errno,pts_name);
if (errno == ENOENT)/* different from
EIO */
return(-1); /*out of pty devices
*/
else
continue;/*try next pty device
*/
}
pts_name[5] = 't'; /* change "pty" to "tty" */
return(fdm);/* got it, return fd of
master */
}
}
printf ("pty, at end, errno is: %d\n", errno);
return(-1); /* out of pty devices */
}
the first call to open() fails, and the printf produces:
ptym_open, open returned errno of: 2, pts_name=/dev/ptyp0
As far as I can deduce by reading cygwin docs and mailing list archives,
PTYs would be expected to work.
I'd appreciate it if someone could point me in the right direction here.
attached is output of "cygcheck -s"
Thanks!
fred
(See attached file: cygcheck.out)
cygcheck.out
Description: Binary data
--
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/
Re: trouble using a PTY
Egor:
Thanks for the info!
Fred
egor duda <[EMAIL PROTECTED]> on 11/03/2002 09:47:53 AM
Please respond to egor duda <[EMAIL PROTECTED]>
To: Fred Smith/Computrition
cc: [EMAIL PROTECTED]
Subject: Re: trouble using a PTY
Hi!
Sunday, 03 November, 2002 [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Fcc> I'm trying to run some very simple code that uses ptys. The
Fcc> code is from W. Richard Stevens APUE book. The only change is
This code is non-portable. The names of ptys are system-specific, and
not guaranteed to be named /dev/ptyXY.
On cygwin, master side of pseudo tty can be opened via
open("/dev/ptym",...). Then you can use grantpt(), unlockpt() and
ptsname() functions to access a slave side of pty.
Unfortunately, its not very portable, either. Proposed portable
interface to open master side of pseudo tty is posix_openpt(), but it
haven't been implemented on cygwin yet. "Patches are gratefully
accepted" (tm).
BTW, implementing this function looks like an easy prey for those who
wish to contribute something to cygwin, but afraid of complexities of
cygwin internals.
Fcc> the printf you see below. In this routine:
Fcc> int
Fcc> ptym_open(char *pts_name)
Fcc> {
Fcc> int fdm;
Fcc> char*ptr1, *ptr2;
Fcc> strcpy(pts_name, "/dev/ptyXY");
Fcc> /* array index: 0123456789 (for references in following
code) */
Fcc> for (ptr1 = "pqrstuvwxyzPQRST"; *ptr1 != 0; ptr1++) {
Fcc> pts_name[8] = *ptr1;
Fcc> for (ptr2 = "0123456789abcdef"; *ptr2 != 0; ptr2++) {
Fcc> pts_name[9] = *ptr2;
Fcc> /* try to open master */
Fcc> if ( (fdm = open(pts_name, O_RDWR)) < 0) {
Fcc> printf ("ptym_open, open returned errno of: %d, pts_name=%s\n",
Fcc> errno,pts_name);
Fcc> if (errno == ENOENT)/* different
from
Fcc> EIO */
Fcc> return(-1); /*out of pty
devices
Fcc> */
Fcc> else
Fcc> continue;/*try next pty
device
Fcc> */
Fcc>}
Fcc> pts_name[5] = 't'; /* change "pty" to
"tty" */
Fcc> return(fdm);/* got it, return fd
of
Fcc> master */
Fcc> }
Fcc> }
Fcc> printf ("pty, at end, errno is: %d\n", errno);
Fcc> return(-1); /* out of pty devices */
Fcc> }
Fcc> the first call to open() fails, and the printf produces:
Fcc> ptym_open, open returned errno of: 2, pts_name=/dev/ptyp0
Fcc> As far as I can deduce by reading cygwin docs and mailing list
archives,
Fcc> PTYs would be expected to work.
Fcc> I'd appreciate it if someone could point me in the right direction
here.
Fcc> attached is output of "cygcheck -s"
Egor.mailto:deo@;logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19
--
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/
Backwards typeahead
>On Tue, Nov 05, 2002 at 11:55:52AM -0500, Steve Chapel wrote: >>Christopher Faylor wrote: >>>On Tue, Nov 05, 2002 at 10:25:58AM -0500, Steve Chapel wrote: >>> So again I ask for information on how this cygwin problem can be solved. It makes typeahead completely useless for me. >>> >>>What kind of information are you hoping for? If we knew how to solve the >>>problem it would be solved. >> >>I saw on another post that what was needed to fix the problem is someone >>who can reproduce it and is willing to use gdb to track down the >>problem. I just volunteered. Was the earlier post incorrect? > >Without knowing what "the earlier post" might be, that's rather hard to say. There IS a bug in certain versions of Windows wherein fast type-ahead that occurs while the system is busy will be queued up in the incorrect order. What I do not know is if it has ever been fixed, and if so in what version. I know it exists in 95 (and probably its derivatives). It's documented in the Kermit-95 pages at columbia.edu as a windows bug. -- 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/
pthreads compile/link flags
I don't see this in the docs (forgive me if I"m blind) What compile and/or link options should be used with Cygwin for pthreads apps? I know on LInux it is "-pthread", other systems have other options, but what are the correct settings for Cygwin? Thanks! Fred -- 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/
repost: correct compile/link flags for PTHREADS
I don't see this in the docs (forgive me if I"m blind) (I've looked yet again, and searched the archives too) What compile and/or link options should be used with Cygwin for pthreads apps? I know on LInux it is "-pthread", other systems have other options, but what are the correct settings for Cygwin? Thanks! Fred -- 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/
suitable cygwin subset question
I'm developing a multithread app on cygwin (well, porting from LInux, actually), which uses Oracle OCI for client services. So far it's running well on my development box. Just tried an experiment, in which I took my program and its necessary data files, and the cygwin DLLs reported by cygcheck (cygwin1.dll, cygz.dll) to another windows machine, one that has NO cygwin stuff on it at all. Dropped all those files in a directory (for simplicity, I know it's not the long-term right way to do it). My app starts up just fine, it receives its input (via tcp), drops it in its queue and sits there forever. It's got another thread that pulls things out of the queue, processes them and sends off to the Oracle database. But somehow it never seems to actually get anything sent. When I tell the app to terminate, its behavior makes it plain that it's down inside the bowels of the OCI code (as compared to being in my higher-level code that polls the queue), so my guess is it's blocking somewhere in Oracle for some unknown-to-me reason. So this all is a prelude to the question: What's the minimum subset of stuff I need to move, and is it necessary to actually run a cygwin installer (for registry setups, maybe???) or will simply putting files in the "right place" work? Bash, strace, and ps all seem to work on this configuration, if it means anything. My apologies about the somewhat vague question, I don't know how to be more specific without posting a billion lines of crap. Anybody needs some specific info I'll be glad to provide it. Fred -- 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/
Re: suitable cygwin subset question
>> So this all is a prelude to the question: What's the minimum subset of >> stuff I need to move, and is it necessary to actually run a cygwin >> installer (for registry setups, maybe???) or will simply putting >> files in the "right place" work? > >Without registry entries, Cygwin won't know where / is - so the only paths >that will work are /cygdrive paths. > >Installing a small set of packages with setup is probably the best option, >but if you really don't want to do that, 'mount' should enable you to set >the necessary info in the registry. > >Quite how this could cause Oracle code to hang, though, I have no idea. > >Max. OK, I did a minimal install on a machine without Cygwin, my program then runs. I then used regedit to delete the two sets of "cygnus solutions" registry keys, and my program now no longer runs (properly). so, maybe all I need to do is set the right registry keys. Could someone "in the know" explain to me how to use mount to do that? Thanks! Fred -- 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/
cross-compiler
Pardon me if maybe this belong on developer instead I've seen mention of a cygwin-targeted cross-development toolset (for LInux, perhaps), but so far have no clue where/how one obtains it. Is there a package available somewhere, or does one need to download gcc et al (and I don't know how big a set of things 'et al' might be) and do one's own build? Tks! Fred -- 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/
Re: cygwin Digest 2 Jan 2003 23:32:57 -0000 Issue 2457
> > Message-ID: <[EMAIL PROTECTED]> > Date: Thu, 2 Jan 2003 08:52:07 -0800 (PST) > From: Robert Bercik <[EMAIL PROTECTED]> > Subject: lockf() or flock() support? > To: [EMAIL PROTECTED] > MIME-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > > > I'm porting an application that uses lockf() to cygwin > and it doesn't appear that either are supported on > cygwin. If so i can't seem to find which library they > are contained in. Anybody have any luck with either of > these? > > thanks, > -Rob You could implement your own lockf() as a wrapper around fcntl(), assuming that enough of fcntl() functionality actually exists (I did it once upon a time for a really old LInux that didn't have lockf, and it actually worked! however I don't own the code so I can't send it to you--it wasn't hard, less than 100 lines of code, including whitespace and comments.) I have no personal knowledge of the completeness of cygwin's fcntl() so YMMV. Good luck! Fred -- 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/
Subject: Re: Setup.exe
>
> Message-ID: <[EMAIL PROTECTED]>
> Date: Wed, 8 Jan 2003 17:24:22 - (GMT)
> Subject: Re: Setup.exe
> From: "Dave Hooper" <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> MIME-Version: 1.0
> Content-Type: text/plain;charset=iso-8859-1
>
>
> >>> Isn't that kinda up to the user. When you finish downloading new
> >>> packages you kill your internet connection as cygwin setup won't
> >>> need it.
> >
> > Autodialling isn't something that (most) programs do. Windows does it
for
> > them. So setup doesn't know if a connection was made on it's account or
> > not.
>
> I'd agree that it isn't something most programs do. I'd disagree if you
> were to say "Autodialling isn't something that most programs need to do",
> however. Windows cannot know that setup.exe has 'finished' with the
> internet connection (I believe Windows will by default wait until
> setup.exe has exitted before closing the dialup connection) unless
> setup.exe gives Windows a hint. I'm almost utterly convinced that a
> sequence in setup.exe a bit like the following will do the trick
> admirably.
>
> DWORD dwNetAccess;
> InternetGetConnectedState(&dwNetAccess,0);
> if (dwNetAccess & INTERNET_CONNECTION_MODEM)
> {
> // autodial now. windows will update a reference count
> // if the connection is already open
> InternetAutoDial(INTERNET_AUTODIAL_FORCE_ONLINE, &hwndSetupDialog);
> }
>
> [snip - setup.exe goes and downloads the packages]
>
> if (dwNetAccess & INTERNET_CONNECTION_MODEM)
> {
> // hang up. windows will decrease a reference count.
> // Can't remember if Windows prompts the user if they
> // wish to close the dialup connection when the reference
> // count reaches zero, or if Windows just does it anyway!
> InternetAutodialHangup(0);
> }
>
>
> I'm speculating, I'll try it when I get a chance. Of course this relies
> on behaviour built into Internet Explorer 4 and newer (more accurately
> built into the version of WinInet.dll shipping with IE 4, or a newer
> version of that dll) but setup.exe can easily test for the presence of
> this and do what it currently does if it can't find the functions or
can't
> find wininet.dll in the path.
>
> > Isn't the change from downloading to installing info enough?
>
> Some people won't notice that. A larger issue is if you go away and make
> some tea. I for one don't stare at setup.exe while it downloads
> eighty-six megabytes of information on a 33.6K modem. (I do sit and
watch
> defrag for hours on end though, but that's just me)
>
> > http://sources.redhat.com/cygwin-apps/setup.html
>
> Thanks. Will play.
>
>
> d
I'll leap in here too...
If Windoze is smart enough to autodial when some program wants to use the
internet it then should be smart enough to notice that the connection has
gone idle and do an idle time-out for hanging up. If not, then its broken.
You can't blame the program that USES that auto-dialed connection for not
hanging up. It didn't dial, why should it hang up? Every program that might
use the internet (auto-dialled) now has to be modified to know how to hang
up the connection? What if you have two programs using the connection at
the same time, and one of them decides to hang it up? Oops. Clearly not the
right solution.
F
--
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/
Re: bash shell
[EMAIL PROTECTED] on 02/14/2003 03:14:39 PM To: [EMAIL PROTECTED] cc:(bcc: Fred Smith/Computrition) Subject: cygwin Digest 14 Feb 2003 20:14:39 - Issue 2563 > > It has recently come to my attention that some people think the Cygwin > > list is exceptionally unfriendly to the uninitiated. Of course, I'd just > > like to think we hold a higher standard. > > > Here, here! :-) I should point out that there are all kinds of opinions to keep up with the meanies on the list, I feel compelled to point out that perhaps you MEANT to say: "Hear, Hear!" ;^} -- 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/
Re: EOF error
"Kooser, Ara S" <[EMAIL PROTECTED]> said: >PROGRAM TEMP > * > *This program converts Celsius to Farenheit * > ** > *The variable used is: * > * DEGC : degress celsius * > * > >REAL DEGC, DEGF >PRINT * , 'ENTER THE TEMPERATURE IN DEGRESS C:' > READ * , DEGC >DEGF = 9 / 5 * DEGC + 32 >PRINT * , 'DEGRESS FARENHEIT:' , DEGF > END > > I compiled it with this command > > gcc -o projec -c projec.f Besides the fact that this program does not produce correct results (entering "-40" produces output of "-8" which certainly is incorrect), is it also not an error to be trying to compile a FORTRAN program with gcc? Should he not be using g77 instead? --- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed.If you have received this email in error please notify [EMAIL PROTECTED] Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Computrition, Inc. Finally, the recipient should check this email and any attachments for the presence of viruses. Computrition, Inc. accepts no liability for any damage caused by any virus transmitted by this email. --- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Changing jobs
> > Date: Wed, 31 Mar 2004 13:08:30 -0500 > From: Christopher Faylor <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: Changing jobs > Message-ID: <[EMAIL PROTECTED]> > Reply-To: [EMAIL PROTECTED] > Mime-Version: 1.0 > Content-Type: text/plain; charset=us-ascii > > > I just wanted to send a brief note to inform everyone that today is my > last day at Red Hat. I have accepted a position with TimeSys > Corporation. > > I plan on continuing my volunteer work on both Cygwin and on > sources.redhat.com so people here should see little change in that > regard. > > Corinna Vinschen has volunteered to be the official Red Hat maintainer > for Cygwin. So, she'll be involved with any special cygwin licensing > issues (she gets all of the distasteful stuff). Corinna and I will be > co-project leads for Cygwin. > > So, again, I don't think anyone will notice much of a change but I > thought I should make my new situation clear. > -- > Christopher Faylor > Cygwin Co-Project Leader Does this mean you'll be getting out of the house some? Maybe some fresh air will help the termperament (so that now CGF wont' be synonymous with mean?) :^) Congratulations, Chris, we wish you well! --- This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed.If you have received this email in error please notify [EMAIL PROTECTED] Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Computrition, Inc. Finally, the recipient should check this email and any attachments for the presence of viruses. Computrition, Inc. accepts no liability for any damage caused by any virus transmitted by this email. --- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Pthread problems -- [was: Re: newer bintuils]
> --- Alan Hourihane <[EMAIL PROTECTED]> wrote: > > "Alan Hourihane" wrote in message > > amnb7e$7k5$[EMAIL PROTECTED]">news:amnb7e$7k5$[EMAIL PROTECTED]... > > > Anyone know when the new binutils will be out with Egor's > > > fixes for auto-import of arrays ? > > > > Anyone know the expected ETA for this ? > > No, because Egor's application for copyright assignment is currently > stuck in the Russian Postal System. We could be in for a long > wait... > > > I think we need a new cygwin dll for this too first though - don't > > we? > > Yes, you are correct. However there are currently some pthread > issues which are being resolved before this happens. Anyhow, as > previously mentioned, we are probably in for a long wait. > > Cheers, > Nicholas Can someone elucidate a bit on the pthread problems? I'm using pthreads, haven't yet done major/exhaustive testing, but would like to know if I could expect any impact from the problems. Thanks! Fred -- 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/
Re: What is the minimum needed to run gtar?
Message-ID: <[EMAIL PROTECTED]> From: "Biederman, Steve" <[EMAIL PROTECTED]> To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> Subject: What is the minimum needed to run gtar? Date: Tue, 5 Aug 2003 17:04:53 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Steve Biederman said: > I want to allow the users I support to be able to run Cygwin tar on their Windows > machines. > These machines have not had any Cygwin installed; they're just bare Windows machines. > I provided them tar.exe and cygwin1.dll and assumed that with these, they could ru > Cygwin tar sucessfully. It appears that that isn't the case: machines without Cygwin > installed see different behavior than machines which have it installed. (Running tar > on machines without Cygwin installed creates incorrect tar archives.) > What is the minimum I need to provide to a non-Cygwin Windows machine to get > Cygwin tar to run reliably? Steve, have you looked into DJGPP? DJGPP creates 32-bit DOS executables, and I believe one of the "standard" tools available from the DJGPP project is GNU tar. This should run on any Win32 box without needing additional dll files. Keep in mind, though, that if you are using one of the compression options (-z, -j, -Z) that you will also need a DOS-callable version of gzip, bzip2, or compress. Fred This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error please notify [EMAIL PROTECTED] Please note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Computrition, Inc. Finally, the recipient should check this email and any attachments for the presence of viruses. Computrition, Inc. accepts no liability for any damage caused by any virus transmitted by this email. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
