[Bug libstdc++/51673] New: undefined references / libstdc++-7.dll

[Bug libstdc++/51673] New: undefined references / libstdc++-7.dll

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

             Bug #: 51673
           Summary: undefined references / libstdc++-7.dll
    Classification: Unclassified
           Product: gcc
           Version: 4.6.3
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: pluto@agmk.net


Created attachment 26182
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26182
testcase with libstdc++-6/7.dll

with gcc crosscompiler configured for target x86_64-pc-mingw32 with
--enable-symvers=gnu-versioned-namespace --enable-libstdcxx-allocator=mt
i'm getting linker errors on trivial testcase.


/home/users/pluto/tmp/ccsZppkB.o:t.cpp:(.text$_ZN9__gnu_cxx3__710__mt_allocIiNS0_20__common_pool_policyINS0_6__poolELb1EEEE8allocateEyPKv[__gnu_cxx::__7::__mt_alloc<int,
__gnu_cxx::__7::__common_pool_policy<__gnu_cxx::__7::__pool, true>
>::allocate(unsigned long long, void const*)]+0x63): undefined reference to
`operator new(unsigned long long)'
/home/users/pluto/tmp/ccsZppkB.o:t.cpp:(.text$_ZN9__gnu_cxx3__710__mt_allocIiNS0_20__common_pool_policyINS0_6__poolELb1EEEE8allocateEyPKv[__gnu_cxx::__7::__mt_alloc<int,
__gnu_cxx::__7::__common_pool_policy<__gnu_cxx::__7::__pool, true>
>::allocate(unsigned long long, void const*)]+0x142): undefined reference to
`__gnu_cxx::__7::__pool<true>::_M_reserve_block(unsigned long long, unsigned
long long)'
/home/users/pluto/tmp/ccsZppkB.o:t.cpp:(.text$_ZN9__gnu_cxx3__710__mt_allocIiNS0_20__common_pool_policyINS0_6__poolELb1EEEE10deallocateEPiy[__gnu_cxx::__7::__mt_alloc<int,
__gnu_cxx::__7::__common_pool_policy<__gnu_cxx::__7::__pool, true>
>::deallocate(int*, unsigned long long)]+0x6d): undefined reference to
`__gnu_cxx::__7::__pool<true>::_M_reclaim_block(char*, unsigned long long)'


afaics the libstdc++7.dll doesn't export e.g. _Znwy* symbols
while libstdc++-6.dll looks fine in this area:

$ 86_64-pc-mingw32-objdump -p libstdc++-6.dll|grep _Znw

        [3472] _Znwy
        [3473] _ZnwyRKSt9nothrow_t

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bkoz at gcc dot gnu.org,
                   |                            |paolo.carlini at oracle dot
                   |                            |com

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-12-24 13:01:47 UTC ---
Versioned is for Benjamin to look at, I guess.

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> 2011-12-24 14:11:00 UTC ---
Do we want to define mt_allocator in v7?
Is it worth keeping all the ext allocators in the library forever?

If not, we could conditionally define them only when configured for v6, which
would "solve" this problem.

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #3 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-12-24 14:37:23 UTC ---
I don't have a strong opinion, but it's a bit hard to make a choice: the legacy
HP/SGI pool still makes sense; mt too, has some problems, but we spent quite a
bit of time on it, works decently well in a few circumstances (still, I have to
tell Pawel, enabling it as default allocator isn't something one should do with
light heart); bitmap I would not include, actually I would deprecate and remove
it completely, you know that already.

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #4 from Pawel Sikora <pluto at agmk dot net> 2011-12-27 09:32:11 UTC ---
i'm using the mt allocator for large std containers with small fixed-size
objects. the mt's flexible pool configuration and alloc/free speed are
an advantage over the simple new (malloc/free) allocator and i'd like
to avoid reinventing the wheel with yet another pool allocator.

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[paolo.carlini at oracle dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011-12-27
     Ever Confirmed|0                           |1

--- Comment #5 from Paolo Carlini <paolo.carlini at oracle dot com> 2011-12-27 10:26:42 UTC ---
To be clear, no matter what, undefined references is a bug, in any mode of the
library even the most esoteric ;) The fix may be simple too.

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #6 from Pawel Sikora <pluto at agmk dot net> 2011-12-28 16:06:47 UTC ---
btw, i've tested the default allocator with std::__7 and the i686-pc-mingw32
toolchain works fine while the x86_64-pc-mingw32 reports undefined reference to

.text$_ZN9__gnu_cxx3__713new_allocatorIiE8allocateEyPKv[__gnu_cxx::__7::new_allocator<int>::allocate(unsigned
long long, void const*)]

so, there's a bug with symbol exporting not directly related to mt_allocator.
_Znwj vs. _Znwy issue?

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #7 from Pawel Sikora <pluto at agmk dot net> 2011-12-28 19:51:55 UTC ---
please apply following obvious patch:

--- gcc-4.6.0/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver.orig     
2011-12-28 12:43:50.000000000 +0100
+++ gcc-4.6.0/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver  
2011-12-28 20:25:36.603040153 +0100
@@ -42,9 +42,9 @@
     __once_proxy;

     # operator new(size_t)
-    _Znw[jm];
+    _Znw[jmy];
     # operator new(size_t, std::nothrow_t const&)
-    _Znw[jm]RKSt9nothrow_t;
+    _Znw[jmy]RKSt9nothrow_t;

     # operator delete(void*)
     _ZdlPv;
@@ -52,9 +52,9 @@
     _ZdlPvRKSt9nothrow_t;

     # operator new[](size_t)
-    _Zna[jm];
+    _Zna[jmy];
     # operator new[](size_t, std::nothrow_t const&)
-    _Zna[jm]RKSt9nothrow_t;
+    _Zna[jmy]RKSt9nothrow_t;

     # operator delete[](void*)
     _ZdaPv;


it fixes new/delete exports for x86_64-pc-mingw32.
mt-allocator needs more exports...

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #8 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-12-28 21:24:25 UTC ---
(In reply to comment #7)
> please apply following obvious patch:
> 
> --- gcc-4.6.0/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver.orig     
> 2011-12-28 12:43:50.000000000 +0100
> +++ gcc-4.6.0/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver  
> 2011-12-28 20:25:36.603040153 +0100
> @@ -42,9 +42,9 @@
>      __once_proxy;
> 
>      # operator new(size_t)
> -    _Znw[jm];
> +    _Znw[jmy];
>      # operator new(size_t, std::nothrow_t const&)
> -    _Znw[jm]RKSt9nothrow_t;
> +    _Znw[jmy]RKSt9nothrow_t;
> 
>      # operator delete(void*)
>      _ZdlPv;
> @@ -52,9 +52,9 @@
>      _ZdlPvRKSt9nothrow_t;
> 
>      # operator new[](size_t)
> -    _Zna[jm];
> +    _Zna[jmy];
>      # operator new[](size_t, std::nothrow_t const&)
> -    _Zna[jm]RKSt9nothrow_t;
> +    _Zna[jmy]RKSt9nothrow_t;
> 
>      # operator delete[](void*)
>      _ZdaPv;
> 
> 
> it fixes new/delete exports for x86_64-pc-mingw32.
> mt-allocator needs more exports...

Thanks. Yes, confirmed patch fixes reported new/delete issue.  From my side
this patch is ok.  If C++ maintainer ok-s it too, I will apply it.

Kai

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[bkoz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #9 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2012-01-09 23:39:30 UTC ---
Author: bkoz
Date: Mon Jan  9 23:39:22 2012
New Revision: 183043

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183043
Log:
2012-01-09  Kai Tietz  <ktietz@redhat.com>

    PR libstc++/51673 part 2
    * config/abi/pre/gnu-versioned-namespace.ver: Adjusted new/delete
    operators signature for LLP64 size_t, and adjusted signatures for
    mt-allocator using size_t.

2012-01-09  Benjamin Kosnik  <bkoz@redhat.com>

    PR libstc++/51673 part 1
    * config/abi/pre/gnu-versioned-namespace.ver: Sync cxxabi symbols
    with gnu.ver.

Modified:
    trunk/libstdc++-v3/ChangeLog
    trunk/libstdc++-v3/config/abi/pre/gnu-versioned-namespace.ver

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[bkoz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #10 from Benjamin Kosnik <bkoz at gcc dot gnu.org> 2012-01-09 23:42:01 UTC ---

Thanks guys. This looks good, and is in trunk. 

Pawel, thanks for noticing this. Please note that namespace versioning was
updated for 4.7.x to bring this experimental feature up to the final C++11
spec.

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #11 from Pawel Sikora <pluto at agmk dot net> 2012-01-10 19:56:08 UTC ---
(In reply to comment #10)
> Thanks guys. This looks good, and is in trunk. 
> 
> Pawel, thanks for noticing this. Please note that namespace versioning was
> updated for 4.7.x to bring this experimental feature up to the final C++11
> spec.

can we get this fix for upcoming 4.6.4? it doesn't touch default libstdc++
configuration and fixes bug in non-primary target. looks safe.

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #12 from Pawel Sikora <pluto at agmk dot net> 2012-03-04 19:36:30 UTC ---
with current 4.6.4 i've noticed a new undefined reference
during boost_rexeg.dll linking:

(...)
Creating library file:
bin.v2/libs/regex/build/gcc-mingw-4.6.4/release/inlining-on/target-os-windows/threadapi-win32/threading-multi/libboost_regex.dll.abin.v2/libs/regex/build/gcc-mingw-4.6.4/release/inlining-on/target-os-windows/threadapi-win32/threading-multi/cpp_regex_traits.o:
 In function
`boost::re_detail::cpp_regex_traits_base<char>::imbue(std::__7::locale
const&)':
/home/users/pluto/buildenv/linux/x86_64-w64-mingw32/boost_1_49_0/./boost/regex/v4/cpp_regex_traits.hpp:216:
 undefined reference to `bool std::__7::has_facet<std::__7::messages<char>
>(std::__7::locale const&)'


$ x86_64-w64-mingw32-objdump -t cpp_regex_traits.o|egrep
'_ZN.+has_facet.+messages'
[325](sec  0)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x0000000000000000
_ZNSt3__79has_facetINS_8messagesIcEEEEbRKNS_6localeE

i see a has_facet in symbols table:

$ x86_64-w64-mingw32-objdump -t libstdc++-7.dll|egrep
'_ZN.+has_facet.+messages'

[13096](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x0000000000093880
_ZNSt3__79has_facetINS_8messagesIcEEEEbRKNS_6localeE
[21476](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 0) 0x00000000000938e0
_ZNSt3__79has_facetINS_8messagesIwEEEEbRKNS_6localeE

but they aren't present in export-address-table. any ideas?

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[ktietz at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #13 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-03-06 11:48:22 UTC ---
Hmm, this looks to me like an boost-issue and seems to me not being related to
gcc itself.  The cause might be that symbol-mangling has changed and boost
doesn't specifies it on its export-table?

I will close this bug as invalid.

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

Pawel Sikora <pluto at agmk dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |NEW
         Resolution|INVALID                     |

--- Comment #14 from Pawel Sikora <pluto at agmk dot net> 2012-03-06 18:36:06 UTC ---
(In reply to comment #13)
> Hmm, this looks to me like an boost-issue and seems to me not being related to
> gcc itself.  The cause might be that symbol-mangling has changed and boost
> doesn't specifies it on its export-table?
> 
> I will close this bug as invalid.

1).
please don't close this issue as invalid - orignal topic is fixed on 4.7.
will it be backported to 4.6? (i have an adjusted patch).

2).
i've found the core issue for problem mentioned in comment 12.
the --disable-nls configure option causes missing x64 .dll exports
but this is imho a bug (libstdc++ headers allow boost to use locale
support but linking fails later). i've --enabled-nls and it works fine.

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[redi at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-03-06 18:43:19 UTC ---
(In reply to comment #14)
> i've found the core issue for problem mentioned in comment 12.
> the --disable-nls configure option causes missing x64 .dll exports
> but this is imho a bug (libstdc++ headers allow boost to use locale
> support but linking fails later). i've --enabled-nls and it works fine.

This is why we ask for configure options in bug reports - you hadn't mentioned
anything about --disable-nls

I agree it's a bug if --disable-nls has any effect on libstdc++ exports.

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[joseph at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #16 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-03-06 20:19:24 UTC ---
I think --disable-nls should be purely a *host* configure option - it's a 
bug if it affects anything at all about libstdc++.

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

--- Comment #17 from Pawel Sikora <pluto at agmk dot net> 2012-03-06 21:04:40 UTC ---
(In reply to comment #15)
> (In reply to comment #14)
> > i've found the core issue for problem mentioned in comment 12.
> > the --disable-nls configure option causes missing x64 .dll exports
> > but this is imho a bug (libstdc++ headers allow boost to use locale
> > support but linking fails later). i've --enabled-nls and it works fine.
> 
> This is why we ask for configure options in bug reports - you hadn't mentioned
> anything about --disable-nls
> 
> I agree it's a bug if --disable-nls has any effect on libstdc++ exports.

i've filled this issue as PR52514.

[Bug libstdc++/51673] undefined references / libstdc++-7.dll

[pluto at agmk dot net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51673

Pawel Sikora <pluto at agmk dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #18 from Pawel Sikora <pluto at agmk dot net> 2012-03-22 22:17:46 UTC ---
ok, the original isse (gnu-versioned-namespace.ver) is fixed for 4.7.0.
the secondary issue (--disable-nls vs. export table [PR52514]) is invalid,
so i'm closing this PR as fixed for 4.7.0.