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:
> ie. into :
> and the DJGPP2-libraries into '$prefix/$target/lib', ie. into :
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
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-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
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
> > 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 '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
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.
Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to firstname.lastname@example.org
More information about the crossgcc