Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT cygwin DOT com Mail-Followup-To: cygwin AT cygwin DOT com Delivered-To: mailing list cygwin AT cygwin DOT com Message-ID: <036201c5d04a$7f485010$1600a8c0@toyon.corp> From: "Peter J. Stieber" To: References: <045001c5cd2c$657579e0$1600a8c0 AT toyon DOT corp> <056901c5cd3e$3986d010$1600a8c0 AT toyon DOT corp> <434A5ADB DOT 2080602 AT byu DOT net> <20051010151806 DOT GC14608 AT trixie DOT casa DOT cgf DOT cx> <20051010153309 DOT GD14608 AT trixie DOT casa DOT cgf DOT cx> Subject: Re: 1.5.18: ld command generates stackdump Date: Thu, 13 Oct 2005 16:04:42 -0700 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-IsSubscribed: yes PS = Peter J. Stieber on 10/9/2005 7:59 PM: PS>>>> It's attached. I added the -t command to the g++ command so PS>>>> the loader would list the files it was processing when it breaks. PS>>>> The name of the object file in the last line should be PS>>>> SimpleInterpolationTable.o, but it gets truncated. PS>>>> (/home/pete/Build/lib/libUtilityg.a)SimpleInterpolmake: *** [slamem.exe] PS>>>> Error 1 >>>You may be hitting command line length limitations. I'm wondering if >>>the >>>core dump happens because the truncated argument was not >>>NUL-terminated. >>>Have you considered bundling arguments into a temporary file, then >>>passing >>>@filename as the lone argument to ld, to bypass the command-line >>>length >>>limitations? You may also want to try mounting ld's directory as >>>cygexec, >>>or trying a recent snapshot, both of which use cygwin magic to >>>increase >>>the command-line length of cygwin applications. CF = Christopher Faylor CF>> This seems like a real shot in the dark to me. CF>> What would not be terminating a truncated CF>> command line? Cygwin? That's not likely. CF>> CF>> AFAIK, only very recent CVS versions of CF>> binutils take '@' command line arguments, CF>> although cygwin will honor them itself for CF>> processes which are not started by a cygwin CF>> process. I don't see any indication that CF>> this is the problem here. CF>> CF>> If this is a command-line length problem then something like: CF>> CF>> mount -X -b c:/cygwin/bin /bin CF>> mount -X -b c:/cygwin/bin /usr/bin CF>> CF>>would probably fix it. CF>> CF>> See: http://cygwin.com/faq/faq-nochunks.html#faq.programming.make-execvp I tried this, but I am still seeing the problem. Calling the mount comment results in the following: CF> Btw, if the above doesn't fix this and you can't provide CF> any more details then it seems like your best bet would CF> be to build a debugging version of binutils and see where CF> the core dump is coming from. CF> CF> If you include "error_start:c:/cygwin/bin/gdb.exe" in CF> your CYGWIN environment variable, it will start gdb CF> automatically when a SEGV is encountered. Sorry in advance for the stupid questions, but... I downloaded the binutils source package, and extracted the source. When I ran ./configure --help I didn't see a --enable-debug option or anything I though was equivalent. Am I missing something? Do I also need to build a debug version of the cygwin DLL? Pete -- 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/