Update Mac Build Instructions in Wiki and Dependency Pack (to 64-bit)

[egirsova]

As mentioned in the Building and Packaging on OS X page in the wiki, right now it is kind of tricky to build on Mac OS X 10.8 or later. The only information that we get regarding how to do it is the statement: "you will need to either convince the compiler to produce 32-bits binaries, either produce a 64-bits dependency pack".

I feel like the wiki could do a better job of explaining this process step-by-step and perhaps provide a 64-bit dependency pack so that each developer doesn't have to generate it themselves. It has been nearly 5 years since the 10.7 release and I'm assuming that the majority of Mac users are now on OS X 10.8+ (and would therefore need to produce 64-bit binaries).

I would be able to help out with updating the Wiki instructions and providing the 64-bit dependency pack. I have already created a git repository that has all of the necessary 64-bit dependencies as well as the build instructions. I'm just not sure what the best way of integrating all of this with the STK project and SourceForge files would be. Thoughts?

[hiker]

Hi, we would glad to improve the osx situation. Auria, who is typically doing out mac builds (on a somewhat older system) might provide more feedback in a day or two.

Thanks! Joerg

[nado]

Concerning sourceforge, AFAIK it is only used for the datas repository (meshes, assets, etc). So, everything code related would be on github.

[egirsova]

@nado, the way it's set up right now is that all of the dependencies for Mac first need to be downloaded from sourceforge. The dependencies provided there are only 32-bit though and don't work well with the newer operating systems (which is why I think they should be updated to include 64-bit dependencies).

[nado]

Oh. Right. Nevermind me then.

[auriamg]

Hi, that's a very nice start, thanks!

It's really nice to have 64-bits binaries. One thing though, instead of supplying a replacement CMake file, why not simply issue a pull request against the current one, so that it can build both 32-bits and 64-bits? (or maybe 32-bits is not required anymore, there's probably not many 32-bits macs left anyway)

In the next few days I'll try your 64-bits build on my mac and see if everything works fine for me

[egirsova]

Hi @auriamg, thanks for your response!

I think it's definitely a good idea to allow both 32-bit and 64-bit binaries, and not completely weed out the 32-bit users. To be honest, I'm not super familiar with CMake files (my replacement CMake files have only minor changes regarding the build architecture) but I can look into editing the main one and the corresponding library ones so that they can build both 32 and 64-bits. The only issue is that I wouldn't be able to test the 32-bit build because I don't have a 32-bit machine.

[auriamg]

Just a quick update, I was able to build and run STK 64-bits with your changes, nice work! We'll need to have a little team discussion as to whether we want to keep supporting 32 bits or if we go 64-bits only - that will determine what happens with the CMake files.

There is one little issue though, your frameworks are not all distributable, the Fribidi one uses @rpath, and the Freetype one contains a hardcoded absolute path

If you're not familiar with making distributable frameworks, just compare the outputs of otool -D :

$ otool -D /Library/Frameworks/Ogg.framework/Ogg
@executable_path/../Frameworks/Ogg.framework/Versions/1.3/Ogg

$ otool -D /Library/Frameworks/FreeType.Framework/FreeType
/Library/Frameworks/FreeType.framework/Versions/2.4/FreeType

All frameworks should be fixed to use @executable_path using install_name_tool. I can do it if you want

One final question, I see you modified the cmake file for libpng, removing a part where it setups a unix configuration file. May I know what? Were there issues with that part? The way you changed it may break unix/linux builds so I can't use this as-is

[egirsova]

I'm glad you got STK to run in 64-bits.

I made the necessary changes using install_name_tool so that all the frameworks use @executable_path. I committed those changes to my repository so you can take a look.

Yeah, I had modified the CMakeLists file for libpng because I was getting an error when trying to get it to build on my Mac. I just tested it again, though, with the unix part restored and wasn't running into any errors this time. I'm assuming the issue I was having previously had been related to something else. So, I updated the libpng CMakeLists file to include the unix part again and committed those changes as well.

Also, I remember removing the below part in the CMakeLists file for the wiiuse library because it prevented STK from configuring on my Mac (I ended up getting the FATAL_ERROR and the cmake configuration stopped).

# libbluetooth is required on Unix platforms
if(UNIX)
    include(FindPkgConfig)
    pkg_check_modules(BLUETOOTH bluez)
    if(NOT BLUETOOTH_FOUND)
        message(FATAL_ERROR "Bluetooth library not found. "
            "Either install libbluetooth or disable wiiuse support with -DUSE_WIIUSE=0")
    endif()
endif()

Is the libbluetooth library necessary for building/running on a Mac? In the comments it says "# libbluetooth is required on Unix platforms". I'm not sure if you consider Apple a "unix platform" in this case. I just tried restoring that entire part and changing the if statement to:

if(UNIX AND (NOT APPLE))

After making that change I am no longer getting the FATAL_ERROR and cmake is able to configure properly. I added these changes to my latest commit as well.

If the libbluetooth library is necessary for Mac, though, then I'm assuming we would need to somehow include it with the dependencies rather than simply changing the if statement.

[Benau]

In #2138, auria told you why, because bluez (libbluetooth) is linux-specific.

[auriamg]

Thanks! Pretty much everything seems in order and ready to merge :)

Just one last question, I see you are overwriting CMAKE_C(XX)_ARCHIVE_CREATE and CMAKE_C(XX)_ARCHIVE_FINISH, could you explain why? The defaults were always okay up to now, and everything still builds fine for me without those lines

[auriamg]

I have just pushed most changes to github, thanks! I only left out the CMAKE_C(XX)_ARCHIVE_CREATE and CMAKE_C(XX)_ARCHIVE_FINISH part as mentionned above, since I don't need that modification to get it working. That should pretty much complete this issue - maybe the wiki page on building could be improved a bit (feel free to help edit it, too!) but it's already a bit better as I've done some cleanup

[egirsova]

Great! I'm happy I could help.

The reason I'm overwriting CMAKE_C(XX)_ARCHIVE_CREATE and CMAKE_C(XX)_ARCHIVE_FINISH is because of the build warnings that occurred when trying to build in Qt. More specifically, Qt would give me a bunch of "has no symbol" warnings that prevented STK from building so those lines were meant to prevent those warnings (because there were no issues in the make build). I can't seem to recreate the issue now, though, so I think it's fine to leave out those additions. I might play around a little bit more to see if I can figure out what was causing that warning in the first place and will circle back here if I do. But I think we're good for now. Thanks for merging!

[hiker]

Can this ticket be closed now?

[egirsova]

Yes, as far as I know.

[hiker]

Thanks a lot!

Cheers, Joerg

[auriamg]

Okay something weird has happened with this. I remember I had tested it all, but the dependency package no longer seems to work : when unzipping the dependencies zip file, all symlinks are lost, producing an unusable framework. @egirsova would you still happen to have the originals so that we can produce a new, correct 64-bits dependency pack? Maybe packaging it as a dmg would be safter than as a zip

[egirsova]

Hi @auriamg, all of the necessary frameworks are located in my repository here. Are you trying to build for Xcode?

[Benau]

No not xcode, now we are trying to git clone your repo and copy it directly to /libraries/framework (try to preserve symbolic links) instead of using .zip file, hopes succeed...

[egirsova]

Okay, sounds good. Let me know if there is anything I can do to help.

[Benau]

Now @ozoneone who is our musician can finally build STK on his OSX now! It should allow him to test his new music more easily.

And we did it with git clone your repo and copy it to /libraries/framework,so I guess the Dependencies.zip may need a new format...

[egirsova]

Great! Glad it worked.

[auriamg]

Yes it seems like the zip we have on sourceforge is corrupt, will check to make a new one

[auriamg]

I uploaded a new zip, hopefully it should be fine now