I've answered the question enough times to know that the current method of diagnosing and fixing this oh-too-common bug in the combonation of GCC 2.8.x and RHIDE. This HOWTO will diagnose the problem, show where the current documentation fails, and show the methods I know of to fix the bug.

    For this HOWTO, I assume you have the following environment:

An otherwise working version of GCC 2.8.x (you can compile C code with no sweat)
RHIDE v1.x
The desire to use C++ as a tool in the rest of the environment.
Windows 9x

    I will also assume you have read the DJGPP Faq.  Thoroughly.  If you
haven't, please close this HOWTO and read it first.  Don't worry, the rest of us
will wait.

    How do you check if your GCC is working?  On the command line(a Dos box in
Windows that points to your command line interpreter [commnand.com in most
cases]), type:

gcc -v

    And that will also tell you the version of your GCC.  If you get an error
message (anything other than "Reading specs from..."), stop reading, and fix
it.  The problems you are experiencing are outside the scope of this HOWTO.

    So we've established that GCC itself is functional.  We could further test
it by throwing it some simple C code,but I'm not a C programmer (but I play one
on the 'Net), so I assume you know how to compile C code with GCC.  Testing
further, we could see that it is truly RHIDE's fault by compiling C++ code on
the command line.  You should Definatly know how to do this, as it is in the
DJGPP Faq (You HAVE read the faq, right???).

    So by now, we know that GCC is otherwise working fine and dandy.  So the
problem must be when RHIDE is thrown into the mix.

    The current version of RHIDE that's distributed with DJGPP is.  That version
was built with/for GCC 2.7.x.  There are many documented bugs in 2.7.x when it
exists in an environment that doesn't support Long File Names.  DJGPP got around
it by tweaking with the way GCC interacts with files-the LFN Environment
variable.  In 2.7.x, it's set to "No" by default in the DJGPP.env file.  In
2.8.x, it's also set to "No" by default.

    So where's the Problem?

    Those No's are actually completly the opposite of each other.  Think of it
this way:

    In pure DOS, you'd want the LFN fix on.  In 2.7.x, you'd set LFN to "No" as
in "No, my environment doesn't use Long File Names".  In Windows, you'd want the
LFN variable set to "Yes" as in "Yes, my environemt supports Long File Names
(Sort of).

    But that changed in DJGPP's Implementation of GCC 2.8.x.  Why?  Well, the
rumors were flying around about Micro$oft attempting to Kill DOS off in Win98.
So the Yes/No thing changed-Now the LFN variable doesn't say much about the
environment; rather it's a flag for whether or not the LFN Fix is on-It's set to
"Yes" when you are in a NON-LFN environment.

    Sure, Kagenin, but what does this have to do with -lstdcx?

    Well, allow me to first explain some more things.  GCC's -l switch (that's
L, not One) is where you specify what libraries you are linking with.  For
example, if you were using Allegro, you'd need to specify -lalleg on you command
line.

    Ever looked into your DJGPP\lib directory?  You should, if you haven't
already.  GCC uses a specific format to store it's Libraries.  That's why you
can't usse GCC's libraries with MSVC or Borland's compilers.  They also have a
strict naming convention: The first three letters are lib, and it's extension is
a.  All the rest in between is free and clear-that's 5 letters to play with in a
Non-LFN environment.

    Now let's look at an oddball file-libstdcxx.a.  It's 9 letters long.  It's
also all the required libs to use G++.  If you are compiling a C++ file (and for
some reason, you couldn't use 'gxx' or 'g++' specifically), you'd need to link
with that file.

    It's worth digressing for a moment (unless you already know about it, in
which case you can skip it) to state that the file GCC.exe does not do any
compiling or linking of your code.  GCC itself is merely a front-end for all the
programs that do (the C Preprocessor, the compiler, the assembler, the linker,
the librarian, etc).  G++.exe (or gxx.exe of you are in a Non-LFN environment)
is merely a front-end for gcc -lstdcxx, and little else (well, it does some
other things, but they're outside the scope of this document as well).

    So if it's not appearant by now, let me spell it out for you.  RHIDE was
compiled under and targets GCC 2.7.x, and when it sees that DJGPP(GCC 2.8.x) has
set LFN to N, it thinks that it is in a Non-LFN environment, and uses short
names.

    It's looking for libstdcx.a.  The file is called libstdcxx.a.
--------------------------------------------------------------------------------

    Alright, Kagenin, you said something about where the documentation fails?

    Yeah, well, kinda sorta.  Before I say anything stupid, let me say that I
have the utmost respect for Eli.  His contributions to the community are
exponentially better than these feeble attempts at HOWTOs I'm writing.

    That said, the Faq does need a quick update, but I'm hoping this HOWTO
replaces the entry all together.  The Faq does address this issue, but it's not
clear that this is the problem described in the Faq, section 8.7.  It's like,
"Here's a solution.  It just goes with a different problem."  But not really.
Read section 8.7.  If you think that it explains the issue quite well, then,
well, why are you reading the rest of this document.  You should already know
how to fix the problem already.  But if you're like me, you skimmed over the
title of 8.7 (Unresolved Externals) and kept looking for something more
specific.

--------------------------------------------------------------------------------

    Alright, Kagenin, how do I fix it?  You are going to explain how, right?
Cause I'm falling asleep over that long explanation and it's late and I need to
get some sleep cause it's monday and I've already had to go to school, come
back, and then move heavy furnature for my grandmother.  Oops, sorry, that's
what I'm saying right now, not you.

    Of course.  I've explained the fixes many times on many different C++
newsgroups.  I know of 4 ways.

                Method A: Kagenin's stupid, and untested Hack/Kludge

  Easy-On the command line, change directory over to your djgpp\lib directory
and make a copy of libstdcxx.a, renaming it libstdcx.a.  If you're under
Linux/DosEmu, then I guess you could just make a Symbolic Link instead.  But
since Linux symlinks and Windows Shortcuts work two different ways, you kinda
have to waste the disk space.

  That method is Untested, and Unsupported.  I did this at first, but I don't
use it anymore.


                          Method B: The DJGPP.env Hack


    This is what the Faq tells you to do.  And it's kinda buggy.  The DJGPP.env
file is really the most unfriendly componant of the DJGPP compiler system.
Trailing whitespace, mismatched variables, etc, can make your life hard.  That
said, you need to add some lines.  Delorie Software's motto is "Making it harder
to hate computers."  My gripe is that I probably hate my computer more because
of that damn text file.  Enough ranting, tho.  DJ, you otherwise rule, dude.

  The lines you need to add are:

[RHIDE]
RHIDE_TYPED_LIBS. =stdcxx

    But you need to add that second line a couple more times.  And do you see
that space in there?  You need to change it- Remove the whitespace, and replace
it with a file extension you wish RHIDE to associate with C++ Source Files, so
it ends up looking like

RHIDE_TYPED_LIBS.cc=stdcxx
RHIDE_TYPED_LIBS.cpp=stdcxx
RHIDE_TYPED_LIBS.cxx=stdcxx

    Make sure all trailing whitespace is gone.  I don't like this method either,
as the environment file is a pain in the ass to troubleshoot.



                    Method 3- The rarely-used RHIDE.env file

    Somewhere in you DJGPP Directory Tree is a file called rhide_.env.  It's put
in a place where RHIDE automatically looks for the RHIDE.env file.  Rename it to
Rhide.env and add the lines from the above method in here instead.  Put them at
the bottom.  Here, you don't need the [RHIDE] line, either, so you should leave
that out.


                  Method 4- Become one of Robert's Beta Testers

    I hear that the problem is fixed in the current beta release of RHIDE.  I've
never used it, and won't attempt to offer information on it.


--------------------------------------------------------------------------------

    Jeeze, Kagenin, with all this information, why haven't you fixed the problem
yet?  You're so knowledgable on the topic, surely you must have insight on how
to fix the code, right?

    Hey, for crying out loud, I'm still a Minor, and I'm taking College courses
instead of wasting away in High School, and I have no stable source of Income,
let alone a computer I can call my own (I'm using the same computer the rest of
the family uses), and neither the time nor motivation to do such a task.
Besides, the sources are in C, and I already said I'm not a C programmer.  I'm a
Perl Hacker-In-Training, and I only know a little C++.  And besides, I hate
DOS.  And I don't even use DJGPP anymore (I'm using Mumit Khan's build of Egcs
for Mingw32 if you care).  I just write HOWTOs on some things I had problems
with when I was using DJGPP, and in some wannabe
hacker(http://www.tuxedo.org/~esr/) stint, and to call this a "Contribution to a
Community."  That's all ^_^.

All I can do is hope that it gets fixed in GCC 3(currently known as Egcs, if you
haven't been reading the news).

Kagenin
kagenin@cyberspace.org
--------------------------------------------------------------------------------