From: Andris Pavenis To: djgpp-workers AT delorie DOT com, 2boxers <2boxers AT comcast DOT net> Subject: Re: djcrx203.zip refresh (June 2002) Date: Tue, 12 Nov 2002 10:28:20 +0200 User-Agent: KMail/1.4.7 References: <10211120238 DOT AA21596 AT clio DOT rice DOT edu> <002501c28a10$b1612a00$021ca8c0 AT helm> In-Reply-To: <002501c28a10$b1612a00$021ca8c0@helm> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Message-Id: <200211121028.20817.pavenis@latnet.lv> Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id gAC8S0018766 Reply-To: djgpp-workers AT delorie DOT com On Tuesday 12 November 2002 07:59, 2boxers wrote: > > I haven't heard anything from anyone on this. It's been downloaded > > dozens of times, but that may have been by mirrors and web caches. > > Well, the refresh it is definitely a step in the right direction. I know > of at least two different build errors corrected when building the linux > host cross compiler against the official gcc releases. > > > Since it's been 3 weeks, if I don't hear anything negative soon I'll > > put it on DJ's incoming to move to Simtel > > A few comments and questions... All of these questions and comments > reference the linux host xgcc targetting djgpp. > > Documentation: > Not that I have anything negative to say about what is included in the > refresh or in the djcrx203.zip package, as I have yet to get a satisfactory > build from it, but clearly one thing that this updated package release is > missing is updated documentation. As a result, the existing faq, howto and > readme's do little more than vaguely outline a process that even the most > knowledgeable C programmers and linux gurus would characterize as "tricky". > At least if there was solid documentation, if you ran into a bug with the > build process, you would have a better chance of realizing that it _is a > bug_ with sources, perhaps other than djgpp sources, and not be left > wondering if there is somthing wrong with your particular build method. > One example is limits.h. I am still not 100% clear on how to properly > configure the gcc build so that the dj version of limits.h is seen, used > and 'fixed' and not other headers that possibly should 'not' be fixed. > > I have a few general questions that I would appreciate some answers too > that pertain to using djcrx203. > > The patch.lib located in ~/cross... what is it for? I realize it modifies > the linker script, but when applied, it causes the libstdc++ build to fail > and the compilers not to work. Maybe this question seems foolish, but why > is this patch in this package? > > Is djcrx203.zip meant to be built with vanilla gcc-3.2 and binutils-2.13 > sources or does it require gcc32s.zip and bnu213s.zip? > > What exactly are the differences between the gcc32s from the djgpp file > archives and the vanilla fsf gcc-3.2? Download archive gcc32s2.zip. It contains all diffs and shell script for patching gcc-3.2 and generating gcc32s.zip (gcc32s.zip was generated file for me, similary as all binary archives). No readme files though, but I think script is not too complicated. > Can anybody confirm a successful build (again, this refers only to the > linux host xgcc build) and C++ function using djcrx203, binutils-2.13, and > gcc-3.2? I built earlier practically all GCC versions since 2.95 time as Linux to DJGPP cross-compilers. For 2.95 line I also put scripts for building Linux hosted cross-compiler for DJGPP and also cross-building native compiler for DJGPP under Linux (as far as I remeber, "official" build of gcc-2.95.3 on Simtelnet was done in that way). Later I built also various gcc-3.0.X versions as Linux hosted cross-compiler, gcc-3.1. Some time ago had some problems with building gcc-3.2 as cross-compiler for DJGPP caused by different build environment. I'm now working in Finland and tried to do a build on a different machine. After fixing some small problems (in my build environent here) gcc-3.2 builds as Linux hosted cross-compiler without problems, however I haven't tested it seriously yet. Some hints (I assume that target name is i586-pc-msdosdjgpp and prefix is /usr and) 1) One needs DJGPP headers at /usr/i586-pc-msdosdjgpp/sys-include. One can also use cofigure option --with-headers instead as in this case header files will be copied to to the location mentioned above. 2) DJGPP libs from djcrxXXX.zip at /usr/i586-pc-msdosdjgpp/lib 2) Working cross-binutils at the same prefix and for the same target 3) stubify somewhere on path. 4) patched (for DJGPP) sources of gcc-3.2. Unpack gcc32s2.zip from DJGPP distribution, put gcc-3.2.tar.gz or gcc-3.2.tar.bz2 in the same directory and run unpack-gcc.sh there (script from gcc-3.2.tar.gz). Also make sure You're using autoconf-2.13 but not 2.5X. 5) Configure in directory different from source one. Also use configure options --with-as and --with-ld to point (full path) to cross-assembler and cross-linker. Otherwise compiler will build but not all features (eg. assembler ones) will be used. 6) Have existing directory /usr/gcc-lib/i586-pc-msdosdjgpp/3.2 when running make (unless You're builing GCC with root permissions) 7) There may be need to rename C++ header directory after that, but I don't remeber exactly as I haven't tested it yet. Hopefull I have'n forgot something significant. I would be nice if somebody would go through this and update docs in djcrx. I don't have plans to do it myself in near future. Andris