Using ofxNetwork on an iOS project hijacks OF's main()

[armadillu]

Making a new ios project with PG, if ofxNetwork is added, your project will not launch when run. Instead, the app spits out this huge table and quits.

//
// This is an automatically generated file.
// Do not edit.
//

const unsigned short expTable[] =
{
    0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 
    0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 
    0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 
    0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 
    0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 0x3c00, 
    ...

Googling lead me to this... Apparently there's an int main()function within the freeimage library??? WTF??

Anyway, somehow, including ofxNetwork makes the project launch that main() within FreeImage instead of the main() defined in your project's main.mm file. I've painstakingly isolated the issue within ofxNetwork; it turns out the ofxUDPManager.cpp file is to blame. If you remove ofxUDPManager.cpp from the project and run it, the expected main() is launched, and the app works as normal. If you add it back, the freeImage main() runs instead.

At this point I was too curious to stop, so I've been slowly commenting out code within ofxUDPManager.cpp and re-running the project to see what part of the code could possible be responsible for this bizzare feat...

I've isolated it to the method ofxUDPManager::BindMCast(char *pMcast, unsigned short usPort), and even more precisely, this line:

ofLogWarning("ofxUDPManager") << "BindMcast(): couldn't bind to port " << usPort;

Leaving this line as it is, makes the project not launch. Commenting it out, makes the project work as normal.

This is one of the weirdest things I've ever seen, I would love to hear a rational explanation of what's triggering this! I wonder if it's a linker bug of some sort?

I can be reproduce this using the latest Master and also a much older revision (~mid-2017). I'm using macOS 10.13.3 to test, and the latest XCode (9.3).

[arturoc]

wtf. perhaps we can try to remove that file before compiling freeimage for ios

[arturoc]

btw, I think freeimage uses some flag to hide internal symbols from binaries linking to it but no idea why that one specific line would unhide it.

[armadillu]

Also worth nothing, the same thing happens in both the Simulator and a real iOS device, so It affects both architectures the same way...

[arturoc]

This should be solved now but would be good if you can check.

[armadillu]

Yep I just tested on RC2 and the freeImage main() doesn't seem to show up no matter what I try.
It certainly doesn't show up under the circumstances that triggered it before either.
I think it's fixed!