From: Hans-Bernhard Broeker <broeker AT physik DOT rwth-aachen DOT de>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: i686-pc-msdosdjgpp-g++ problems (long)
Date: 11 Nov 2002 15:27:03 GMT
Organization: Aachen University of Technology (RWTH)
Lines: 59
Message-ID: <aqoi87$73t$1@nets3.rz.RWTH-Aachen.DE>
References: <lrplsuounbjm9n878rvu4e4sobqofcu437 AT 4ax DOT com> <aqfvt3$6t$1 AT antares DOT lu DOT erisoft DOT se> <taunsusrk60vfe987b0a0ncp0u2cqkh7of AT 4ax DOT com> <1036779663 DOT 158618 AT queeg DOT ludd DOT luth DOT se> <1h6osuka51oan46817ptm2o1loq3k6fqm7 AT 4ax DOT com> <200211082039 DOT gA8Kdck00835 AT envy DOT delorie DOT com> <c5aosuktk341qeu7fj7gj8954a32ktpk1a AT 4ax DOT com> <1036845028 DOT 195290 AT queeg DOT ludd DOT luth DOT se> <si3qsugank9hsrjrig0m72dne3rb8gm6hj AT 4ax DOT com>
NNTP-Posting-Host: acp3bf.physik.rwth-aachen.de
X-Trace: nets3.rz.RWTH-Aachen.DE 1037028423 7293 137.226.32.75 (11 Nov 2002 15:27:03 GMT)
X-Complaints-To: abuse AT rwth-aachen DOT de
NNTP-Posting-Date: 11 Nov 2002 15:27:03 GMT
Originator: broeker@
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

Charles Wilkins <chas AT pcscs DOT com> wrote:
>   My gut feeling, based on observation, tells me that a linux hosted
> libstdc++-v3 does not support djgppv2 as a target in its present form
> or if you are standing on the other side of the fence, the djgppv2
> target doesn't support the libstdc++-v3 linux host.

The problem is somewhere between the DJGPP runtime and the libstdc++.
But there is not really such a thing as a libstdc++ "hosted"
somewhere.  It's essentially just stored on Linux, but has no other
links to that platform.  The .a file should usually be identical to
one built natively using DJGPP itself (or to the pre-built one).

I strongly suspect a linker script problem.  E.g. the wrong libgcc
might be used, either by the final installed toolchain or by the
cross-build of libstdc++ itself.  Or libgcc itself might be
referencing the wrong libstdc++.

>   It is only when linking against libstdcxx.a that the SIGSEGV occurs.
> So this tells me to look at all sources that are used to create
> libstdcxx.a.

Be sure to also consider the build setup files, i.e. Makefiles and
linker scripts.  Literally any file in the config/msdos subdirectory
that the build process actually uses (or fails to use) could be the
root of the problem.

> they use 'cxx' in their place.  On the linux / libstdc++-v3 cross
> compiler build, is it possible that the libstdc++ headers, which do in
> fact use c++ in their name are causing the DOS exe crash due to the
> 8.3 file limitation? 

No. Because none of those file names are even visible to the
executable (they're buried in the debug info section).  DOS doesn't
have any way of knowing what the include file names were, at build
time.

>   I think I am going to go through the entire source tree for
> libstdc++-v3 and change all sources and their references to be
> compliant with 8.3 notation and see what happens.  If I am lucky
> enough to get it to build, maybe it will fix this problem.

Don't.  A setup like this is almost completely unmaintainable.  GCC
maintainers know that, which is why the provided better methods, like
the header file name mapping table.  This maps a C++ header name to an
actual, file name(s) representable on the host platform.

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

> not exactly a productive gdb session...

You're supposed to ask gdb for whatever information about the crash.
The most crucial command being "where", alias "backtrace" or "bt" for
short.

-- 
Hans-Bernhard Broeker (broeker AT physik DOT rwth-aachen DOT de)
Even if all the snow were burnt, ashes would remain.