Question / Help Help wanted with compiling

keybounce

Member
I'd like to know: What is your secret to making a Mac release of OBS?

I just found out about the following new things:
1. Beam.pro has a streaming service with a sub-second delay (instead of 15 seconds to 15 minutes with twitch)
2. Beam does this with a customized version of OBS (their code is also on github, forked from this)
3. They are based on OBS 18, with only a windows release
4. The official OBS 18 is also windows only.

I have no problem compiling things. I technically *can* compile OBS. But what I get is not actually runnable (it crashes). And when I tried getting a version that someone else had compiled, it died with a missing library.

So there is some unknown special magic.

Would someone be willing / able to help me figure out what it takes to compile a mac release that is actually portable from one system to another?

Once I can get the official release working, I can then get the beam version with "FTL" streaming working. And at that point, I can say "bye-bye Twitch".
 

Narcogen

Active Member
I'd like to know: What is your secret to making a Mac release of OBS?

I have no problem compiling things. I technically *can* compile OBS. But what I get is not actually runnable (it crashes). And when I tried getting a version that someone else had compiled, it died with a missing library.

Which library?
 

Narcogen

Active Member
I use homebrew to install QT5, and it goes in /usr/local/opt/qt5

If you add the path to your qt installation to CMAKE_PREFIX before running cmake, it should use that one instead.

export CMAKE_PREFIX_PATH=/path/to/qt5/

I am honestly not knowledgeable enough to know what, if anything, I can do to make my build more portable. I would have assumed that it looked for qt5 during compilation and not afterwards.

Alternatively I guess I could use MacPorts to install qt5 on another machine and compile a separate build.
 

keybounce

Member
Ugh.

I have just asked some basic question over on the MacPorts mailing list.

How bad is it?

Me:
Is this why a program compiled against a brew installation of qt5 in /usr/opt won't work with a ports installation of qt5 in /opt/local, and visa-versa?

Partial response:
DYLD_LIBRARY_PATH... but this exact situation is also why DYLD_LIBRARY_PATH can break your whole system and should not be used except as a last resort. (Yes, I do mean "whole system" --- you can search for DYLD_LIBRARY_PATH in MacPorts Trac and find instances of people breaking Apple-provided system binaries... which is part of why Sierra prevents Apple binaries from using that and other dyld envars via SIP. (Thereby causing other kinds of breakage for various people... dyld envars are *extremely* blunt tools, and so is SIP in many ways.)


Ultimate response:
Use something like Platypus to create an app bundle, and dylibbundler to stow the needed dylibs in its Resources. Everything has to cart around its own set of dylibs. And even then you have no guarantees, because ...

And the list of possible problems ...

Ugh. So, OBS people: How in the heck do you manage? You document a simple "cmake .. && make", but it actually takes a lot more than that -- what's the trick?
 
Top