Date: Mon, 11 Nov 2002 10:12:51 -0500 From: 2boxers <2boxers AT comcast DOT net> Subject: Re: cross-gcc build for a linux host for the msdosdjgpp target problems To: kai DOT ruottu AT luukku DOT com Cc: djgpp-workers-ml , libstdc++-ml , crossgcc-ml Message-id: <00af01c28994$cd6293f0$021ca8c0@helm> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4910.0300 X-Mailer: Microsoft Outlook Express 5.50.4807.1700 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <3DCFCF6B DOT 25752 DOT 31A4FAE AT localhost> Reply-To: djgpp-workers AT delorie DOT com > 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... The only thing that hinted me into thinking that there was some significance to using newlib vs glibc, was the fact that the libstdc++ configure script was including newlib headers from ~/libstdc++-v3/config/os/newlib instead djgpp headers from ~/libstdc++-v3/config/os/djgpp > > 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 This was one of the first steps listed in the howto from delorie.com. I didn't specifically mention this in my e-mail because it was already in the howto. Even before building binutils, the DJGPP2-headers and DJGPP-2 libraries already are copied into '$prefix/$target/include' and '$prefix/$target/lib' Additionally, the program stubify must be built and installed to '$prefix/$target/bin' as mentioned in the howto. > 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. I will try just sym linking limits.h into '$prefix/$target/sys-include' and not use the configure option --with-headers which copies them all and see if this makes a difference. > > 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.... It was not a stand alone paramater, but rather one of the parameters of the --with-libs option. The --with-libs accepts multiple directories. It should read: --with-libs=/usr/local/compiler/cross2/djgpp/lib /usr/local/compiler/cross2/djgpp/i686-pc-msdosdjgpp/lib The effect of this was that libs from '$prefix/lib' are copied to '$prefix/$target/include' as showed in the attachments I provided. Using this option was more or less an experiment with trying to build without errors. > > 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'... Got it. I will try just sym linking limits.h into '$prefix/$target/sys-include' and not use the configure option --with-headers. Maybe something is breaking from using --with-headers. > > 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... Can you point me to the specific url or patches that you mentioned here? Are there gcc sources other than 3.2 that I should try that has these fixes merged? If so, specifically which versions? > 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. Did you try this? I try it and it does not eliminate the SIGSEGV error... Thenagain, I haven't tried the other things you have suggested yet, either... so it is likely that something else is broken, but only shows itself when using C++ headers and linking to libstdc++.a. > 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... Yes, this seems to be the case... > 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... I guess I should try this too. Thank you for the suggestions, I will post what I find. Most grateful, Charles Wilkins