delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2002/11/09/09:30:25

NNTP-Posting-Date: Sat, 09 Nov 2002 08:23:44 -0600
From: Charles Wilkins <chas AT pcscs DOT com>
Newsgroups: comp.os.msdos.djgpp
Subject: Re: i686-pc-msdosdjgpp-g++ problems (long)
Date: Sat, 09 Nov 2002 09:25:40 -0500
Message-ID: <si3qsugank9hsrjrig0m72dne3rb8gm6hj@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>
X-Newsreader: Forte Agent 1.92/32.570
MIME-Version: 1.0
Lines: 123
NNTP-Posting-Host: 68.45.75.113
X-Trace: sv3-cZKv7UAQSB/3viIvuwfV7SRjWmtb3GXikigTV1eKe2kAGP9Ul0yQzQQLbxeVfRgW9Y8YX2um1/QIwQh!3VAunkwZ0ZAlOQmgcqNRWH23KteAi6Ml27ooTfgK4Z4XBtBDxZwcmRDf9qXGF7c9zuV4uzY=
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

>3. If you run out of ideas
  has never happened to me in 32 years...

  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 thought of either of these two cases is disturbing to me because
the cross compilers themselves work and the executables made using the
standard C library provided in djcrx2xx run under DOS and Win32.  So I
am confident that this is _not_ a bintuils issue and I am reasonably
certain that this is not a gcc-3.2 issue.  

  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.

  It would be helpful to hear from anyone who has successfuly built a
linux host C++ cross compiler with msdosdsgpp as the target with
semi-current sources including libstdc++.

/*
  I have yet to hear of one confirmed case that this cross compiler
was built under linux using libstdc++-v3 and gcc-3.2 with msdosdjgpp
as the target.  This is somewhat concerning, but not nearly to the
extent of giving up.  If anything, this strengthens my resolve to get
to the bottom of this.
*/

Just as an idea.
This may have been suggested by another, but the validity of it didn't
hit me until recently.

  I was looking over the header files for the DOS based DJGPP and
noticed that none of the headers use 'c++' in their names.  Rather,
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? 

  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.

  If it does work, I will make a diffs and patches for everything and
post patches on my website along with a revised howto with all of the
workarounds _as they pertain to linux as the host/build machine_.

  If it doesn't work, I will catch up on all of my weekend drinking
and start with fresh brain cells Monday morning...

>make sure that your libstdcxx.a does
>contain debug information and try to run this program in gdb to see
>what's amiss.
  I know how to compile with debug support for a program.
g++ -g welcome.cpp -o welcome.exe.  but as far as adding debug info to
libstdcxx.a, how do I do that?

>You'll probably need to copy libstdcxx.a's source files
>to where your program run or add the corresponding .o or .c or .cpp
>files to the link line.
  This could prove to be difficult considering that the 'program' runs
under DOS/Win32 and the 'source files' are stored on a linux
filesystem.  libstdcxx.a's source files are the entire libstdc++-v3
package aren't they?


-========================-
Gdb stuff:
-========================-

Here is the output of using gdb on welcome.exe
compiled with djgpp-g++ -g welcome.cpp -o welcome.exe

gdb welcome.exe

(gdb) list
1        welcome.cpp: No such file or directory (ENOENT).
        in welcome.cpp
(gdb)

(gdb) run
Starting program: c:/Archives/RIP2/DJGPP/bin/welcome.exe

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

not exactly a productive gdb session...
any suggestions to get more information?

Here is the output of using gdb on welcome.exe (no -g)
compiled with djgpp-g++ welcome.cpp -o welcome.exe

(gdb) list
1        globals.cc: No such file or directory (ENOENT).
        in globals.cc
(gdb)

(gdb) run
Starting program: c:/Archives/RIP2/DJGPP/bin/welcome.exe

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

Note that globals.cc is a source file in the libstdc++-v3 source tree.
The very first include directive in this file is #include
"bits/c++config.h"  Notice the c++ in the name.  Unlike the DOS
releases of DJGPP where this same file would be "bits/cxxconfig.h"

I am going to continue with the assumption that this will only work,
once all libstdc++-v3 source files and contents meet 8.3 criteria.

If this is the problem, then some patching is in order. I volunteer to
do this. If it is not the problem, then I will be needed some fresh
ideas...  
 
a grepping we will go....
Charles

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019