Build fail

[lukewar]

I really like the project. Unfortunately I was unable to make it build. Process fails on libevent.sh.
Do you plan to actively maintain this project or should I look for other Tor solutions for iOS/OSX?

[conradev]

I am actively maintaining the project, yes. It builds fine for me – can you post your full build log?

[lukewar]

Hi, sorry for enigmatic message. I did manage to resolve build issues, I was missing automake & libtool.
Now I trying to make it work on OSX. Unfortunately I don't get authentication callback back.

[conradev]

Awesome. To my knowledge, libtool is included in OS X's Command Line Utilities, and the build scripts use that version. Unfortunately, autoconf and automake are required because we use git submodules for both tor and libevent. I neglected to add that to the README, thanks for pointing that out!

As for it not working on OS X, what does the syslog show? Does tor abort startup? If you're running an instance of tor already (via Tor Browser or otherwise), the SOCKS port will conflict and fail to bind. You might also need to add a small delay before attempting to authenticate because when you initialize the TORController it attempts to connect to the tor instance and might fail because tor hasn't bound to the control port yet.

[lukewar]

Yes, delay did the trick. I took a look at iOS tests and I have missed this delay there.

[conradev]

Sweet, glad to hear it. Right now, TORController is lacking in terms of features it should and could have. Let me know if you come across something you would like to add to it, and I can help!

Out of curiosity, are you able to talk about what you are working on? I'm not aware of people using this project besides myself, so I'm always eager to learn about new and emerging use cases. The idea behind this project is to make tor super easy to integrate into iOS and OS X applications so that people do it more often :)

[lukewar]

Sure. Unfortunately I can't share much but I can tell that I am working on instant messaging application.

Regarding features, I definelty will. Two things that could bring up now are:

• change setup to eliminate need to set delay before instantiating TORController, maybe by changing interfaces to indicate asynchronous nature
• add Cocoapods integration (I will try to prepare PR for that)

Anyways, great job!

[conradev]

For the first one, the connected state of the controller (with the tor daemon) is not very robust. I am considering doing the following:

– Adding an observer for the connected state (so you can be notified if the connection times out, etc.)
– Automatically attempting to connect to tor (if not connected) before every command, with a retry for ECONNREFUSED, such that the need for a delay is eliminated

As for the Cocoapods integration, I want to avoid having to distribute binaries. We can depend on @FredericJacobs pod for OpenSSL, and write a pod with two subspecs, one for tor, one for libevent, both with prepare_commands to compile them. I also want to avoid duplicated build systems, so if the prepare_commands could share code with the existing shell scripts, that would be ideal.

In the future I can consider making these into full standalone specs. The only reason I am supportive of Cocoapods right now is for ease of integration – I do not want to embrace it fully. Carthage wasn't any work to support because it already compiles in Xcode. The ideal build system is one that is cross platform such that it can be used inside of gitian for reproducible builds on iOS. I am aware of a few of developing technologies to this end (iOS builds on Linux), so I want to wait on these before overhauling the build system.

[chrisballinger]

Just a heads up, if you use Fred's OpenSSL pod as a dependency of another pod, you won't be able to use Swift or dynamic frameworks via use_frameworks! due to the transitive static library dependency. For whatever reason, vendored static libraries in a podspec can only be one step removed from your project without triggering this problem.

[conradev]

Closing in favor of #18