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

Mon Nov 11 07:10:00 GMT 2002

>  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
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:


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

> > The --with-headers=path was essential to prevent conflicts with limits.h
> > 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
> > the djgpp target where the newlib headers are being used when they
> > 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 ''), 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

Want more information?  See the CrossGCC FAQ,
Want to unsubscribe? Send a note to

More information about the crossgcc mailing list