From: "Kai Ruottu" Organization: MTV3 Internet To: 2boxers <2boxers AT comcast DOT net>, libstdc++-ml , djgpp-workers-ml , crossgcc-ml Date: Mon, 11 Nov 2002 15:40:27 +0200 MIME-Version: 1.0 Subject: Re: cross-gcc build for a linux host for the msdosdjgpp target problems Message-ID: <3DCFCF6B.25752.31A4FAE@localhost> In-reply-to: <002601c2878f$2a61f0d0$021ca8c0@helm> X-mailer: Pegasus Mail for Windows (v4.01) Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7BIT Content-description: Mail message body Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk 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