delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp-workers/2002/11/12/03:30:32

From: Andris Pavenis <pavenis AT latnet DOT lv>
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
Message-Id: <200211121028.20817.pavenis@latnet.lv>
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

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019