Windows: "execinfo.h: No such file or directory" about stacktrace HOT 24 CLOSED

Fixed that in 6a146fe :)

Please, try it out and report the progress.

from stacktrace.

Well, now I get

../../source/stacktrace/include/boost/stacktrace/detail/safe_dump_win.ipp:19:55: fatal error: boost/detail/winapi/get_current_process.hpp: No such file or directory

It's because in boost version 1.60 (which is used in MXE) this header was called GetCurrentProcess.hpp. Starting from version 1.61 it redirects to get_current_process.hpp. So it can be fixed easily.
But then you get similar problem with access_rights.hpp which was not in 1.60 ...

from stacktrace.

Try copying it into your Boost installation from here

from stacktrace.

I was trying to build it with latest Boost version (in order to avoid previously described problems) and I got

../../source/stacktrace/include/boost/stacktrace/detail/frame_unwind.ipp:23:36: fatal error: dlfcn.h: No such file or directory

In fact it was the first error that I got during Windows cross-build but I temporally workarounded it with this Windows port. Unfortunately this port does not contain dladdr function. So even if I use it it gives me errors

../../source/stacktrace/include/boost/stacktrace/detail/frame_unwind.ipp: In member function 'std::__cxx11::string boost::stacktrace::detail::to_string_impl_base::operator()(const void*)':
../../source/stacktrace/include/boost/stacktrace/detail/frame_unwind.ipp:99:9: error: '::Dl_info' has not been declared
::Dl_info dli;
^
../../source/stacktrace/include/boost/stacktrace/detail/frame_unwind.ipp:100:15: error: '::dladdr' has not been declared
if (!!::dladdr(addr, &dli) && dli.dli_sname) {

So this port is useless and dlfcn looks as Linux specific.

from stacktrace.

As a temporary solution - comment out those lines. I'll fix the code in a more appropriate way soon.

from stacktrace.

Fixed in develop branch. Not all tests are passing, but the library is usable.

I'll fix the remaining tests in two weeks.

from stacktrace.

Well, now I can build it at least. But information that it provides is not very informative and looks like this

0# 0x000000000040F7B3
1# 0x00007FDFD72EFF45
2# 0x000000000040F4B9

from stacktrace.

Try defining the BOOST_STACKTRACE_USE_BACKTRACE macro or linking with boost_stacktrace_backtrace (some more info could be found here)

from stacktrace.

It builds and works on Linux but not on Windows where I (expectedly?) get

../stacktrace/include/boost/stacktrace/detail/libbacktrace_impls.hpp:19:23: fatal error: backtrace.h: No such file or directory

from stacktrace.

One more question. Do I understand correctly that stacktrace gives function names only when used in debug version of a program and in release - only addresses?

from stacktrace.

It builds and works on Linux but not on Windows where I (expectedly?) get fatal error: backtrace.h: No such file or directory

That's not good. Looks like an issue in MinGW (I'll create a feature request soon). Until then you can download and manually install the libbacktrace library from here - this will produce filenames and line numbers in stacktraces.

from stacktrace.

One more question. Do I understand correctly that stacktrace gives function names only when used in debug version of a program and in release - only addresses?

On MinGW without defining BOOST_STACKTRACE_USE_BACKTRACE - yes. Consider compiling with -rdynamic flag, without -fisibility=hidden in release mode to produce a better stacktraces with function names. Warning: this may affect you program startup times and size.

P.S.: Looks like I need to significantly improve documentation. Sorry for not doing that long time ago.

from stacktrace.

Consider compiling with -rdynamic flag, without -fisibility=hidden

I've tested, this would not help you :(

Are you using MinGW or mingw-w64?
Does your MinGW has the "Dbgeng.h" header?

from stacktrace.

Are you using MinGW or mingw-w64?
Does your MinGW has the "Dbgeng.h" header?

I am using MinGW. More exactly - I am using MXE which in turn uses MinGW.
Yes it has the "Dbgeng.h" header.

from stacktrace.

I've updated the develop branch. Could you please test it and report problems?

from stacktrace.

In my distribution of MinGW there is "dbgeng.h" not "Dbgeng.h". So it fails to compile because it can not find the file. If I change the file name correspondingly then I get

release/main.o:main.cpp:(.text+0xa7): undefined reference to _GUID const& __mingw_uuidof<IDebugClient>()' release/main.o:main.cpp:(.text+0xd1): undefined reference to _GUID const& __mingw_uuidof()'
release/main.o:main.cpp:(.text+0x16f): undefined reference to __imp_CoUninitialize' release/main.o:main.cpp:(.text+0x202): undefined reference to _GUID const& __mingw_uuidof()'
release/main.o:main.cpp:(.text+0x79b): undefined reference to `__imp_CoUninitialize'

from stacktrace.

Link with the following two libraries: "ole32.lib" and "Dbgeng.lib".

Great thanks for continuing helping with this issue! I's very important for me.

from stacktrace.

It was linked to dbgeng before. After I add link to ole32 __imp_CoUninitialize error disappears but __mingw_uuidof remains:

release/main.o:main.cpp:(.text+0xa7): undefined reference to _GUID const& _mingw_uuidof()

from stacktrace.

Try linking with "uuid.lib" too.

Meanwhile I'll try to remove MSVC specific extensions

from stacktrace.

Linking to uuid changes nothing.

from stacktrace.

Try adding the following lines: https://github.com/apolukhin/stacktrace/blob/3f48887f2e24f86e75a07d8c6ac5450aa808867a/include/boost/stacktrace/detail/frame_msvc.ipp#L36-L40

Has the linker issue gone? If not, then additionally uncomment the line https://github.com/apolukhin/stacktrace/blob/3f48887f2e24f86e75a07d8c6ac5450aa808867a/include/boost/stacktrace/detail/frame_msvc.ipp#L43

Please, report the results back

from stacktrace.

For first I get:

release/main.o:main.cpp:(.text$_ZN5boost10stacktrace6detail9to_stringB5cxx11EPKNS0_5frameEy[_ZN5boost10stacktrace6detail9to_stringB5cxx11EPKNS0_5frameEy]+0x5e): undefined reference to _GUID const& __mingw_uuidof<IDebugClient>()' release/main.o:main.cpp:(.text$_ZN5boost10stacktrace6detail9to_stringB5cxx11EPKNS0_5frameEy[_ZN5boost10stacktrace6detail9to_stringB5cxx11EPKNS0_5frameEy]+0x8d): undefined reference to _GUID const& __mingw_uuidof()'
release/main.o:main.cpp:(.text$_ZN5boost10stacktrace6detail9to_stringB5cxx11EPKNS0_5frameEy[_ZN5boost10stacktrace6detail9to_stringB5cxx11EPKNS0_5frameEy]+0x181): undefined reference to `_GUID const& __mingw_uuidof()'

For second:

release/main.o:main.cpp:(.rdata$.refptr.IID_IDebugSymbols[.refptr.IID_IDebugSymbols]+0x0): undefined reference to IID_IDebugSymbols' release/main.o:main.cpp:(.rdata$.refptr.IID_IDebugControl[.refptr.IID_IDebugControl]+0x0): undefined reference to IID_IDebugControl'
release/main.o:main.cpp:(.rdata$.refptr.IID_IDebugClient[.refptr.IID_IDebugClient]+0x0): undefined reference to `IID_IDebugClient'

from stacktrace.

I has the same issues and solve them for boost 1.60 in MinGW. see. It is only question for me why symbols are not demangled. Solution on the patch looks like strange trick.

from stacktrace.

Looks like the MinGW that is installed in Appveyor CI does not have "dngeng.h" at all, so I can not easily check the results.

Could someone please check out the latest master? Have the issues gone?

from stacktrace.