RE: cygwin archive? (previous versions for fallback)
>From: Igor Pechtchanski [mailto:[EMAIL PROTECTED] >On Tue, 11 Mar 2003, Jason Tishler wrote: > >> [snip] >> However, Cygwin setup.exe's cache should have all previous versions >> installed including PostgreSQL unless one deletes them. >Hence, the old >> PostgreSQL version should still have been available for the pg_dump >> phase. >> Jason > >Not if it's not present in the newly downloaded setup.ini, I don't >think... No, unless the user takes steps to clean out the download directory (with Michael Chase's clean_setup.pl script, for example) all previously downloaded tarballs persist. Being able to installing one of those previous tarballs with setup is another story, though. One way that I know of is to force setup to put the packages of interest into the Misc category. Regards, Chris -- 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: Hello. (running programs as daemon)
>Hello. This is my first mail to the list. Well, for starters, you'll need to put a better subject line on your posts. You might want to peruse http://www.tuxedo.org/~esr/faqs/smart-questions.html for additional tips. >I have this problem... >... it [Redir v.2.1] really works. but when i close my terminal the program >does not remain on background as /usr/sbin/sshd does. I want my program >to do as sshd.exe inetd is the service listening for connections on sshd's behalf. Have you added an entry to your inetd.conf for your new daemon? You have to have at least one service associated with your program for it to run without a console window. HTH, Chris -- 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: Alternate Cygwin download methods (was Re: NO hugepackages, please!)
>From: Max Bowsher [mailto:maxb@;ukf.net] > >Polley Christopher W <[EMAIL PROTECTED]> wrote: > >>> From: Max Bowsher [mailto:maxb@;ukf.net] >>> I thought I might as well mention my download method: >>> I wrote a little script to get a setup.ini file from a mirror, ... >> >> Sounds useful. :-) Care to share it? > >I was going to say "I've posted the URL so many times now, >just search the >archives.", but just checked and the archives are glacial. >So, here it is >again: > >http://home.ix.netcom.com/~mchase/zip/ Right. I had that already, and your options are useful, but I was referring to your script. Warm Regards, Chris -- 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: Alternate Cygwin download methods (was Re: NO hugepackages, please!)
>From: Max Bowsher [mailto:maxb@;ukf.net] >I thought I might as well mention my download method: >I wrote a little script to get a setup.ini file from a mirror, >and then use >Michael Chase's clean_setup.pl to make a list of URLs to get, >and pass that >to wget. I then invoke clean_setup.pl again, which tidys the >files away into >their correct location in the directory tree. >The great advantage is:- You can mirror only [curr] files, and >clean_setup >can delete/move files as the become [prev]. Plus, you can >exclude packages >by globbing on the package name. > Sounds useful. :-) Care to share it? Warm Regards, Chris -- 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: how to set "To:" and "Subject:" with ssmtp
You might also try formail, which is included in the procmail package. >From: Marcos Lorenzo > >I'm unable to fill some fields in mail header with ssmtp: > >When I run: > >marcos@MOZART ~$ echo "testing mail" | ssmtp -f >administrador@mozart -F Administrador [EMAIL PROTECTED] > > >I get the following: > ... > >Which is quite OK but I cannot see any option in ssmtp to set the To or >the Subject fields as with the From one. I searched the docs >and read the >manpage, but I didn't find any documentation on setting the >fields Subject >and To. > > -- 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: Viruses being transported with Cygwin messages
Robert, It's probably not your system that is infected -- Bugbear, like KLEZ, uses addresses harvested from the infected system in spoofed "From" headers. The only way I've been able to guess at the real identity for bugbear-infected mail that I've received (from friends/family) is to search through my mailbox for the first Received header's domain, and from that, look for a common association with the name in the "from" line. On a mailing list, that wouldn't work very well. Warm regards, Chris >-Original Message- >From: Gregg C Levine [mailto:[EMAIL PROTECTED]] >Sent: Sunday, October 13, 2002 8:38 PM >To: Robert Collins >Cc: [EMAIL PROTECTED] >Subject: Re: Viruses being transported with Cygwin messages > > >Hello from Gregg C Levine >Gladly, if I can find it. It's a message in ugly HTML format, >and it arrived >at my other address. >Gregg C Levine [EMAIL PROTECTED] >"Oh my!" The Second Doctor's nearly favorite phrase. >- Original Message - >From: "Robert Collins" <[EMAIL PROTECTED]> >To: "Gregg C Levine" <[EMAIL PROTECTED]> >Cc: <[EMAIL PROTECTED]> >Sent: Sunday, October 13, 2002 4:36 PM >Subject: Re: Viruses being transported with Cygwin messages >On Mon, 2002-10-14 at 05:04, Gregg C Levine wrote: >> Hello from Gregg C Levine >> Folks, don't roar at me, but I am seeing a number of >messages arrive here, >> infected. One came with a message via Robert Collins, twice, > >Can you point me at the message with the virus? And the virus? I email >from UNIX, so am *very* surprised at this. > > > >-- >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/
RE: Printing postscript file
I don't use XP, so this is based on my NT/W2K/95/ME experience, but when used in conjunction with '//host', 'name' should be the name that it is shared as -- from the "Sharing..." menu option. Type \\JASON in your Start->Run dialog -- that will show you the shares that are exposed. HTH, Chris > -Original Message- > From: Jason C. Johnston [SMTP:[EMAIL PROTECTED]] > Sent: Tuesday, April 02, 2002 3:11 AM > To: [EMAIL PROTECTED] > Subject: RE: Printing postscript file > > Michael A Chase wrote: > >> > >> lpr -P //host/name gmeta1.ps- what to put in //host etc. ? > >> > > > >Check your Window's printer definitions. 'host' is the name of the > server > >hosting the printer. 'name' is the shared name of the printer in that > >host. > >If its a local printer, use your computer's name and the printer's > name. > > Doesn't work for me on XP. Mine is a local printer, my computer's name > is -- according to the value of the COMPUTERNAME envvar -- 'JASON', and > my printer name is -- according to the Printers and Faxes control panel > -- 'HP LaserJet 1200 Series PCL'. This information is also given thus on > the Windows XP Printer Test Page. However: > > $ lpr -P "//JASON/HP LaserJet 1200 Series PCL" eight.c > lpr: can't open '//JASON/HP LaserJet 1200 Series PCL' for > writing > lpr: The printer name is invalid. > > (Yes, I know I shouldn't be sending it a textfile but rather PCL, but I > don't think that's the issue here.) > > Just for laughs I tried substituting the 'Port name", whatever that is, > for the 'Printer name', with equally dismal results: > > $ lpr -P "//JASON/DOT4_001" eight.c > lpr: can't open '//JASON/DOT4_001' for writing > lpr: The printer name is invalid. > > I have read all the postings in this on-again, off-again thread, but > although they raise, they do not appear to solve, the issue which is > that some of us cannot connect to our printer *at all* under Cygwin, and > it always comes down to the fact the we do not know how to refer to it > *symbolically* (an ability which all the various fixes assume). > > It may be relevant that my printer is connected via USB, but then again, > private correspondence with someone else having these problems, and who > is connected via the parallel port I gather, suggests that it may not > be. > > Cygcheck output attached as file cygout.txt. > > _ > Jason C. Johnston > mailto:[EMAIL PROTECTED] > http://www.astadhyayi.net > > << File: cygout.txt >> << File: ATT11063004.txt >> -- 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/
strace on inetd (was RE: bash failed to initialize ontelnet/rsh/ rlogin server)
I can't get strace to give any output against inetd. (which I'm trying to trace with -f to catch the startup of login.exe) Here's what I tried: $ ps -a PIDPPIDPGID WINPID TTY UIDSTIME COMMAND 1636 11636 16360 13721 12:32:03 /usr/bin/rxvt 1576163615766041 13721 12:32:03 /usr/bin/bash 1252 11252 1252? 18 12:42:57 /usr/sbin/inetd 179612521252 1796? 18 12:42:57 /usr/sbin/inetd 580 1 5805804 13721 13:44:44 /usr/bin/rxvt 1244 5801244 13565 13721 13:44:45 /usr/bin/bash 173212441732 16045 13721 13:46:40 /usr/bin/ps $ strace -p 1252 -f all <> $ strace -p 1252 all <> $ strace -p 1252 -f <> $ strace -p 1796 -f all <> $ strace -p 1796 all <> $ strace -p 1796 -f <> <> diverting output to a file with the -o option has no effect. leaving off the -f has no effect, either Are there more complete instructions to strace besides --help, the Cygwin user guide, or winsup/utils/utils.sgml (all essentially the same thing)? Thanks, Chris > -Original Message- > From: Christopher Faylor [SMTP:[EMAIL PROTECTED]] > Sent: Wednesday, March 27, 2002 12:18 PM > To: [EMAIL PROTECTED] > Subject: Re: bash failed to initialize on telnet/rsh/rlogin server > > On Wed, Mar 27, 2002 at 09:05:20AM -0600, Polley Christopher W wrote: > >So now that I know how to isolate the problem, is there a way to strace > >a daemon? > > strace -p pid > > 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/
RE: bash failed to initialize on telnet/rsh/rlogin server
Thanks, David, >This happened to me on NT4 when I upgraded to cygwin-1.3.10, and was >*not* using ntsec. Using ntsec fixed it. Is ntsec set early enough >for inetd? (And are you rebooting when making changes?) Does the >inetd service have sufficient user rights? Is everything I had ntsec set... but had not rebooted since setting it. Rebooted, and now all is well :-) (closing all cygwin processes including 'net stop inetd' wasn't enough) So now that I know how to isolate the problem, is there a way to strace a daemon? Warm regards, Chris -- 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: Debugging cygwin
Bill, The debug_printf statements get printed when you run your program under strace. (see http://cygwin.com/faq/faq.html#TOC111 ) Also, here are some excellent tips that cgf has given on strace and debugging cygwin1.dll: http://www.cygwin.com/ml/cygwin/2000-11/msg01469.html (BTW, "google is your friend" http://www.google.com/search?q=debugging+cygwin1%2Edll ) HTH, Chris -Original Message- From: William Hubbard Can someone point me to a how-to, or provide the steps, for getting set up so that I can debug cygwin1.dll? I want to instrument the com routines to help zero in on a problem I am having with connecting gdb to a simulation environment via a virtual serial port (to determine if it is cygwin or the virtual serial port driver that is the problem). I notice there are debug_printf statements in the code, already, but am clueless as to where this information gets printed. If I at least knew that, I could add my own tracers, but I'd like to be able to step through the code as well. I finally got cygwin1.dll to compile...so what's my next step? Thanks, Bill -- 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/
bash failed to initialize on telnet/rsh/rlogin server
I'm trying to get inetd set up for telnet/rsh/rlogin on my machine and have everything going up to the point that after login.exe gives the motd to the telnet client, a dialog window pops up on the server titled "bash.exe - Application Error" and says "The application failed to initialize properly (0xc022)." Acknowledging the dialog closes the connection with the client. I have telnetd working on another machine (NT4) but haven't been updating it to the latest cygwin packages. The new machine is running W2K, was updated this afternoon, and although there are 56 differences in the cygcheck -c outputs, these are the ones that seem relevant to me: (differences highlighted with *) Cygwin Package Information Cygwin Package Information Package Version Package Version * bash2.05a-3 bash2.05a-2 * cygwin 1.3.10-1cygwin 1.3.6-6 inetutils 1.3.2-17inetutils 1.3.2-17 login 1.4-3 login 1.4-3 Both are running with ntsec, and have identical passwd and group files (both from the domain server, passwd trimmed to a couple users plus the usual system accounts) Even though I thought I recalled seeing something about this in the last couple months, I've searched the mailing list for all kinds of combinations of keywords, including 'bash "failed to initialize"', and got no relevant hits. Before I try to debug this on my own, I wanted to check to see if there was some obvious answer (aside from "cygwin 1.3.10-1 broke this...because we're mean" :-) ) that I'm overlooking. And if I do need to debug this, where would I put the strace? in inetd.conf? if so, how? Thanks, Chris -- 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: Setting up user mode cron
You wrote: >At 01:45 PM 1/10/2002, Andrew DeFaria wrote: >>Anyway, cron has no access to them. It's running under SYSTEM >>account which has only access to publicly available net drives, that >>is, drives which are available w/o any form of authentication >>required. > > > >>No credentials, no authenticated network drive access. That's it. >> >>Questions: What is a publicly available net drive? How does one tell if it is publicly available vs. non publicly >available? > >I think the above quote from Corinna answers this question. In other words, >if Windows would ask you to identify yourself if you browsed to this share >as a user the domain doesn't know about, then you'll see a problem when >trying to use this share with cron (and some other) tools. > >Someone will correct me if I'm wrong. ;-) This seems correct to me, and I would add (or rather expand on how to become a "user the domain doesn't know about") that to find out what shares are publicly accessible, you need to log in to your workstation with unprivileged credentials, for example as \\localmachinedomain\guest (on NT, use the "User Manager" to see what accounts are defined on your machine). Accessing a non-public network share will then require you to enter a domain\userid and password, while a public share will be accessible without credentials. I don't know if NT caches userid/password combinations for network share attempts subsequent to a properly authenticated non-public share access, so be careful here. I have used batch files with NT's AT command and run into the same problem. My solution was to put a "net use : /user:\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: cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
I think I've found the cause of this. I'll summarize the problem, since this is an old thread: when a Windows GUI IDE calls gcc or make, the process reports "fhandler_base::dup: dup(unknown disk file) failed, handle 0, Win32 error 6" and crashes. The problem seems to occur when the [non-cygwin] application calls the windows CreateProcess API function with one or more of the STARTUPINFO.hStdInput, .hStdOutput, or .hStdError handles set to NULL; and STARTF_USESTDHANDLES is set in StartupInfo.dwFlags. The MSDN documentation is silent on the topic of calling CreateProcess with STARTUPINFO in this state, so I guess this falls under the realm of "undefined behavior", but at least some windows programs call this function without hStdInput set. I've found that in dtable::vfork_child_dup (), where each open fd in the fd table is dup'ed if it is open, that if a check for a null handle is added, the problem disappears: diff cygwin-1.3.6-6/winsup/cygwin/dtable.cc cygwin-1.3.6-6-orig/winsup/cygwin/dtable.cc 565c565 < if (not_open (i) || (fds[i]->get_handle() == NULL) ) --- > if (not_open (i)) Will this break anything else? (i.e. are there occasions where a valid open file handle might be 0?) I've taken a glance at the testsuite directory -- is a successful "make check" the benchmark? What other tests should I run? BTW, I noticed in the definition of not_open (in dtable.h), that the ResourceLock is set with the string "not_open" and then released with the string "not open". Does this inconsistency matter? I haven't noted any effects (good or bad) of changing the second to "not_open" (to match the function name): diff cygwin-1.3.6-6/winsup/cygwin/dtable.h cygwin-1.3.6-6-orig/winsup/cygwin/dtable.h 62c62 < ReleaseResourceLock (LOCK_FD_LIST, READ_LOCK, "not_open"); --- > ReleaseResourceLock (LOCK_FD_LIST, READ_LOCK, "not open"); Warm Regards, Chris -- 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: bootstrap/5149: gcc-20011217 reads beyond EOF on cygwin
> -Original Message- > From: Christopher Faylor [SMTP:[EMAIL PROTECTED]] > On Fri, Dec 21, 2001 at 03:42:14PM +0100, Werner Tuchan wrote: > >> Weird. The bytes after EOF are a mixture of NULs and 0xc0. Is 0xc0 > >> of special significance in Windows? Is your version of cygwin the AFAIR, I once read in the book "Code Complete..." by Steve McConnell (a MS programmer from the pre-windows days) a recommendation to set uninitialized pointers and memory to a known value (I think he used 0x for pointers and C0 for buffers) to aid in finding bugs of using unitinialized data areas. My limited experience with the MS debugger leads me to believe that this is a practice [at least some of] the MS kernel developers follow. (BTW, he also advocated setting allocated blocks to another known value immediately before freeing them, for a similar reason) Warm Regards, Chris -- 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: cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
> > it. If you can, debugging Cygwin via gdb would be the best way to go. > > Alternatively, if you can't do that, calling gcc indirectly through > > strace in your IDE environment would provide some trace information > > Here is a strace snippet right around the error's occurrence: 09:19:17 [main] make 384 dtable::build_fhandler: fd 3, fh 0x61550820 09:19:17 [main] make 384 dtable::build_fhandler: fd 4, fh 0x61550960 09:19:17 [main] make 384 fhandler_base::init: created new fhandler_base for handle 0xD8 09:19:17 [main] make 384 fhandler_base::init: created new fhandler_base for handle 0x154 09:19:17 [main] make 384 make_pipe: 0 = make_pipe ([3, 4], 16384, 0x1) 09:19:17 [main] make 384 _close: close (4) 09:19:17 [main] make 384 fhandler_base::close: closing '(null)' handle 0x154 09:19:17 [main] make 384 dtable::not_open: in not_open, fds=0x61550128 fd=4 fds[fd]=1632962912 res=0 size=32 09:19:17 [main] make 384 _close: 0 = close (4) 09:19:17 [main] make 384 fhandler_base::set_close_on_exec: set close_on_exec for (null) to 1 09:19:17 [main] make 384 _fcntl: 0 = fcntl (3, 2, 0x1) 09:19:17 [main] make 384 set_process_mask: old mask = 0, new mask = 1804007 09:19:17 [main] make 384 dtable::not_open: in not_open, fds=0x61550128 fd=0 fds[fd]=1632961224 res=0 size=32 09:19:17 [main] make 384 dtable::build_fhandler: fd -1, fh 0x61550960 09:19:17 [main] make 384 fhandler_base::dup: in fhandler_base dup 09:19:17 [main] make 384 fhandler_base::dup: dup(unknown disk file) failed, handle 0, Win32 error 6 09:19:17 [main] make 384 seterrno_from_win_error: /usr/src/cygwin/winsup/cygwin/fhandler.cc:926 errno 6 09:19:17 [main] make 384 geterrno_from_win_error: windows error 6 == errno 9 09:19:17 [main] make 384 vfork: 0 = vfork() 09:19:17 [main] make 384 vfork: exiting vfork, res 0 I'm not sure how far back is relevant to the vfork's setting up for the make-file's "echo" command that occurs next vs. cleaning up from checking dependencies (the previous task make was doing) the build_fhandler: fd=-1 is expected; that's a new dtable being built, so aside from that the error occurring in fhandler_base::dup (which we already knew) there's no new info. Larry, would posting a complete strace be useful? What might I look for in the strace? Warm Regards, Chris -- 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: cygwin1.dll (file version 1003.6.0.0) dup problem with gcc
I've been looking into this problem myself, (see last month's thread
starting with http://www.cygwin.com/ml/cygwin/2001-11/msg01217.html )
and have gotten to this point: at the point where vfork is duplicating the
fhandler table and dup'ing open fh's it somehow isn't detecting that stdin
isn't connected to anything. (see dtable::vfork_child_dup () in dtable.cc,
line 553)
Where i'm stuck is figuring out why fh 0 has status of 0x18010 (FH_DISK,
FH_RBINSET, FH_SYMLINK). Shouldn't fh 0 point to stdin?
The file name is a null string, so there's no help there.
BTW, I've written a short windows program to launch make (which i've
recompiled with support for the -D switch, to give me time to attach gdb --
gdb'ing the test-make program doesn't seem to work) here it is:
<>
It seems that there have been reports of this for gcc and make (my guess is
that it probably happens for all cygwin programs that launch other programs
as child processes) when launched using the windows CreateProcess API call.
Does anyone know how the cygwin dll handles CreateProcess calls in these
cases?
Warm Regards,
Chris
> -Original Message-
> From: Larry Hall (RFK Partners, Inc) [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, December 17, 2001 12:52 PM
> To: Suman Kumar Ray; [EMAIL PROTECTED]
> Subject: Re: cygwin1.dll (file version 1003.6.0.0) dup problem with
> gcc
>
> At 01:40 PM 12/17/2001, Suman Kumar Ray wrote:
>
> >Hi,
> > In the mailing list, I have found this problem with
> >earlier dll but with no solution or information
> >whether this is a bug of cygwin.
> >If I use cygwin.dll file version 1003.6.0.0, then when
> >a windows GUI based IDE is calling gcc through
> >createprocess and pass a file for compilation error
> >message appears as
> >fhandler_base::dup: dup(unknown disk file) failed,
> >handle 0, Win32 error 6. If I use cygwin1.dll file
> >version 1003.2.0.0 ( I mean I put gcc in separate
> >directory and put 1003.2.0.0 cygwin1.dll there), no
> >problem in calling gcc from IDE. Interestingly, if I
> >open cygwin shell, within that I can compile using any
> >of the above dlls.
> > Can somebody please tell me, what is the problem, and
> >how to rectify it ?
> > I have tried following command after reading one
> >e-mail, but no success.
> > mount -b --change-cygdrive-prefix /cygdrive
>
> Right. This isn't a cygdrive issue so I wouldn't expect to see any
> significant change by altering the mount option here.
>
> Clearly, fhandler::dup() is getting an invalid handle ('net helpmsg 6'
> tells you that). Given that the handle is 0, I think it's clear that
> this complaint is valid. Beyond that though, you're going to need to
> dig a little deeper to find the root of the problem. The issue is
> internal, which would require debugging to find the cause and correct
> it. If you can, debugging Cygwin via gdb would be the best way to go.
> Alternatively, if you can't do that, calling gcc indirectly through
> strace in your IDE environment would provide some trace information
> that might help you or others better understand the problem.
>
> Good luck,
>
>
> Larry Hall [EMAIL PROTECTED]
> RFK Partners, Inc. http://www.rfk.com
> 838 Washington Street (508) 893-9779 - RFK Office
> Holliston, MA 01746 (508) 893-9889 - FAX
>
>
> --
> 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/
>
test-make.c
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: Debug version of cygwin dll
Thanks, my apologies for asking a FAQ; I didn't see it on the list. I'll give these methods a try and see how it goes. Having done the make/make install from my source tree, do I have to repair anything now? Where can I find more information on the rationale behind not building in the src directory? Why does the README in the cygwin package say: >It is now possible to automatically configure and build a variety of >tools with one command. To build all of the tools contained herein, >run the ``configure'' script here, e.g.: > > ./configure > make if this is the incorrect way to do it? -Chris > -Original Message- > From: egor duda [SMTP:[EMAIL PROTECTED]] > Hi! > > Wednesday, 05 December, 2001 Peter Buckley [EMAIL PROTECTED] > wrote: > > PB> You need to bunzip2 and untar the src, then cd to > PB> /usr/src/cygwin-1.3.5-3 (or wherever you extracted it to) and do the > PB> following: > > PB> mkdir build > PB> cd build > PB> ../configure > PB> make > PB> make install > > please, don't make wrong suggestions! > > this way is _wrong_. for a correct way, check the FAQ, particularly > question "How do I rebuild the tools on my NT box?" > > cygwin sources also contain a file how-to-debug-cygwin.txt which > contains several debugging hints. > > Egor.mailto:[EMAIL PROTECTED] 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/
Debug version of cygwin dll
Hello, I'm trying to build cygwin(-1.3.5.3) with the debug symbols included. I exported CFLAGS=-g, then did ./configure, make, and make install; but only the .a libraries were built. Is there more info available about the makefile targets in this package? The README doesn't mention it and it's not obvious (to me) from inspection of the Makefile. How does one build the dlls? (or are debug versions available in a tarball?) Thanks, Chris -- 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: Problem with virtual inheritance and destruction of arrays
gcc 2.95.3-5 is the latest available from the cygwin mirrors, but I see from the gcc 3.0.x build status (http://gcc.gnu.org/gcc-3.0/buildstat.html) that it builds successfully on i[5|6]86-pc-cygwin. Are there any issues with building 3.0 OOTB on cygwin? When will the cygwin package be released onto the mirrors? Thanks, Chris > -Original Message- > From: Robinow, David [SMTP:[EMAIL PROTECTED]] > > This has nothing to do with cygwin. It's a gcc 2.95 problem. Fixed in > 3.0 > > -- 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/
