This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: wide character issues with gcc 3.2



From: Benjamin Kosnik <bkoz@redhat.com>
To: "Anthony Feick" <afeick@hotmail.com>
CC: libstdc++@gcc.gnu.org
Subject: Re: wide character issues with gcc 3.2
Date: Tue, 20 Aug 2002 13:06:18 -0700


> Gcc 3.2 on linux compiles and links our app, but -fshort-wchar
> doesn't seem to be working completely.  The compiler directive
> 'L' converts character strings properly, and wchar_t is the
> right size.  The problem is that "basic_string<wchar_t>" still
> thinks everything is 4-bytes.

...because the library has been compiled without this flag, for
starters. You'd have to pass it in with CXXFLAGS, or configure with
--enable-cxx-flags="-fshort-wchar"

I did this, but now I get a segfault in stl_alloc.h :

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1024 (LWP 3072)]
std::string::_Rep::_S_create(unsigned, std::allocator<char> const&) (__capacity=7, __alloc=@0xbffff810)
at /home/shared/software/gcc-3.2-obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_alloc.h:397
397 *__my_free_list = __result -> _M_free_list_link;
(gdb) bt
#0 std::string::_Rep::_S_create(unsigned, std::allocator<char> const&) (__capacity=7, __alloc=@0xbffff810)
at /home/shared/software/gcc-3.2-obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/stl_alloc.h:397
#1 0x400e2d25 in char* std::string::_S_construct<char const*>(char const*, char const*, std::allocator<char> const&, std::forward
_iterator_tag) (__beg=0x88db524 "muadclp", __end=0x88db52b "", __a=@0x40129728)
at /home/shared/software/gcc-3.2-obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:150
#2 0x400df014 in basic_string (this=0x370036, __s=0x88db52b "", __a=@0x88db524)
at /home/shared/software/gcc-3.2-obj/i686-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:732
#3 0x0840391f in __static_initialization_and_destruction_0 (__initialize_p=1, __priority=65535)
at ../../creatortech/portlib/PhotoshopTags.h:55
#4 0x084039b0 in _GLOBAL__I__ZN7PortLib15CPlatformBitmapC2Ev () at ../../creatortech/portlib/Path.h:261
#5 0x0871f2d5 in __do_global_ctors_aux ()
#6 0x0804e906 in _init ()
#7 0x4016e26a in __libc_start_main () from /lib/libc.so.6

Unfortunately, I don't have a 'simple' test case for this.

$ gcc -v
Reading specs from /home/shared/local/lib/gcc-lib/i686-pc-linux-gnu/3.2/specs
Configured with: ../gcc-3.2/configure --prefix=/home/shared/local --enable-shared --enable-threads=posix --enable-__cxa_atexit --e
nable-cxx-flags=-fshort-wchar
Thread model: posix
gcc version 3.2



There are additional issues with wide character support on BSD's, as
some of the underlying "C" library bits for C99 support in wchar.h,
wctype.h, are not implemented, but try to get this working on linux
first would be my suggestion.

-benjamin

Yes, I See FreeBSD has some distance to go before supporting wide character string functions:
http://www.freebsd.org/projects/c99/

That's too bad. We had been using a hack in our code to get systems without wide char string functions to work (convert the unicode to ascii then call the ascii string functions). But it doesn't look like that will be possible on FreeBSD without hacking libstdc++ itself.





_________________________________________________________________
Join the world’s largest e-mail service with MSN Hotmail. http://www.hotmail.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]