The changes in r297174 moved the #include of <link.h> on FreeBSD (and
probably other systems) inside of the open 'libunwind' namespace
causing various system-provided types such as pid_t to be declared in
this namespace rather than the global namespace. Fix this by moving
the relevant declarations before the 'libunwind' namespace is opened,
but still using the cleaned up declarations from r297174.
Details
Diff Detail
- Build Status
Buildable 10475 Build 10475: arc lint + arc unit
Event Timeline
I posted a sample compile failure on FreeBSD/amd64 in the review for the earlier change: D30696
src/AddressSpace.hpp | ||
---|---|---|
38 | Why does this need a #ifndef __APPLE__ guard? |
src/AddressSpace.hpp | ||
---|---|---|
38 | This is to mimic the same conditionals in the existing code. The current flow is '#ifdef APPLE <do stuff> #else <the code being moved> #endif' I chose to use '#ifndef APPLE' rather than having an empty '#if APPLE' body but can use whichever is preferred. I could also push the !defined(APPLE) down into the other conditionals. |
Hey! Sorry for the breakage. I thought I did a good job of testing this change on various operating systems, but somehow this still fell through the cracks. Odd.
src/AddressSpace.hpp | ||
---|---|---|
268 | Considering that this block only declares an inline function, maybe it would make sense to move this to the top of the source file as well? That way we can keep the existing order of #ifs. |
src/AddressSpace.hpp | ||
---|---|---|
38 | _LIBUNWIND_ARM_EHABI should never be defined under a Darwin build AFAIK. I would just entirely drop the __APPLE__ check. |
Moving the __APPLE__ case up to the top of the file would be nice, although, it does move a compatibility implementation too. I suppose that it isn't too terrible though.
src/AddressSpace.hpp | ||
---|---|---|
38 | Yeah, it does. Although, I think we could just do: #elif defined(_LIBUNWIND_ARM_EHABI) || (!defined(__APPLE__) && defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND)) |
Why does this need a #ifndef __APPLE__ guard?