You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@stdcxx.apache.org by Eric Lemings <le...@roguewave.com> on 2007/03/14 00:08:29 UTC
Next Darwin/Mac OS X Porting Problem...
The util/localedef.cpp source file fails to compile.
...
gcc runall.o cmdopt.o output.o util.o exec.o display.o -o exec
-L./stdcxx/lib -lstd -lsupc++ -lgcc_eh -lm
gcc -c -I./stdcxx/include/ansi -D_RWSTDDEBUG -D_RWSTD_USE_CONFIG
-I./stdcxx/include -I./stdcxx/include -I./stdcxx/include/loc -pedantic
-nostdinc++ -g -W -Wall -Wcast-qual -Winline -Wshadow -Wwrite-strings
-Wno-long-long -Wcast-align ./stdcxx/util/localedef.cpp
In file included from ./stdcxx/util/localedef.cpp:33:
./stdcxx/include/ansi/clocale:62: error: '::lconv' has not been declared
./stdcxx/include/ansi/clocale:64: error: '::localeconv' has not been
declared
./stdcxx/util/localedef.cpp: In function 'bool
process_command_line(ProgramOptions*, int, char**)':
./stdcxx/util/localedef.cpp:468: warning: unused variable 'errors'
make[2]: *** [localedef.o] Error 1
make[1]: *** [util] Error 2
make: *** [libstd] Error 2
On Darwin (Mac OS X) platforms, these symbols are defined in the
/usr/include/_locale.h file which is included by the
/usr/include/locale.h file.
$ more /usr/include/locale.h
/*
...
*/
#ifndef _LOCALE_H_
#define _LOCALE_H_
#include <_locale.h>
#define LC_ALL 0
#define LC_COLLATE 1
#define LC_CTYPE 2
#define LC_MONETARY 3
#define LC_NUMERIC 4
#define LC_TIME 5
#define LC_MESSAGES 6
#define _LC_LAST 7 /* marks end */
__BEGIN_DECLS
char *setlocale(int, const char *);
__END_DECLS
#endif /* _LOCALE_H_ */
$ more /usr/include/_locale.h
/*
...
*/
#ifndef __LOCALE_H_
#define __LOCALE_H_
#include <sys/cdefs.h>
#include <_types.h>
struct lconv {
...
};
#ifndef NULL
#define NULL __DARWIN_NULL
#endif /* ! NULL */
__BEGIN_DECLS
struct lconv *localeconv(void);
__END_DECLS
#endif /* __LOCALE_H_ */
The reason why the localedef.cpp source file fails to compile is the
order of search paths for include files. The include directive for
_locale.h finds STDCXX's _locale.h header file before it finds the
system's _locale.h header file. The preprocessed localedef.cpp file
looks like this.
# 1 "./stdcxx/include/ansi/clocale" 1
# 54 "./stdcxx/include/ansi/clocale"
# 1 "/usr/include/../include/locale.h" 1 3 4
# 40 "/usr/include/../include/locale.h" 3 4
# 1 "./stdcxx/include/loc/_locale.h" 1 3 4
# 41 "/usr/include/../include/locale.h" 2 3 4
# 52 "/usr/include/../include/locale.h" 3 4
extern "C" {
char *setlocale(int, const char *);
}
# 55 "./stdcxx/include/ansi/clocale" 2
namespace std {
using ::lconv;
using ::localeconv;
using ::setlocale;
}
What to do about this problem? Not sure. Just reporting it. ;)
Eric.
Re: Next Darwin/Mac OS X Porting Problem...
Posted by Martin Sebor <se...@roguewave.com>.
Eric Lemings wrote:
> Yep that fixed it. Opened up STDCXX-356 so you can track it.
Thanks! I've checked in your patch (although I forgot your
attribution -- sorry about that).
Martin
>
> Brad.
>
>> -----Original Message-----
>> From: Martin Sebor [mailto:sebor@roguewave.com]
>> Sent: Tuesday, March 13, 2007 8:34 PM
>> To: stdcxx-dev@incubator.apache.org
>> Subject: Re: Next Darwin/Mac OS X Porting Problem...
>>
>> Eric Lemings wrote:
>>>
>>> The util/localedef.cpp source file fails to compile.
>>>
>>> ...
>>> gcc runall.o cmdopt.o output.o util.o exec.o display.o -o exec
>>> -L./stdcxx/lib -lstd -lsupc++ -lgcc_eh -lm
>>> gcc -c -I./stdcxx/include/ansi -D_RWSTDDEBUG -D_RWSTD_USE_CONFIG
>>> -I./stdcxx/include -I./stdcxx/include -I./stdcxx/include/loc
>> ^^^^^^^^^^^^^^^^^^^^^^
>>
>> This is the problem. You don't want ./stdcxx/include/loc
>> in the search path.
>>
>> I was going to continue with: "Look at one of our build
>> logs for an example of the correct command line:
>> http://people.apache.org/~sebor/stdcxx/results/redhat_as-5.0-e
>> m64t-gcc-32b-4.1.1-11s-log.gz.txt"
>> but I see we have -I$(TOPDIR)/include/loc there for the
>> utilities as well, and always have! It should be just
>> a matter of taking it out. Can you open a new issue for
>> this?
>>
>> Martin
>>
>>
RE: Next Darwin/Mac OS X Porting Problem...
Posted by Eric Lemings <le...@roguewave.com>.
Yep that fixed it. Opened up STDCXX-356 so you can track it.
Brad.
> -----Original Message-----
> From: Martin Sebor [mailto:sebor@roguewave.com]
> Sent: Tuesday, March 13, 2007 8:34 PM
> To: stdcxx-dev@incubator.apache.org
> Subject: Re: Next Darwin/Mac OS X Porting Problem...
>
> Eric Lemings wrote:
> >
> > The util/localedef.cpp source file fails to compile.
> >
> > ...
> > gcc runall.o cmdopt.o output.o util.o exec.o display.o -o exec
> > -L./stdcxx/lib -lstd -lsupc++ -lgcc_eh -lm
> > gcc -c -I./stdcxx/include/ansi -D_RWSTDDEBUG -D_RWSTD_USE_CONFIG
> > -I./stdcxx/include -I./stdcxx/include -I./stdcxx/include/loc
> ^^^^^^^^^^^^^^^^^^^^^^
>
> This is the problem. You don't want ./stdcxx/include/loc
> in the search path.
>
> I was going to continue with: "Look at one of our build
> logs for an example of the correct command line:
> http://people.apache.org/~sebor/stdcxx/results/redhat_as-5.0-e
> m64t-gcc-32b-4.1.1-11s-log.gz.txt"
> but I see we have -I$(TOPDIR)/include/loc there for the
> utilities as well, and always have! It should be just
> a matter of taking it out. Can you open a new issue for
> this?
>
> Martin
>
>
Re: Next Darwin/Mac OS X Porting Problem...
Posted by Martin Sebor <se...@roguewave.com>.
Eric Lemings wrote:
>
> The util/localedef.cpp source file fails to compile.
>
> ...
> gcc runall.o cmdopt.o output.o util.o exec.o display.o -o exec
> -L./stdcxx/lib -lstd -lsupc++ -lgcc_eh -lm
> gcc -c -I./stdcxx/include/ansi -D_RWSTDDEBUG -D_RWSTD_USE_CONFIG
> -I./stdcxx/include -I./stdcxx/include -I./stdcxx/include/loc
^^^^^^^^^^^^^^^^^^^^^^
This is the problem. You don't want ./stdcxx/include/loc
in the search path.
I was going to continue with: "Look at one of our build
logs for an example of the correct command line:
http://people.apache.org/~sebor/stdcxx/results/redhat_as-5.0-em64t-gcc-32b-4.1.1-11s-log.gz.txt"
but I see we have -I$(TOPDIR)/include/loc there for the
utilities as well, and always have! It should be just
a matter of taking it out. Can you open a new issue for
this?
Martin