OT ## RE: Difference between just having cygwin1.dll and running under cygw in
Thanks for answering one of my long-standing questions (re. the AT+T guy). You might consider replacing Can't think of a witty .sigline today with I'm no relation to the AT+T guy.. :-) -Original Message- From: Dave Korn [mailto:[EMAIL PROTECTED] Sent: Sunday, March 14, 2004 1:33 PM To: [EMAIL PROTECTED] Subject: RE: Difference between just having cygwin1.dll and running under cygw in -Original Message- From: cygwin-owner On Behalf Of George Hester Sent: 13 March 2004 00:24 This coming from a whipper-snapper I don't expect a response. But you sure have a famous name. I'm no relation to the AT+T guy. FYI. cheers, DaveK -- Can't think of a witty .sigline today -- 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/ -- 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/
RE: Difference between just having cygwin1.dll and running under cygw in
-Original Message- From: cygwin-owner On Behalf Of George Hester Sent: 13 March 2004 00:24 This coming from a whipper-snapper I don't expect a response. But you sure have a famous name. I'm no relation to the AT+T guy. FYI. cheers, DaveK -- Can't think of a witty .sigline today -- 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/
Re: Difference between just having cygwin1.dll and running under cygw in
Thanks George Hester __ Thorsten Kampe wrote in message news:[EMAIL PROTECTED] pdksh -- 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/
RE: Difference between just having cygwin1.dll and running under cygw in
-Original Message- From: cygwin-owner On Behalf Of Larry Hall Sent: 11 March 2004 20:28 At 03:17 PM 3/11/2004, you wrote: What's the difference between running an executable in the cygwin environment and running it in a Win2K DOS shell on the same machine(which obviously has cygwin1.dll)? As I mentioned in another thread of mine, I have a program(port of objcopy) that I've compiled that runs just fine under cygwin, but crashes with a stack violation whenever I run it under a DOS window on the same machine! There's really no significant difference, assuming your DOS shell can see cygwin1.dll and it's the same one you get when you run under your Cygwin shell (having more than 1 cygwin1.dll on your system is a *very* bad idea anyway). Certainly, there can be all kinds of differences in the environment, literally, but it should be pretty obvious if you're dependent on some environment variable or something that's not set for Windows. Maybe you just need to debug it and see where the problem is and why you get it. Like I said, objcopy that comes with Cygwin's binutils works just fine for me outside of a Cygwin shell so it's not a problem with the tool in general. Larry I think you may slightly underestimate the amount of difference it makes. For example, it's going to make a big difference to the runtime memory layout. If you run under bash you're going to have a whole load of posix environment vars at the very top of your runtime stack. I could easily imagine a stray pointer or stack smashing bug that harmlessly scribbles on the environment vars under bash but writes over what is active program stack at the same address / offset-from-sp when run from dos. However, I agree with your conclusion: any *correct* program should run equally well under either, and I think in this case it's not that running under DOS breaks the program, but that it just happens to get lucky and work by chance under bash. My makefile does the same thing as the objcopy makefile, but the result of my compilation is something that only works under cygwin. That's quite an assertion to make! How did you generate your makefile, and how can you be really sure it's doing exactly the same? Autoconf-produced makefiles are fairly hairy; if you've hacked up the autoconf one, you're probably in the clear, but if you've tried reading the autoconf one and duplicating it's effects from scratch, you may easily have introduced a discrepancy. However, that's a side issue; it's unlikely to be a compiler option that's causing your problem. The fact that it's hanging in malloc suggests that it's very likely that the root cause of the crash is trashing the heap, most likely by writing past the end of a malloc'd block of memory. Beyond that it's difficult to speculate, particularly since we don't really have any idea what sort of changes you've made to the code. You should investigate any of the changes you've made that refer to arrays or malloc'd memory, or perhaps use some kind of error-checking malloc wrappers - e.g. efence, http://perens.com/FreeSoftware/ (ftp site currently down, it seems) or http://freshmeat.net/projects/efence/?branch_id=2277release_id=7043 . Of course it's always possible that it's not the code you've changed that is overwriting memory but something elsewhere by means of some indirect and unexpected interaction. Those are the worst kinds of bugs to look for, but malloc-wrappers might still help. How big are the changes you've made to the source? Minor overhaul or radical surgery? cheers, DaveK -- Can't think of a witty .sigline today -- 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/
Re: Difference between just having cygwin1.dll and running under cygw in
This coming from a whipper-snapper I don't expect a response. But you sure have a famous name. Now if I could just get the Korn Shell in cygwin or integrate UWin into cygwin that would be really neat. George Hester __ Dave Korn [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -Original Message- From: cygwin-owner On Behalf Of Larry Hall Sent: 11 March 2004 20:28 At 03:17 PM 3/11/2004, you wrote: What's the difference between running an executable in the cygwin environment and running it in a Win2K DOS shell on the same machine(which obviously has cygwin1.dll)? As I mentioned in another thread of mine, I have a program(port of objcopy) that I've compiled that runs just fine under cygwin, but crashes with a stack violation whenever I run it under a DOS window on the same machine! There's really no significant difference, assuming your DOS shell can see cygwin1.dll and it's the same one you get when you run under your Cygwin shell (having more than 1 cygwin1.dll on your system is a *very* bad idea anyway). Certainly, there can be all kinds of differences in the environment, literally, but it should be pretty obvious if you're dependent on some environment variable or something that's not set for Windows. Maybe you just need to debug it and see where the problem is and why you get it. Like I said, objcopy that comes with Cygwin's binutils works just fine for me outside of a Cygwin shell so it's not a problem with the tool in general. Larry I think you may slightly underestimate the amount of difference it makes. For example, it's going to make a big difference to the runtime memory layout. If you run under bash you're going to have a whole load of posix environment vars at the very top of your runtime stack. I could easily imagine a stray pointer or stack smashing bug that harmlessly scribbles on the environment vars under bash but writes over what is active program stack at the same address / offset-from-sp when run from dos. However, I agree with your conclusion: any *correct* program should run equally well under either, and I think in this case it's not that running under DOS breaks the program, but that it just happens to get lucky and work by chance under bash. My makefile does the same thing as the objcopy makefile, but the result of my compilation is something that only works under cygwin. That's quite an assertion to make! How did you generate your makefile, and how can you be really sure it's doing exactly the same? Autoconf-produced makefiles are fairly hairy; if you've hacked up the autoconf one, you're probably in the clear, but if you've tried reading the autoconf one and duplicating it's effects from scratch, you may easily have introduced a discrepancy. However, that's a side issue; it's unlikely to be a compiler option that's causing your problem. The fact that it's hanging in malloc suggests that it's very likely that the root cause of the crash is trashing the heap, most likely by writing past the end of a malloc'd block of memory. Beyond that it's difficult to speculate, particularly since we don't really have any idea what sort of changes you've made to the code. You should investigate any of the changes you've made that refer to arrays or malloc'd memory, or perhaps use some kind of error-checking malloc wrappers - e.g. efence, http://perens.com/FreeSoftware/ (ftp site currently down, it seems) or http://freshmeat.net/projects/efence/?branch_id=2277release_id=7043 . Of course it's always possible that it's not the code you've changed that is overwriting memory but something elsewhere by means of some indirect and unexpected interaction. Those are the worst kinds of bugs to look for, but malloc-wrappers might still help. How big are the changes you've made to the source? Minor overhaul or radical surgery? cheers, DaveK -- Can't think of a witty .sigline today -- 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/
Re: Difference between just having cygwin1.dll and running under cygw in
* George Hester (2004-03-13 01:24 +0100) This coming from a whipper-snapper I don't expect a response. But you sure have a famous name. Now if I could just get the Korn Shell in cygwin or integrate UWin into cygwin that would be really neat. George Hester __ Dave Korn [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] -Original Message- From: cygwin-owner On Behalf Of Larry Hall Sent: 11 March 2004 20:28 At 03:17 PM 3/11/2004, you wrote: What's the difference between running an executable in the cygwin environment and running it in a Win2K DOS shell on the same machine(which obviously has cygwin1.dll)? As I mentioned in another thread of mine, I have a program(port of objcopy) that I've compiled that runs just fine under cygwin, but crashes with a stack violation whenever I run it under a DOS window on the same machine! There's really no significant difference, assuming your DOS shell can see cygwin1.dll and it's the same one you get when you run under your Cygwin shell (having more than 1 cygwin1.dll on your system is a *very* bad idea anyway). Certainly, there can be all kinds of differences in the environment, literally, but it should be pretty obvious if you're dependent on some environment variable or something that's not set for Windows. Maybe you just need to debug it and see where the problem is and why you get it. Like I said, objcopy that comes with Cygwin's binutils works just fine for me outside of a Cygwin shell so it's not a problem with the tool in general. Larry I think you may slightly underestimate the amount of difference it makes. For example, it's going to make a big difference to the runtime memory layout. If you run under bash you're going to have a whole load of posix environment vars at the very top of your runtime stack. I could easily imagine a stray pointer or stack smashing bug that harmlessly scribbles on the environment vars under bash but writes over what is active program stack at the same address / offset-from-sp when run from dos. However, I agree with your conclusion: any *correct* program should run equally well under either, and I think in this case it's not that running under DOS breaks the program, but that it just happens to get lucky and work by chance under bash. My makefile does the same thing as the objcopy makefile, but the result of my compilation is something that only works under cygwin. That's quite an assertion to make! How did you generate your makefile, and how can you be really sure it's doing exactly the same? Autoconf-produced makefiles are fairly hairy; if you've hacked up the autoconf one, you're probably in the clear, but if you've tried reading the autoconf one and duplicating it's effects from scratch, you may easily have introduced a discrepancy. However, that's a side issue; it's unlikely to be a compiler option that's causing your problem. The fact that it's hanging in malloc suggests that it's very likely that the root cause of the crash is trashing the heap, most likely by writing past the end of a malloc'd block of memory. Beyond that it's difficult to speculate, particularly since we don't really have any idea what sort of changes you've made to the code. You should investigate any of the changes you've made that refer to arrays or malloc'd memory, or perhaps use some kind of error-checking malloc wrappers - e.g. efence, http://perens.com/FreeSoftware/ (ftp site currently down, it seems) or http://freshmeat.net/projects/efence/?branch_id=2277release_id=7043 . Of course it's always possible that it's not the code you've changed that is overwriting memory but something elsewhere by means of some indirect and unexpected interaction. Those are the worst kinds of bugs to look for, but malloc-wrappers might still help. How big are the changes you've made to the source? Minor overhaul or radical surgery? cheers, DaveK -- Can't think of a witty .sigline today pdksh -- 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/
Difference between just having cygwin1.dll and running under cygw in
What's the difference between running an executable in the cygwin environment and running it in a Win2K DOS shell on the same machine(which obviously has cygwin1.dll)? As I mentioned in another thread of mine, I have a program(port of objcopy) that I've compiled that runs just fine under cygwin, but crashes with a stack violation whenever I run it under a DOS window on the same machine! Obviously, I have done something in my code that has created a dependency on the environment provided by cygwin, but I have been at a complete loss as to discover what it is. My makefile does the same thing as the objcopy makefile, but the result of my compilation is something that only works under cygwin. I'd appreciate any ideas or pointers to information. -Original Message- From: Larry Hall [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 9:13 AM To: Liang, James; 'Cygwin List' Subject: RE: using shared libraries w/o cygwin James, If you want to build objcopy locally and have it linked against cygwin1.dll, just compile it with Cygwin's compiler. Don't use the '-mno-cygwin' flag. The 'binutils' package obviously builds 'objcopy' so you can consult that package's process if you're having problems with building your custom version. Larry At 10:44 AM 3/10/2004, you wrote: My current goal is to run my custom build of objcopy WITH cygwin1.dll Is there a special compile or link time flag that tells it to link the cygwin1.dll instead of doing whatever it's doing now that's causing the crashes? -Original Message- From: Larry Hall [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 7:59 PM To: Liang, James; '[EMAIL PROTECTED]' Subject: Re: using shared libraries w/o cygwin At 07:35 PM 3/9/2004, you wrote: Hi. I've got a port of objcopy that I'd like to run on Windows systems. I'd rather not have to install cygwin on the machine that I'm going to be running this tool on. The problem I'm having is that whenever I run my program on a file, it appears to have a STACK_VIOLATION on a call to malloc. It works just fine under Linux, under cygwin, and can print the usage statement and things like that under DOS, but crashes in DOS whenever I actually pass it a data file. So far, the only explanation I can come up with is that there's some sort of failure during the dynamic libraries. Is there any way I can setup a DOS environment to make it run? I tried statically linking in bfd, but that didn't seem to the problem either. Could this be caused by something else? The 'objcopy' that comes with the 'binutils' package works fine when invoked directly from a DOS prompt (outside of a Cygwin shell). Of course, that one comes with Cygwin and links to cygwin1.dll. If you don't want to have to install Cygwin or manage a local copy of cygwin1.dll on your target systems, then this isn't an option for you. However, if you're using a custom built version of 'objcopy' that doesn't use cygwin1.dll, then the question is really off-topic for this list. You'll need to debug the problem yourself. Sorry. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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/ -- 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/
Re: Difference between just having cygwin1.dll and running under cygw in
There's really no significant difference, assuming your DOS shell can see cygwin1.dll and it's the same one you get when you run under your Cygwin shell (having more than 1 cygwin1.dll on your system is a *very* bad idea anyway). Certainly, there can be all kinds of differences in the environment, literally, but it should be pretty obvious if you're dependent on some environment variable or something that's not set for Windows. Maybe you just need to debug it and see where the problem is and why you get it. Like I said, objcopy that comes with Cygwin's binutils works just fine for me outside of a Cygwin shell so it's not a problem with the tool in general. Larry At 03:17 PM 3/11/2004, you wrote: What's the difference between running an executable in the cygwin environment and running it in a Win2K DOS shell on the same machine(which obviously has cygwin1.dll)? As I mentioned in another thread of mine, I have a program(port of objcopy) that I've compiled that runs just fine under cygwin, but crashes with a stack violation whenever I run it under a DOS window on the same machine! Obviously, I have done something in my code that has created a dependency on the environment provided by cygwin, but I have been at a complete loss as to discover what it is. My makefile does the same thing as the objcopy makefile, but the result of my compilation is something that only works under cygwin. I'd appreciate any ideas or pointers to information. -Original Message- From: Larry Hall [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 10, 2004 9:13 AM To: Liang, James; 'Cygwin List' Subject: RE: using shared libraries w/o cygwin James, If you want to build objcopy locally and have it linked against cygwin1.dll, just compile it with Cygwin's compiler. Don't use the '-mno-cygwin' flag. The 'binutils' package obviously builds 'objcopy' so you can consult that package's process if you're having problems with building your custom version. Larry At 10:44 AM 3/10/2004, you wrote: My current goal is to run my custom build of objcopy WITH cygwin1.dll Is there a special compile or link time flag that tells it to link the cygwin1.dll instead of doing whatever it's doing now that's causing the crashes? -Original Message- From: Larry Hall [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 09, 2004 7:59 PM To: Liang, James; '[EMAIL PROTECTED]' Subject: Re: using shared libraries w/o cygwin At 07:35 PM 3/9/2004, you wrote: Hi. I've got a port of objcopy that I'd like to run on Windows systems. I'd rather not have to install cygwin on the machine that I'm going to be running this tool on. The problem I'm having is that whenever I run my program on a file, it appears to have a STACK_VIOLATION on a call to malloc. It works just fine under Linux, under cygwin, and can print the usage statement and things like that under DOS, but crashes in DOS whenever I actually pass it a data file. So far, the only explanation I can come up with is that there's some sort of failure during the dynamic libraries. Is there any way I can setup a DOS environment to make it run? I tried statically linking in bfd, but that didn't seem to the problem either. Could this be caused by something else? The 'objcopy' that comes with the 'binutils' package works fine when invoked directly from a DOS prompt (outside of a Cygwin shell). Of course, that one comes with Cygwin and links to cygwin1.dll. If you don't want to have to install Cygwin or manage a local copy of cygwin1.dll on your target systems, then this isn't an option for you. However, if you're using a custom built version of 'objcopy' that doesn't use cygwin1.dll, then the question is really off-topic for this list. You'll need to debug the problem yourself. Sorry. -- Larry Hall http://www.rfk.com RFK Partners, Inc. (508) 893-9779 - RFK Office 838 Washington Street (508) 893-9889 - FAX Holliston, MA 01746 -- 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/ -- 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/ -- 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/
