delorie.com/archives/browse.cgi | search |
From: | noer AT cygnus DOT com (Geoffrey Noer) |
Subject: | Re: String.h vs string.h question |
9 May 1997 02:24:38 -0700 : | |
Approved: | cygnus DOT gnu-win32 AT cygnus DOT com |
Distribution: | cygnus |
Message-ID: | <199705090313.UAA14307.cygnus.gnu-win32@rtl.cygnus.com> |
Original-To: | gnu-win32 AT cygnus DOT com |
Original-Cc: | noer AT cygnus DOT com (Geoffrey Noer) |
In-Reply-To: | <199705090113.SAA08234@nz1.netzone.com> from "Mikey" at May 8, 97 01:20:25 pm |
X-Mailer: | ELM [version 2.4 PL23] |
Original-Sender: | owner-gnu-win32 AT cygnus DOT com |
I was asked: > > So is mount -m reenabled, or what? > > Is that the String.h string.h fix, and if so so we need to reinstall to use > it? > > Confused. The header files fix in b18 has nothing to do with mount -m. I am making use of a gcc internal mechanism that allows you to create a mapping between header file names. String.h is really _string.h in the release. I added a mapping in a file called header.gcc which tells gcc that any references to String.h really mean _string.h. Similar conflicts are handled in the same way. Although this is what's happening inside the compiler, everyone should continue to #include the standard names. (The internal mapping should stay internal). -- Geoffrey Noer noer AT cygnus DOT com - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |