Simon Hausmann writes:
> Package: libstdc++5
> Version: 1:3.3-0pre5
> Severity: normal
>
> The symbol in the subject is missing from libstdc++5. It appears to be
> new in gcc-3.3's libstdc++. A simple testcase like this compiled with
> -O2 reproduces the problem:
>
> #include <string>
>
> int main()
> {
> std::string bleh;
> return 0;
> }
>
> g++-3.3 -O2 -o test test.cc ; ./test
> ./test: relocation error: ./test: symbol
> _ZN9__gnu_cxx17_Atomic_add_mutexE, version GLIBCPP_3.2.3 not defined in
> file libstdc++.so.5 with link time reference
You can workaround this when compiling with -march=i486 or above (or
remove the libstdc++'s in /usr/lib/<arch>/*.
This is due to the merged atomicity.h (generic for i386, i486 for
above i386). The generic one defines _GLIBCPP_NEED_GENERIC_MUTEX,
which is referenced in misc-inst.cc. A solution would be to define
this in the "i486" part of the merged atomicity.h as well, so the
following code is included in the i486 version of libstdc++ as well.
Does the extra initialization do any harm?
#ifdef _GLIBCPP_NEED_GENERIC_MUTEX
namespace __gnu_cxx
{
#ifdef __GTHREAD_MUTEX_INIT
__gthread_mutex_t _Atomic_add_mutex = __GTHREAD_MUTEX_INIT;
#else
// generic atomicity.h without static initialization
__gthread_mutex_t _Atomic_add_mutex;
__gthread_once_t _Atomic_add_mutex_once = __GTHREAD_ONCE_INIT;
void __gthread_atomic_add_mutex_once()
{
__GTHREAD_MUTEX_INIT_FUNCTION (&_Atomic_add_mutex);
}
#endif
} // namespace __gnu_cxx
#endif // _GLIBCPP_NEED_GLOBAL_MUTEX
