NNTP-Posting-Date: Mon, 11 Nov 2002 10:18:32 -0600
From: Charles Wilkins <chas AT pcscs DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: i686-pc-msdosdjgpp-g++ problems (long)
Date: Mon, 11 Nov 2002 11:20:29 -0500
Message-ID: <nrlvsuc4lm7a51ldthv8ul14i4f2vac4jr@4ax.com>
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> <aqoi87$73t$1 AT nets3 DOT rz DOT RWTH-Aachen DOT DE>
X-Newsreader: Forte Agent 1.92/32.570
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Lines: 57
NNTP-Posting-Host: 68.45.75.113
X-Trace: sv3-st1qUxio9RXc379IPdCuG2HH99KVcnXsaCjRkBRWPn7cqxHc+8EDxDRHUnDtkCiM8VViL8sEn5RRwjF!64K86/awjBe32Avt/gHmeI8ApZPKoXt8UxHOFMADRgipjwGLe7oW4oQcAHOKIs/osnkZSgw=
X-Complaints-To: abuse AT comcast DOT com
X-DMCA-Complaints-To: dmca AT comcast DOT net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.1
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com


>The problem is somewhere between the DJGPP runtime and the libstdc++.
I agree.

>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).
In my case, the libstdc++.a is significantly larger than the native
build libstdc++.a

>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++.
Very possible.  I am doing my best to look into this now.

>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.
I am backstepping all of the steps in my build proccess as well as
trying my best to consider all of the build setup files.

>> 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 found this out...

>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.
Too late... but it didnt fix the problem, so I know this wasn't it.

>> 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.
I will do more with gdb when I feel more confident that I am not doing
something that is breaking the build setup files.

All of your suggestions are good ones.

Thank you.  
Charles