A couple of weeks ago RetroShare has released version 0.6.6. But while download page offers quite a variety of pre-built packages for different operating systems, there is no 0.6.6 build for Mac OS (only 0.6.5 is available).
- Good Building Mac Os Download
- Mac Os Versions
- Mac Os Download
- Newest Mac Os System
- Good Building Mac Os X
Run the Installer Package to Install Go on Mac. Open the Mac OS installer package and follow the steps. There are no configurations and options to choose from, so it's a straight forward installation. What nobody has asked yet is WHY build a Mac server from this hardware when CentOS would likely do almost anything better than macOS Server on the same hardware. Don't get me wrong, I love Mac OS as a desktop OS, but macOS Server is a real pain to work with and maintain. A couple of weeks ago RetroShare has released version 0.6.6. But while download page offers quite a variety of pre-built packages for different operating systems, there is no 0.6.6 build for Mac OS (only 0.6.5 is available). I found this peculiar, so I decided to try to build it from sources myself. It also seemed like a good opportunity to finally try RetroShare, as it has been available for. I am attempting to build Google Breakpad for Mac OS X as a part of porting an application, based on the trunk revision 782. The Breakpad wiki specifies that one should build client/mac/Breakpad.xcodeproj, which produces a Breakpad.framework including a dynamically linked lib if I understand correctly. There is also sample code on how to use this from an Objective-C application, but all this. I suggest you use Mac OS 10.5 or higher when trying to build OpenBIOS. Part 1: Installing the cross compiler on Mac OS X 1). Download the AWOS cross compiler: 2) Expand this bz2 file by double clicking on it. 3) Rename the file AWOS-CC to AWOS-CC.img. 4) Open the image file. 5) Open the 'AWOS Cross-Compiler for OS X' file on the newly mounted disk.
I found this peculiar, so I decided to try to build it from sources myself. It also seemed like a good opportunity to finally try RetroShare, as it has been available for more than 15 years, and I've heard many good things about it.
At the moment Mac OS section on download page looks like this:
Let's take a cheeky look into the building process then.
RetroShare is based on Qt and currently it uses qmake. So as the very minimum, aside from cloning the repository, you need to have Qt installed in your system. If anything, I built mine from sources, but it will most likely just as well work if you'll get it using official installer.
Just in case, here's my environment:
The base application is extendable with plugins, and there is a qmake configuration option for building those too. I'll describe the process for both variants: with and without plugins.
Building without plugins is easier, because it has less 3rd-party dependencies. And I would say, 3rd-party dependencies is the main difficulty of building RetroShare from sources.
Without plugins
There is some documentation on the matter (more about that later), from which I got to know that I need to install the following dependencies:
SDK resolving issue
Let's try to configure it now:
So right from the very beginning you are getting this fantastic error in your face. Smells like something is hardcoded somewhere.
And indeed, if you open /path/to/retroshare/src/retroshare.pri, there is this weird block at the line 129:
This hardcoded list of versions doesn't look good at all. And no matter what values I provided to CONFIG, the configuration was always failing with the same error. Certainly can't tell what grand plan original developer had behind it, but it definitely does not make sense to me. So I ended up editing this block manually like this:
Good Building Mac Os Download
Why 11.1? Because that's what xcrun reports in my system, and apparently that's what is getting checked against during configuration.
Now the project configures fine, so we can build:
Missing OpenSSL headers paths
But during the build I got these errors: Death wheel mac os.
That can be solved by explicitly providing paths to OpenSSL headers:
By the way, Homebrew had a warning about something similar:
and I tried to do so in my ~/.bash_profile:
but that didn't help. And providing paths via qmake CLI parameters did help, so that's what I will be doing going forward.
Missing dependencies
Next error I got was this:
That is solved by installing RapidJSON:
Then there was this error:
That is solved by installing SQLCipher:
Missing paths to linked libraries
After that everything finally built, but failed on linking stage:
That is because providing just include paths is not enough, you also need to provide paths to linked libraries binaries. So, the final sequence of commands to configure and build RetroShare (without plugins) is this:
Features
You might want to enable/disable certain application features:
- by default
autologinis disabled, so you'll need to enter your password every time you launch RetroShare, which is certainly more secure but also rather annoying - another example is
retroshare_service, which, if I understood correctly, allows RetroShare to run 'headless' (without GUI). It is enabled by default, and I don't need it - not sure what
use_native_dialogsdoes, but it is disabled by default, and having enabled it I seem to get more responsive GUI dialogs in the application
So my configuration looks like this:
Building takes about 8 minutes on my Mac, and as a result I get a working RetroShare application in /path/to/retroshare/src/build/retroshare-gui/src/RetroShare.app.
With plugins
RetroShare has some plugins as part of the main repository, and there are also plugins in separate repositories (for example, RetroChess).
To enable building RetroShare with plugins, you need to set this:
If you want to build more plugins than just the ones from main repository, clone their repositories and copy sources to /path/to/retroshare/src/plugins folder and add them in plugins.pro:
Before building you need to install required dependencies:
The last one, OpenCV, is one crazy package. It drags a whole bunch of dependencies of its own, which in turn drag a lot more on their own, including by the way Qt. You can see the full list for yourself:
Anyway, having installed all the dependencies, you can now build the project. Needless to say, you'll face errors about missing headers and linked libraries, so to save you some time, here are all of them:
…Yet, you will still get errors, though different ones this time. Here's the first one:
This one is happening because RetroShare doesn't link to one of the libraries from OpenCV. To find out which one, you can google for cv::VideoCapture and discover that it's part of videoio, so you need to add that missing link with LIBS+=-lopencv_videoio.
Next error was more difficult to figure out:
Luckily, I've encountered something similar (not exactly) before, so soon enough I suspected that it's yet again Mac OS providing an obsolete version of a library. And indeed, after I installed and used the latest XSLT library:
the problem was gone. So, here's the final configuration command (with the features I've enabled):
Having built such a configuration, aside from RetroShare.app you will also get plugins built in /path/to/retroshare/src/build/plugins/**/lib/*.dylib. These files needs to be either bundled into RetroShare.app/Contents/Resources/ or copied to /Users/YOURNAME/.retroshare/extensions6/ (or whichever path is set in Preferences). Having done that, when you launch RetroShare next time, it should discover the plugins:
What about building from Qt Creator
You might ask, why building with bare qmake from CLI, why not building from Qt Creator?
Well, first of all, building from CLI is just faster and actually more convenient. But also here's what I get when I try to build the RetroShare project from Qt Creator:
And I've no idea what this is about. I have CMake discoverable in my PATH, and also it is added in Qt Creator settings, and also I can build other CMake projects from Qt Creator just fine. Yeah, no idea.
Bundling resources
There are certain styles files which need to be bundled in the application bundle. Not sure why those are not added to resources.
So, if you won't bundle those, the application will still work, but you will be missing some skins/styles in the list of available style options, for example Bubble style for chats:
Bundling stuff into application bundle on Mac OS with qmake is done via QMAKE_BUNDLE_DATA. In /path/to/retroshare/src/retroshare-gui/src/retroshare-gui.pro on line 275 there is a block for macxscope - that's where the application icon is getting bundled, by the way. To bundle styles (or other resources) too, add the following lines:
Having configured and built the application, you should get the following contents in your RetroShare application bundle:
Making a DMG
If you'd like to distribute your build to other people, you'll need to bundle required libraries and frameworks and also make a DMG.
Why DMG? No particular reason, really. It can just as well be a ZIP archive, but DMG seem to be more common for distributing applications on Mac OS.
In order to find and copy all the required libraries and frameworks, I would recommend to use macdeployqt. Actually, I would not recommend it, as it seem to bundle some redundant things as well, for example Virtual Keyboard, which I don't think is used in RetroShare. But still - it does the job, so it's easier to copy all the dependencies with macdeployqt than to find and copy them manually. Though RetroShare plugins do need to be copied manually.
Conveniently enough, macdeployqt can also make a DMG. So here's the entire chain of commands for deployment:
Homebrew is awesome
I must say, Homebrew is an absolute life savior. Getting (and building) all the dependencies without it would take dramatically more time. Or maybe I would have just given up halfway.
About RetroShare
Mac Os Versions
I've never used RetroShare before, and here's what I can tell after using it for a week.
Documentation isn't great
Documentation, and namely Mac OS build instructions, is scattered across several places. I could count at least five:
- Three documents (and a patch) in the main repository:
MacOS.10.6_RS_Compilation_Instructions.txtMacOS_X_InstallGuide.mdOSX_RS_Compilation_Instructions.txtretroshare-mac-build.patch
The manual for building is not very helpful, which is why I created this very article. I would even say, the instructions from manual are half-baked and written in a negligent manner, there are a lot of typos and it even contains nonsense like:
In QtCreator Option Git add its path:
That is from the section about building RetroShare on Mac OS.
General documentation content also seems to be outdated. There are screenshots of menus and settings that no longer exist, and some instructions refer to no longer existing things as well.
Surely, I would be happy to make my contribution and update the documentation with my instructions, and also to fix typos and to make it look better. But given its current state, it just feels like my efforts would go into a void. At the very least documentation should be concentrated in one place first.
Inconsistent connectivity
RetroShare requires you to have 'friends' - other people's nodes who added you as their 'friend'. There are no servers: basically everyone is a server, and together they form a network.
That is the first difficulty you will encounter, but that is not an issue, and actually that is one of the main features of RetroShare. It's even awesome. Also, luckily enough, I've got invites from several people, so I had at least something to connect to.
The real issues started to appear later: I tried running RetroShare on Windows, Mac OS and Linux, and I had different experience on all three.
Windows
On Windows I seemed to get connected at first, and I was even getting forums, chats and so on, but the very next day it just stopped: I am no longer able to see any forums, and all the chats I entered the day before now have no people in them.
The NAT and DHT indicators show the following:
And neither of them ever got green.
Mac OS
Then I tried it on Mac OS, as by that moment I've managed to build it. There it was better, and I get forum posts, chats and so on.
The NAT and DHT indicators, however, are all red:
Mac Os Download
Plus Network settings seem to have some troubles getting external IP, though I am not sure if it matters:
Linux
Finally, I tried RetroShare in a virtual machine running Linux, and would you look at that:
Everything is green!
Newest Mac Os System
No idea, how come the same thing works so differently across different platforms in the same network. I even tried forwarding ports on my router - that didn't change a thing: still, only Linux had green DHT indicator, and Windows was still having troubles getting content.
Good Building Mac Os X
Overall
As much as I wanted to like it, as a user, I can't say that I will use RetroShare every day or rely on it for something important. It could be that this is because I am still an unexperienced user, but it has been more than a week as I'm trying to get familiar with it, and now I am about to give up.
The idea is certainly great, no doubt about that, especially looking at how 'normal' internet is going to shit, but implementation is certainly not perfect. Aside from inconsistent connectivity, there are random (but seldom) application crashes, GUI can freeze on certain actions, notification flags on tabs do not disappear even though there are no unread items left, etc - all that results in not a great user experience.
On the bright side, though, the repository is rather active, so hopefully it all will get better eventually. Maybe I will even find some time to help fixing those issues.
And as a developer, I must admit the fact that (despite the length of my article) RetroShare actually builds just fine on Mac OS, and almost all the troubles I had were coming from missing dependencies. Given the cross-platform nature and the size of the project, this is quite impressive, especially considering that Mac OS is not its primary target platform.
Here are magnet links for my RetroShare 0.6.6 builds on Mac OS:
Let me know if it fails to run on your system, because I suspect that macdeployqt doesn't actually pack all the dependencies.
