This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Problem with `string', threading and shared libraries.
- To: gcc-bugs at gcc dot gnu dot org
- Subject: Problem with `string', threading and shared libraries.
- From: Carlo Wood <carlo at alinoe dot com>
- Date: Fri, 28 Sep 2001 16:49:14 +0200
- Cc: gcc at gcc dot gnu dot org, stl at sgi dot com
When someone compiles a shared library that exports functions
with `string' in their signature - a problem occurs when
people who want to use that library use a different threading
model - even if both the library and the user application are
single threaded!
The problem is that when _NOTHREADS is defined
(See http://www.sgi.com/tech/stl/thread_safety.html)
then a `string' is defined as
basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> >
while people who use a compile with for instance POSIX threads
will have a `string' defined as
basic_string<char, string_char_traits<char>, __default_alloc_template<true, 0> >
The result is that calls to, say
some_library_function(string ¶m);
will fail with an undefined symbol.
I was wondering, how can it be that `string' has a different
mangling on different compilers/machines? Isn't that a bug?
If not, then can you tell me what is the appropriate way to
solve this problem (from the point of view of the developer
of the shared library)?
Thanks,
--
Carlo Wood <carlo@alinoe.com>