Description of problem: I am having trouble getting a simple C++ application to compile and link when trying to use C++ STL wide strings (the basic_string template instantiated for a wchar_t type - 'wstring'). In order to get wide string support, one must define __GLIBCPP_WCHAR_SUPPORT__. However, defining this causes the basic_string template instantiated for a char type ('string') to fail with a link error: test_bad.o: In function `basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::c_str(void) const': test_bad.o(.basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::gnu.linkonce.t.c_str(void) const+0x1b): undefined reference to `string_char_traits<char>::empty(void)' collect2: ld returned 1 exit status Version-Release number of selected component (if applicable): All components correspond to gcc 2.96-118: $ rpm -qa | grep 2.96 cpp-2.96-118.7.2 gcc-2.96-118.7.2 gcc-g77-2.96-118.7.2 gcc-objc-2.96-118.7.2 gcc-c++-2.96-118.7.2 libstdc++-2.96-118.7.2 libstdc++-devel-2.96-118.7.2 How reproducible: Every time. Very easily. Steps to Reproduce: 1. Untar attached test case 2. Run 'make' - this will attempt to build two executables - test_good and test_bad. Test_good will build successfully. test_bad will not. The only difference between them is that __GLIBCPP_WCHAR_SUPPORT__ is defined when compiling 'test.cpp' for test_bad. Actual results: When g++ is invoked to do the link for test_good, the executable links and runs correctly. However, when g++ is invoked to do the link for test_bad when test.cpp was compiled with -D__GLIBCPP_WCHAR_SUPPORT__, the link fails with the following error: test_bad.o: In function `basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::c_str(void) const': test_bad.o(.basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >::gnu.linkonce.t.c_str(void) const+0x1b): undefined reference to `string_char_traits<char>::empty(void)' collect2: ld returned 1 exit status Expected results: Both executables should link and run successfully. Additional info:
That's because you should not use -D__GLIBCPP_WCHAR_SUPPORT__, but instead -wchar-stdc++ switch which will take care of all stuff that's needed (ie. define this and use different stub libstdc++ for linking).
Created attachment 91914 [details] Tar file containing two files - 'test.cpp' and 'Makefile' This is a testcase for the bug reported here. When untarred, this will create a local directory named "test-widestl" which will contain two files, "test.cpp" and "Makefile". To run the test case, simply change dirs to "test-widestl" and run 'make'. This will first compile "test.cpp" without defining __GLIBCPP_WCHAR_SUPPORT__ and link it into an executable named "test_good". It will then compile "test.cpp" again with __GLIBCPP_WCHAR_SUPPORT__ defined and try to link this version into an executable named "test_bad". This will fail with the link error listed in this bug report. You'll note that "test.cpp" does not currently attempt to use any of the wide string support. This test case demonstrates that the steps necessary to enable wide strings (wstring) causes the regular 'string' type to not be usable.
Wow! That was the fastest response I have ever gotten from any vendor. Truly amazing. You had this bug report closed before I even had a chance to add the test case! Thank you Jacob!
Sorry, mistyped - thank you Jakub!