Date: Sun, 26 Jul 1998 12:11:12 +0300 (IDT) From: Eli Zaretskii To: Fabian Nunez cc: djgpp AT delorie DOT com Subject: Re: bugs with c++ compiler In-Reply-To: <6p9puu$58a$1@groa.uct.ac.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Precedence: bulk On 24 Jul 1998, Fabian Nunez wrote: > Your problem is that the guy who built gcc 2.8.x used a long filename > system (probably a win95 shell window) and so everything uses long > filenames (hence your problem with finding the .h file). He also gave > the standard C++ library its "proper" name, which is libstdcxx.a (9 > chars before the dot!). So your solution is to code under windows > (with lfn=y) and change RHIDE's setup so it links -lstdcxx (instead of > -lstdcx). There are alternatives if you want to code in a short > filename environment, but they are quite messy (involving a filename > substitution file - a new feature of 2.8.0 AFAIK). My advice is to > code in a long filename environment (we're in 1998 not 1978!) and to > change RHIDE's linker options. Your advice is sound, but it seems to imply that GCC 2.8.x won't work *unless* long file names are supported. This is incorrect. The DJGPP port of GCC 2.8.x works both with and without long file names. For example, if you install it on plain DOS (no Windows) it will work just fine. The problems with long file names only happen when a user unzips the distribution on Windows 9X, but does NOT enable long file names. It is possible to get even this situation right, but that's not something a garden-variety DJGPP installation would care about. The long names in the zip files are retained precisely *because* we want the distribution to work on both types of platforms. This has nothing to do with the system on which the zip file was prepared (you can prepare a zip file with long names even on plain DOS).