https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88750
Iain Sandoe <iains at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |iains at gcc dot gnu.org
--- Comment #7 from Iain Sandoe <iains at gcc dot gnu.org> ---
(In reply to Jürgen Reuter from comment #6)
> In the linking before I do see the following warning:
> ld: warning: direct access in function 'operator new[](unsigned long,
> std::nothrow_t const&) [clone .cold]' from file
> '/usr/local/lib/libstdc++.a(new_opvnt.o)' to global weak symbol 'operator
> new[](unsigned long, std::nothrow_t const&)' from file
> '/usr/local/lib/libstdc++.a(new_opvnt.o)' means the weak symbol cannot be
> overridden at runtime. This was likely ca
This is almost certainly a "red herring".. (of course, "almost certainly" until
proven).
> Not totally sure what that means.
GCC can optimise code to split it into parts that are frequently executed (or
'hot') and parts that are not ('cold').
The externally-visible function typically calls the .cold part to do some setup
(or it might be an exceptional or abort path). In order to facilitate debug,
the cold part of the function has a label (__xxxxx.cold:) which is visible to
the linker.
In fact, one would never call that symbol from outside the TU in which it's
created (it's linker-visible, but not a global) ..
.. but the linker's complaint here is that if one overrides the externally
visible weak "new" symbol that wouldn't override the __new.cold one.
However, the only caller of __new.cold is __new, and therefore if you override
__new, nothing will be trying to call __new.cold. So IMO (probably we should
file a radar) the linker warning is bogus (or at least overly conservative).
The problem appears that libtool links the
> static stdc++ library into my test binary (via --static-libtool-libs), which
> causes the warning above, and the malloc runtime error. When I link in by
> hand the dynamic library via -lstdc++ then the warning goes away as well as
> the runtime error.
* It's hard to deduce what's going on/changed without some specific points as
Dominque says...
"then"[working] and "now" [first known not-working] could do with some
definition - plus if possible where the actual failure is (with a backtrace)
* It's generally not possible for folks here to reproduce problems by trying to
replicate your builds - this is a volunteer workforce, with highly constrained
time resources ;) .. we will need you to narrow things down
* It's quite possible that when you link statically - you are getting the
compiler's libstdc++ .. and when you link the shared version, it's being
resolved to the one installed in /usr/lib.
Please post as minimum the output of "otool -Lv <binary>" for both the working
(lstdc++) and non-working (--static-libtool-libs).
