Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (athena.apache.org: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: Problem with Visual Studio 2005
Date: Thu, 31 Jul 2008 10:56:00 -0600
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A49015E5950@exchmail01.Blue.Roguewave.Com>
Thread-Topic: Problem with Visual Studio 2005
Thread-Index: AcjymXm1poxzAC/oRiez7SrHRl/pZgAkarFw
From: "Jeremy Dean" <Jeremy.Dean@roguewave.com>
To: <dev@stdcxx.apache.org>

I can not duplicate the problem.  Looking at his config.h file he does
have a difference on this particular line:

// #define _RWSTD_NO_NL_TYPES_H

on my build on windows this is not commented out.

So what test would be  setting this?

Jeremy

-----Original Message-----
From: Martin Sebor [mailto:msebor@gmail.com]=20
Sent: Wednesday, July 30, 2008 5:03 PM
To: dev@stdcxx.apache.org
Subject: Re: Problem with Visual Studio 2005

Jeremy Dean wrote:
> I have a customer trying to use SourcePro edition 10, stdcxx 4.2.0 and

> is getting a failure when building with Visual Studio 2005.
> =20
> Windows Vista x32
> Visual Studion 2005
> =20
> ..\stdcxx-4.2.0\src\messages.cpp (217) : error C2065 'NL_CAT_LOCALE' :
> undefined identifier
>=20
> =20
>=20
> Any thoughts on this issue?

Not a clue. Can you reproduce it?

The NL_CAT_LOCALE macro is #defined in src/catalog.h which should be
#included at the top of messages.cpp. For the file not to be #included
neither of _RWSTD_NO_NL_TYPES_H and _RWSTD_NO_CATOPEN_CATGETS would have
to be #defined. These are config macros that are #defined when the
<nl_types.h> POSIX header is not present or usable, or when either of
the catopen() and catclose() functions declared in it is missing. AFAIK,
Windows doesn't have <nl_types.h> so _RWSTD_NO_NL_TYPES_H should be
#defined in the generated config header (as it is here, for example:
http://tinyurl.com/5orqrd) If it's not, something must be screwy with
the build environment. A good way to find out would be to compare the
customer's config.h header and/or log file with yours (or one of those
on our site:
http://stdcxx.apache.org/builds/4.2.0/logs/ -- follow the H and/or L
link for the platform/configuration closest to the customer's).

Martin