jeremy-rifkin / cpptrace

Simple, portable, and self-contained stacktrace library for C++11 and newer
MIT License
642 stars 67 forks source link

libdwarf errors with vpckg in version 0.4.0 #95

Closed eyalgolan1337 closed 6 months ago

eyalgolan1337 commented 7 months ago

When using vcpkg with the new version of cpptrace (0.4.0) and libdwarf (version 0.8.0) using the latest port version an error occurs: libdwarf::dwarf cannot be found.

This happens when compiling libdwarf as a static lib. The cause is line 409 in CMakeLists.txt: target_link_libraries(${target_name} PRIVATE libdwarf::dwarf)

In version 0.3.0 of cpptrace this line looked like this (and worked fine): target_link_libraries(${target_name} PRIVATE $<IF:$<TARGET_EXISTS:libdwarf::dwarf-static>,libdwarf::dwarf-static,libdwarf::dwarf-shared>). I suggest reverting to this or atleast adding a fallback to it.

Another error that occurs is that cpptrace fails to find libdwarf.h in utils/dwarf.hpp. The cause is a wrong include directory relative to the macro that's defined (CPPTRACE_USE_NESTED_LIBDWARF_HEADER_PATH). This can be fixed by adding this line target_compile_definitions(${target_name} PRIVATE CPPTRACE_USE_NESTED_LIBDWARF_HEADER_PATH) above line 409. After adding it the include works.

jeremy-rifkin commented 6 months ago

Hi @eyalgolan1337, can you check what version of libdwarf you have installed? Unfortunately a number of things changed in 0.9.1, including the name of the cmake target (it's always libdwarf::dwarf now, not libdwarf::dwarf-static/shared), as well as the placement of the libdwarf headers.

jeremy-rifkin commented 6 months ago

Ah I missed in your message that you specified libdwarf 0.8 😄 It should work if you update libdwarf

eyalgolan1337 commented 6 months ago

This means cpptrace version 0.4.0 no longer supports libdwarf 0.8.0. Wouldn't it be better to keep the backward comparability?

jeremy-rifkin commented 6 months ago

I’m not sure what can be done given the libdwarf cmake changes but I agree it would be nice to update the port to not have this limitation.

The vcpkg philosophy seems to be that at a given instant every package should work with every other package, I’m not sure this sort of backwards compatibility thing is usually done for ports.