NNTP-Posting-Date: Sat, 09 Nov 2002 08:23:44 -0600 From: Charles Wilkins Newsgroups: comp.os.msdos.djgpp Subject: Re: i686-pc-msdosdjgpp-g++ problems (long) Date: Sat, 09 Nov 2002 09:25:40 -0500 Message-ID: References: <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> <1036845028 DOT 195290 AT queeg DOT ludd DOT luth DOT se> X-Newsreader: Forte Agent 1.92/32.570 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit 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