Now this is even funnier. I installed libsource-highlight-dev and wrote a
short program whose only relevant expression is:
srchilite::SourceHighlight *X = new srchilite::SourceHighlight();
Then:
1015-north:tmp$ g++ foo.C
/usr/bin/ld: /tmp/ccn6kzOe.o: in function `main':
foo.C:(.text+0x46): undefined reference to
`srchilite::SourceHighlight::SourceHighlight(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)'
collect2: error: ld returned 1 exit status
1016-north:tmp$ g++ foo.C -l source-highlight
1017-north:tmp$ gdb -q --args ./a.out
Reading symbols from ./a.out...
(No debugging symbols found in ./a.out)
(gdb) break main
Breakpoint 1 at 0x11a9
(gdb) run
Starting program: /home/ale/tmp/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, 0x00005555555551a9 in main ()
(gdb) q
A debugging session is active.
Inferior 1 [process 21681] will be killed.
Quit anyway? (y or n) y
So, gdb can run without symbols.
1018-north:tmp$ g++ -g foo.C -l source-highlight
1019-north:tmp$ gdb -q --args ./a.out
Reading symbols from ./a.out...
(gdb) break main
Breakpoint 1 at 0x11b0: file foo.C, line 6.
(gdb) run
Starting program: /home/ale/tmp/a.out
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main () at foo.C:6
gdb: symbol lookup error: gdb: undefined symbol:
_ZN9srchilite15SourceHighlightC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
Although the symbol is probably the same...
1020-north:tmp$ ldd a.out
linux-vdso.so.1 (0x00007ffcbf1eb000)
libsource-highlight.so.4 => /usr/local/lib/libsource-highlight.so.4
(0x00007f9d18b3e000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f9d18971000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
(0x00007f9d18957000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9d18792000)
libboost_regex.so.1.49.0 => /usr/lib/libboost_regex.so.1.49.0
(0x00007f9d18669000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f9d18525000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9d18e57000)
libicuuc.so.48 => /usr/lib/x86_64-linux-gnu/libicuuc.so.48
(0x00007f9d1816b000)
libicui18n.so.48 => /usr/lib/x86_64-linux-gnu/libicui18n.so.48
(0x00007f9d17d3f000)
libicudata.so.48 => /usr/lib/x86_64-linux-gnu/libicudata.so.48
(0x00007f9d169cf000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f9d169c4000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f9d169a2000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f9d1699c000)
That's the culprit, /usr/local/lib/libsource-highlight.so.4 installed in 2016.
Removed it, now gdb works.
Sorry for the noise
Ale
On Fri 12/Nov/2021 17:41:30 +0100 Alessandro Vesely wrote:
Hi all,
don't know since when this happened, maybe since I upgraded to Chimaera.
When I run gdb I get:
src$ gdb -n -q --args ./anyexec
Reading symbols from ./anyexec...
(gdb) break main
Breakpoint 1 at 0x7c7a: file anyexec.c, line 10.
(gdb) run
Starting program: /home/ale/tmp/src/anyexec
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
Breakpoint 1, main (argc=3, argv=0x7fffffffe1c8) at anyexec.c:10
gdb: symbol lookup error: gdb: undefined symbol:
_ZN9srchilite15SourceHighlightC1ERKNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEE
src$ echo $?
127
Demangled symbol seems to be:
srchilite::SourceHighlight::SourceHighlight(std::__cxx11::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&)
I cannot strace gdb, so I don't know where it looks for that missing symbol.
I tried to remove and reinstall gdb, reinstall all libsource-highlight*, to no
avail.
Any idea?
TIA
Ale
_______________________________________________
Dng mailing list
[email protected]
https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
