From: karuottu AT freenet DOT hut DOT fi (Kai Ruottu) Newsgroups: comp.os.msdos.djgpp Subject: Re: Cross compilation Date: Sat, 03 May 1997 21:18:36 GMT Organization: Freenet Finland Lines: 122 Message-ID: <336baa8f.187990325@news.freenet.hut.fi> References: NNTP-Posting-Host: ketol243.tokem.fi To: djgpp AT delorie DOT com DJ-Gateway: from newsgroup comp.os.msdos.djgpp Precedence: bulk On Fri, 2 May 1997 08:25:04 GMT, Robert Humphris wrote: >Has anyone been successful in rebuilding the GNU C on a DOS box for >cross compilation? A couple of years ago I rebuilt gcc-2.4.5 (or some other 2.4.x-version) in a DOS-box for djgpp. That was tough enough and since that I have always used a UNIX-to-go32 cross-compiler when building gcc as a go32-hosted cross-compiler. I'm just as lazy when building cygwin32-hosted cross-compilers - I use my UNIX-to-cygwin32 cross-compiler. Never tried these kind of things under NT or 95... Or under OS/2 with emx - I have a UNIX-to-emx cross-compiler, but haven't tried yet any emx-hosted cross-compilers (needs some patching to gcc sources first...). Perhaps some day... I have built go32-hosted compilers for m68k-coff, i386-sco3.2, sparc-sun-sunos4.1, sparc-solaris2.5, cygwin32 and m68hc11 by cross-building them under UNIX with the Canadian Cross. >If so what pitfalls did you find? Are there any caveats that I should >know about? There is nothing wrong with DJGPP, emx or cygwin32, but DOS, 95, NT or OS/2 don't behave like UNIX. Configure and makefiles for gcc, binutils, libg++ etc. are made for UNIX. And building compilers for other hosts is thought to be done by cross-compiling with the Canadian Cross method. Not too much pain... Perhaps some day DJ gets DOS, Cygnus gets NT & 95, and Eberhard & Co. get OS/2 behave just like UNIX, but just using UNIX is so much easier (and cheaper: Linux, FreeBSD, Free SCO Open Server and Free SCO Unixware are much cheaper than Win95, NT or OS/2 for a home user or student). Just invest your 29 (SCO) to 39 bucks (InfoMagic/Walnut Creek - Linux) for a CDROM with UNIX, make a cross-compiler for go32 and start making go32-hosted cross-compilers the easiest way : configure --build=i486-linux --host=go32 --target=mips-x (this example is for Linux). Investigating the DJGPP-binaries (2.01?) I have now : ----------------------------------------------------------------------------------- J:\c_devel\djgpp\bin>gcc -v gcc version 2.7.2 J:\c_devel\djgpp\bin>gcc -print-search-dirs install: /usr/local/lib/gcc-lib/go32\2.7.2\ programs: /usr/local/lib/gcc-lib/go32\2.7.2\;/usr/local/lib/gcc-lib/go32\;/usr/lib/gcc/go32\2.7.2\;/usr/lib/gcc/go32\;/usr/local/go32\bin\go32\2.7.2\;/usr/local/go32\bin\ libraries: /usr/local/lib/gcc-lib/go32\2.7.2\;/usr/lib/gcc/go32\2.7.2\;/usr/local/go32\lib\go32\2.7.2\;/usr/local/go32\lib\;/usr/local/lib/go32\2.7.2\;/usr/local/lib/;/lib/go32\2.7.2\;/lib/;/usr/lib/go32\2.7.2\;/usr/lib/ ------------------------------------------------------------------------------------ reveals that DJ hasn't really thought how the cross-compilers will be added to the native-gcc path system. Some things that I would suggest: - the "install dir" for cc1.exe, cc1plus.exe etc. should be : /usr/local/lib/gcc-lib/// where version is in the format "2_7_2", not in the format "2.7.2" as in djgpp. This is easy to patch in the Makefile and 'version.c'. The target name cannot either be longer than the 8.3 format. - perhaps the "/usr/local/lib/gcc-lib/" could be stripped to "/gcc/lib/" as the "GCC_EXEC_PREFIX". This and the other environment variables and their effect to the search paths should be investigated. - Using only the GCC_EXEC_PREFIX can be enough to let all the compilers work from any disk. Here is the search paths from my native go32-compiler after setting GCC_EXEC_PREFIX to "f:/gcc/lib/": ------------------------------------------------------------- F:\gcc\bin>gcc-go32 -print-search-dirs install: /gcc/lib/go32/2_7_2/ programs: f:/gcc/lib/go32/2_7_2/;f:/gcc/lib/;/gcc/lib/go32/2_7_2/;/gcc/lib/go32/;/usr/lib/gcc/go32/2_7_2/;/usr/lib/gcc/go32/;/gcc/go32/bin/go32/2_7_2/;/gcc/go32/bin/ libraries: f:/gcc/lib/go32/2_7_2/;f:/gcc/lib/;/gcc/lib/go32/2_7_2/;/usr/lib/gcc/go32/2_7_2/;/gcc/go32/lib/go32/2_7_2/;/gcc/go32/lib/;/gcc/lib/go32/2_7_2/;/gcc/lib/;/lib/go32/2_7_2/;/lib/;/usr/lib/go32/2_7_2/;/usr/lib/ ------------------------------------------------------------ -The files "as.exe" and "ld.exe" can be put into the "install dir" (/gcc/lib/go32/2_7_2/" in the go32 case). The file "ld.exe" could be put into the PATH. - The file "ld.exe" can be common for multiple targets, and can be put therefore into some directory in the PATH. The file"as.exe" must be separate for every target. - support for the cross-targets will be included to the binutils by configuring them as follows: --enable-targets="go32, i386-sco3.2, i386-cygwin32, m68k-coff" so the command "ld -V" will give in this case : J:\ >ld -V ld version 2.6 (with BFD 2.6) Supported emulations: i386go32 i386coff i386pe m68kcoff Using the same "ld" for all the supported emulations requires patching the 'specs' files of the secondary targets, adding: -m after the "*link:" row. E.g. adding "-mm68kcoff" to the m68k-coff target compiler's "specs" file. So, to make some cross-compilers to work nicely with the "native" go32 compiler, you must now rebuild all the tools anew, the standard djgpp distribution just doesn't easily fit into a multi-target system... Regards, Kai R.