Your message dated Fri, 7 Jul 2006 18:36:43 -0400 (EDT) with message-id <[EMAIL PROTECTED]> and subject line Close has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what I am talking about this indicates a serious mail system misconfiguration somewhere. Please contact me immediately.) Debian bug tracking system administrator (administrator, Debian Bugs database)
--- Begin Message ---Package: libstdc++5 Version: 1:3.2.1-0pre6 Severity: normal Tags: upstream Underlying types are used when creating the mangled name of symbols in C++. In libstdc++, many symbols contains the type mbstate_t. As encoded in the mangled name, the underlying type, __mbstate_t is used. When unmangled, this results in a different source name than what was used in the source. Here is an example: libstdc++ contains the symbol _ZNKSt7codecvtIcc11__mbstate_tE11do_encodingEv. c++filt de-mangles this as std::codecvt<char, char, __mbstate_t>::do_encoding() const, which is not the same thing as in the ISO C++ specification, which would be std::codecvt<char, char, mbstate_t>::do_encoding() const (ref ISO C++ 22.2.1.5). The difference is __mbstate_t vs mbstate_t. It seem that an unmangling operation should produce the original source symbol. This seems like it may be an ABI issue as the C++ headers produce different mangled symbol if headers other than GNU libc headers are used. We ran into this when testing the LSB development environment in conjunction with C++. The LSB description of mbstate_t is a typedef of an anonymous structure, and doesn't have the intermediate __mbstate_t as the glibc headers do. Since __mbstate_t doesn't seem to be present in the source standards, we didn't want to include it in the LSB descriptions. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux bego 2.4.18 #25 Tue Aug 6 14:04:58 EDT 2002 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages libstdc++5 depends on: ii gcc-3.2-base 1:3.2.1-0pre6 The GNU Compiler Collection (base ii libc6 2.3.1-3 GNU C Library: Shared libraries an ii libgcc1 1:3.2.1-0pre6 GCC support library. -- no debconf information
--- End Message ---
--- Begin Message ---This should have been closed long ago. The mangling is correct, even though it is inconvenient for ABI checking tools such as the ones provided by the LSB project. Stuart Stuart R. Anderson [EMAIL PROTECTED] Network & Software Engineering http://www.netsweng.com/ 1024D/37A79149: 0791 D3B8 9A4C 2CDC A31F BD03 0A62 E534 37A7 9149
--- End Message ---
