0

I am working on an iOS project and include ifaddrs.h in one of my files using

#include <ifaddrs.h>

Recently, my code stopped working (in particular, getifaddrs) and I noticed that BLWebSocketsServer delivers a getifaddrs.h/.c which seems to cause issues. If I remove those two files from XCodes "Headers" and "Compile Sources" phase, my code starts working again.

Now, for my questions:

  1. Why does this happen? getifaddrs.h is not <ifaddrs.h>, so this shouldn'at affect my code, should it?

  2. Is there a way to resolve this without altering BLWebSocketsServer?

Thanks!

BlackWolf
  • 5,239
  • 5
  • 33
  • 60

1 Answers1

1

Looking at getifaddrs.[hc] in BLWebSocketsServer, they are redefining getifaddrs, so the system implementation is being overridden (and the #include is basically irrelevant)

It looks like you can work around that by defining HAVE_GETIFADDRS=1 on your compiler command lines (or in options in the Xcode project settings)

Defining HAVE_GETIFADDRS is somewhat equivalent to removing the files from the compile phase, but has the added benefit that the other sources in BLWebSocketsServer won't be using possibly invalid declarations of getifaddrs related calls and structures.

David Berry
  • 40,941
  • 12
  • 84
  • 95
  • thanks. I wish there would be a way without having to define a preprocessor macro, but seems there is none :/ – BlackWolf Feb 17 '15 at 21:13
  • Well, as you use more and more open source and/or generic Unix sources in your projects, you'll find it's a very common model. So much so that there's a standard shell script 'configure' the whole purpose of which is to muck about in your system and compiler and figure out which alternative methods are required and which aren't. In this case, not all unix systems support `getifaddrs` so there's a choice to be made, support multiple varieties of iterating over interfaces (there's a LOT of them), or isolating it all behind an optional emulation of the original. – David Berry Feb 17 '15 at 23:03