cross-gcc build for a linux host for the msdosdjgpp target problems

[Kai Ruottu]

Charles Wilkins wrote:

> Just as a sidenote, I didn't try this with newlib yet.  If anybody thinks
> that using newlib instead of glibc might help with any of this, please speak
> up.

 Neither newlib nor glibc has been ported for the DJGPP2-target, so
they have nothing to do with this target and any how-to instructions
should not mention them associated with the DJGPP2-target...

> I tried starting from scratch and this time using djcrx204_alpha.zip instead
> of djcrx203.zip.

 These packages should contain all the needed target headers and
libraries needed during the GCC-build. Other DJGPP2-packages with
extra libraries (Curses, termcap, graphics,...) will be needed in
order to get more than the 'minimal C library'...

> I am basically doing everything in this faq with some changes to correct
> build errors.
> http://www.delorie.com/howto/djgpp/linux-x-djgpp.html

 Haven't seen this, but if it follows the RMS-instructions in the GCC-
manual, things should be quite ok...

> Additionally, I have consulted the crossgcc faq, the binutils homepage, the
> gcc homepage, the various mailing list archives as well as given google a
> few new grey hairs...

 Can you remmember what faq or something hinted you to use newlib or
glibc for the DJGPP2-target, although DJGPP2 is well-known to have
its own 'proprietary C-library', which should be used always with
this target ?  This info is badly wrong...  BUT newlib was ported to
the old 'DJGPP-1.x', ie. 'GO32' target...

> djcrx203.zip with djdev203_u2.zip

 Needed, contains the DJGPP2-specific target headers and libraries as
prebuilt... I however didn't see the latter in the Finnish 'Simtel'
mirror...

> cd ~/binutils-2.13-obj
> ../binutils-2.13-src/configure --target=i686-pc-msdosdjgpp --prefix=/usr/loc
> al/compiler/cross2/djgpp --without-newlib
> make
> make install

 After this you should follow the GCC-manual and copy the target
headers, ie. the DJGPP2-headers into your chosen:
  $prefix/$target/include
ie. into :
  /usr/local/compiler/cross2/djgpp/i686-pc-msdosdjgpp/include
and the DJGPP2-libraries into '$prefix/$target/lib', ie. into :
  /usr/local/compiler/cross2/djgpp/i686-pc-msdosdjgpp/lib
You already had the target binutils in '$prefix/$target/bin'
after the 'make install' in binutils build...

 There is a bug in current GCCs and the 'limits.h' coming with
the target headers must be seen in '$prefix/$target/sys-include',
so that the GCC's own 'limits.h' will be fixed to '#include_next'
the target's own 'limits.h'.  The other target headers should not
be seen by 'fixincludes', ie. the DJGPP2-headers are assumed to
already be 'suitable for GCC'... Although the header-fixing should
work, it is always safe to follow the old phrase: "Don't fix it,
if it ain't broken". Generally these vain fixes may not work but
instead may break the toolchain.

> /usr/local/compiler/cross2/djgpp/bin/i686-pc-msdosdjgpp-ar needs to be in
> the path so that the cross gcc builds.
> /usr/local/compiler/cross2/djgpp/bin/i686-pc-msdosdjgpp-ranlib needs to be
> in the path so that cross libstdc++-v3 builds.
> This can be done by putting the whole directory in the path or by creating
> links to just the files from a directory in the path.
> Both ways work.

 The '$prefix/bin' of course is selected so that it is a 'local
bin'-directory on path, while the '/usr/bin' is the 'system bin'-
directory. The default '$prefix', '/usr/local', may usually be in
the path already, so it is chosen as the default 'local prefix'.

> cd ~/gcc-3.2-obj
> ../gcc-3.2-src/configure --target=i686-pc-msdosdjgpp --prefix=/usr/local/com
> piler/cross2/djgpp
> --without-newlib
> --with-headers=/usr/local/compiler/cross2/djgpp/i686-pc-msdosdjgpp/include
> --with-libs=/usr/local/compiler/cross2/djgpp/lib

 The target headers seemed to be preinstalled in the right place
($prefix/$target/include), but why the target libraries were
put into '$prefix/lib', not into '$prefix/$target/lib' ?

> /usr/local/compiler/cross2/djgpp/i686-pc-msdosdjgpp/lib

 This however was mentioned in your configure command as a stand-
alone parameter. Cannot say how 'configure' handled it then....

> The --with-headers=path was essential to prevent conflicts with limits.h and
> other subsequent make failures.
>    i.e. PATH_MAX undefined in functions called by getpwd.c
>          LONG_MIN undefined in functionc called by fibheap.c

 Only symlinking it to the '$prefix/$target/sys-include' would have
been enough. This option causes all the target headers being copied
into '$prefix/$target/sys-include', not only the required 'needed to
be seen' 'limits.h'...

> The --without-newlib and the --with-libs don't seem to have any affect on
> the end result, but I list them since I feel they are correct with this
> build process, however I could be wrong.

 These options are not needed...
 
> It would seem that there is a problem with libstdc++-v3 configure script and
> the djgpp target where the newlib headers are being used when they shouldn't
> be.

 The current gcc-3.3 snapshots may/may not have this issue fixed, 
anyhow I built the libstdc++-v3 there without this problem... It
may be that I fixed it with the Mingw, Solaris2 etc. targets, which
also had identical problems... There was a discussion about the
Solaris2 target on the CrossGCC-list and the Mingw-specific patches
for gcc-3.x include fixes for this problem. So, following the same
rules the DJGPP2-issue can be fixed. But the newer GCC-sources are
assumed to have these fixes merged...

> In order to use the i686-pc-msdosdjgpp-gcc, I had to link libstdcxx.a to
> libstdc++.a and libsupcxx.a to libsupc++.a

 The setting in the DJGPP2 main target config header,
'gcc/config/i386/djgpp.h' sets the resulted 'cc1plus' to search
for 'libstdcxx.a', not 'libstdc++.a', ie. whatever the host is,
the DJGPP2-target C++ library has the same name as in DOS, seems
to be the bright idea... Or maybe it is not so bright. What sense
is in 'DOSifying' Unix or Win32 ?  When the name isn't right for
DOS either...

 What on earth host then would require the name being this?  DOS ?
Not DOS because the 8+3 rule cuts it to be 'libstdcx.a'.
Win9x/NT/2k/XP?  Not the Win32-models because they approve the
name being 'libstdc++.a' there...  Not Unix-like systems either...

 Does someone really run DJGPP2-hosted GCCs on the Win32-platform,
not the expected Mingw- or Cygwin-hosted GCCs ?  And when running
DJGPP2-binaries on Win32, they don't accept the '+'s in the file
names ?

> Once the links are in place, I can compile a cpp program, but the
> executable yields an exception error under real mode DOS and Win32.

 This seems to happen with gcc-3.1-3.3 but gcc-3.0.4 worked still.
The gcc-3.1 and the gcc-3.3-20021104 snapshots produced a faulty
toolchain, so I am not surprised to see gcc-3.2 being broken in this
respect...

G:\tmp>hi_dj295
Hello world !!!

G:\tmp>hi_dj30
Hello world !!!

G:\tmp>hi_dj31
Exiting due to signal SIGSEGV
General Protection Fault at eip=0001cf79
eax=00000000 ebx=00000180 ecx=0003d358 edx=0000033f esi=00000054 
edi=000410a8
ebp=0058ff98 esp=0058ff94 program=G:\TMP\HI_DJ31.EXE
cs: sel=01a7  base=01800000  limit=0059ffff
ds: sel=01af  base=01800000  limit=0059ffff
es: sel=01af  base=01800000  limit=0059ffff
fs: sel=017f  base=00006f60  limit=0000ffff
gs: sel=01bf  base=00000000  limit=0010ffff
ss: sel=01af  base=01800000  limit=0059ffff
App stack: [00590000..00510000]  Exceptn stack: [00041004..0003f0c4]

Call frame traceback EIPs:
  0x0001cf79
  0x0001d175
  0x00001607
  0x0000ac62

 A simple workaround could be to use the 'libstdcxx.a' from the
native gcc-3.2 distribution. Just as one can use prebuilt C-libs
(in 'djcrx203.zip'), one can use prebuilt C++ libs. It may be
more than possible that some extra patches will be needed for the
DJGPP2-target, the plain vanilla FSF-sources don't have these yet
installed... The gcc-3.2 sources in the DJGPP2-archives could tell
what these patches are. It would be much better if these patches
would be available as a separate '.diff'-file...

 Because I really haven't gcc-3.2, only 3.1 and 3.3, I'm not sure
how well the 3.2 version of 'libstdc++.a' would work with them...

 Also the 'native' libgcc.a should be compared with the cross-built
one, if stripped their sizes, ie. their code should be identical.
Using 'cmp' should also tell which module(s) in the native and the
cross-built 'libstdc++.a' differ (sizes), and there is something
done in different ways...

 Anyhow I tried to look the breaking C++ executable on GDB and see
where it crashes... Unfortunately there seems to be nothing else
than the native-DJGPP2 GDB, so anyone already spoiled with the
Win32-hosted GDB-with-GUI's (like Insight), must step backwards
some years in time and refresh those GDB-commands in memory...
Anyway loading the executable and writing :

(gdb) run
Starting program: h:/usr/local/samples/cpluspls/hi_dj31.exe

Program received signal SIGSEGV, Segmentation fault.
0x0001cf79 in std::ostream::sentry::sentry(std::ostream&) ()
(gdb)

wasn't that hard and something one can find in the libstdc++-v3
sources was given as a hint...

 A Cygwin-x-DJGPP2 or Mingw-x-DJGPP2 'remote-GDB' would be nice,
but unfortunately there seems to be very few people left compiling
and debugging DJGPP2 apps on Win32-systems... Otherwise someone
would already have implemented a GUI-based debugger for the DJGPP2
target apps running on Win32 systems... There could be something
like a 'run-djgpp.exe' which runs the DOS-program as an subprocess,
filters its output to stdio/stderr and gives input to stdin,
and sends these/gets input from GDB via some interprocess method.
A nice project to any hacker interested in DOS/Win32 and knowing
how those DOS/DJGPP2-programs run on the Win32-systems. I don't
know enough about these things, but if a DOS/DJGPP2-program can
be run there, getting it to communicate with GDB should be fully
possible, I think...

 I don't know about 'dosemu' etc. on the Linux-side, but maybe
something equal could also be possible there, ie. a Linux/X11-hosted
Insight running DJGPP2-apps via the 'target sim', the 'simulator'
called as 'dosemu'...

Cheers, Kai


------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com