On 2023-02-16 20:08, Jonathan Wakely wrote:
On Thu, 16 Feb 2023, 18:39 , <i.nixman@xxxxxxxxxxxxx> wrote:
On 2023-02-16 15:29, Jonathan Wakely wrote:
> On Thu, 16 Feb 2023 at 15:25, i.nixman--- via Gcc-help
> <gcc-help@xxxxxxxxxxx> wrote:
>>
>> hello,
>>
>>
>> I can successfully build the same C++ code using GCC-8.3.1 for Debug
>> (-g
>> -O0) and Release (-g -O2) build.
>> I can successfully debug the Release-executable on a remote host, but
>> I
>> can't debug the Debug-executable on a remote host, because the
>> Debug-executable imports an extra symbol
>> _ZNKSt9basic_iosIcSt11char_traitsIcEEcvbEv from libstdc++ which
>> doesn't
>> exist.
>
> It should exist, it has been there since GCC
hmm...
I just checked the two binaries using this cmd:
> readelf -sW executable | grep
> _ZNKSt9basic_iosIcSt11char_traitsIcEEcvbEv
it shows nothing for release build, and shows this for debug build:
> 54: 0000000000000000 0 FUNC GLOBAL DEFAULT UND
> _ZNKSt9basic_iosIcSt11char_traitsIcEEcvbEv
> 199898: 0000000000000000 0 FUNC GLOBAL DEFAULT UND
> _ZNKSt9basic_iosIcSt11char_traitsIcEEcvbEv
This only shows that the function is inlined in the optimized build,
and
not in the debug build, so the debug one has an unresolved reference to
a
symbol defined in the libstdc++ dynamic library. This is completely
normal.
then I have two questions:
1. will the problem be solved by "pushing" a debug version of libstdc++
on the remote machine?
2. how can I define this symbol in the project code for debug build to
avoid having to use the debug version of libstdc++?
something like this? :
namespace std {
template basic_ios<char, char_traits<char> >::operator bool() const;
}
best!
