Message-ID: <3677C640.4455F78B@mail.pentek.com> Date: Wed, 16 Dec 1998 09:40:00 -0500 From: Charles Krug Organization: Pentek Corporation X-Mailer: Mozilla 4.5 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: Eli Zaretskii CC: djgpp AT delorie DOT com Subject: Re: Trying to isolate build errors. References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp AT delorie DOT com Eli Zaretskii wrote: > On Tue, 8 Dec 1998, Charles Krug wrote: > > > I'm cross compiling for an embedded system using manufacturer > > provided tools (which aren't that great) under djgpp make v3.77, > > using bash as the shell. At one point, specifically adding a > > second source file, make started failing at the link stage. > > It would be nice to hear more about the failures, like what were the > error messages. Frightfully dull, as it turns out. In response to the linker command line: make.exe: *** [bsp_bifo.out] Error -1 > You didn't explain anything about ``the other toolset'' you are using. > So I really cannot tell you anything useful about this. Texas Instruments C compiler and assembly language tools for the TI tms320c6x DSP, 2.11, dos version. 2.11 is TI's first stable iteration for dos. My tests under Unix using gmake were built successfully using v2.00 of the toolset. > In my experience, all of them are subtly incompatible. If you want to > use the DJGPP tools, stick to them, don't mix them with other tools. I was using make for the usual reason. I've never seen make crap out regardless of what I've specified as my $(CC). The compiler, optimizer, assembler, and linker are all TI's. Hence my inclination to suspect TI's tools, especially the linker. My interest in the older version of make is to eliminate one variable, so that I can email TI with confidence that I've adaquatly isolated the faulty element in my build chain. I am rather strongly inclined to suspect their lnk6x linker. First, the TI tools seem to have been ported from Unix rather badly. Link command lines tend to get rather long rather quickly. I suspect that they don't correctly handle command lines longer than 127 characters when they made the port. Second, my experience with the previous generation of TI DSP's is that the lnkcxx linker family is subtly broken, especially in handling filenames. Not simply LFN's either. Many valid dos filenames will cause TI's c3x/c4x linker to simply truncate the command line at that point > > The makefile worked correctly in the past under both djgpp and > > unix. It only began failing under djgpp when I added another > > source file to the dependency list. > > So let's investigate this problem, instead of looking for alternative > tools that would most probably get you into more trouble. Alternative? Can't really say how I've much alternative in this case, until I have time to build gcc as a TI cross compiler or until one of my DSP colleagues does so. The c3x/c4x has been done, so it's only a matter of time. I don't suspect that the djgpp port of gmake is at fault. I'm just trying to eliminate a variable, so TI doesn't turn around and say, "well, obviously your make is broken" when I seriously doubt that's the case. Charles -- Charles Krug, Jr. Application Engineer Pentek Corp 1 Park Way Upper Saddle River, NJ 07458