pkubaj at anongoth.pl
Tue Oct 17 21:48:31 UTC 2017
I think I got it. It turns out that it's our gdb in base that can't read the debug info. lldb and gdb from ports do it just fine.
I also thought about recompiling library dependecies, but something didn't fit in, because not only the libraries calls were not there, but the calls from the port itself as well.
On 17-10-17 23:29:47, Jan Beich wrote:
>Guido Falsi <mad at madpilot.net> writes:
>> On 10/17/2017 23:11, Guido Falsi wrote:
>>>> Thing is, recompiling with WITH_DEBUG doesn't help (I only get
>>>> memory addresses in gdb), nor does -DCMAKE_BUILD_TYPE=Debug to
>>>> CMAKE_ARGS (the port uses CMake).
>> Sorry, I clearly did not parse your message correctly.
>> Looks strange though, WITH_DEBUG always worked for me... Usually I
>> compile the whole set in poudriere with WITH_DEBUG, to make sure all
>> libraries have symbols too.
>WITH_DEBUG doesn't disable vendor optimizations like -fomit-frame-pointer
>which may hinder stack unwinding, doesn't enable debug symbols for ports
>not respecting CFLAGS, often a nop for non-C/C++ ports, etc.
>Without an example it's hard to guess.
>This message has been scanned for viruses and
>dangerous content by MailScanner, and is
>believed to be clean.
/ If a camel is a horse designed by a \
| committee, then a consensus forecast is |
| a camel's behind. |
\ -- Edgar R. Fiedler /
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the freebsd-ports