easelpad wrote:
@etresoft - thanks. Can you please share what the *correct* specification for what that command would be? This is coming from a compile I'm doing against a source called VLC. I'm not specifying the command, it's embedded into the compile and this is the point where it crashes.
I just did "./configure" to build breakpad itself. I didn't look at anything in VLC.
I am happy to post the build / configure and support scripts he uses -- he sets a "$MINIMAL_OSX_VERSION" to be 10.11 -- in some cases 10.7 -- that *may* be where that's coming from.
I was wrong about the MACOSX_DEPLOYMENT_TARGET. I thought that was talking about the SDK version. Apparently that is the minimum deployment version. Ideally, all of those should be the same, either 10.7 or 10.11, but it should be fine.
In my projects I have the deployment version hard-coded. I don't see how that could or should be variable based on an environment setting. If the code requires 10.11 APIs, I don't see why you would want to allow a crashing version to be deployed on 10.10. And I also don't see why you would want to change the minimum to 10.12 if you only need 10.11. Just hard-code it to what the code really requires.
I took another look at what you posted. You are actually trying the build inside the client/Mac/ subdirectory. I'm not sure what that is. It looks like it builds the lower-level breakpad framework and a bunch of other things. That command is just wrong. When I try it with only command line tools installed, I get the following error:
xcode-select: error: tool 'xcodebuild' requires Xcode, but active developer directory '/Library/Developer/CommandLineTools' is a command line tools instance
That's pretty straightforward. But when I try that command with just Xcode installed, I get the same error you did. I'm not going to attempt to install both Xcode and command line tools. All you need to do is change that command and remove the sdk flag, like so:
xcodebuild MACOSX_DEPLOYMENT_TARGET=10.11 WARNING_CFLAGS=-Werror=partial-availability OTHER_CFLAGS=-fno-stack-check -arch x86_64 CLANG_CXX_LIBRARY=libc++
The command succeeds, but I don't think it actually works. There are some failures, that aren't actually errors, related to code signing. Ironically enough, the signing identity is something that would be better to pass on the command line.
I build a lot of code from various open-source libraries. There is no easy way to do it. Generally speaking, you should never, ever use any provided "Mac version". Those are generally hacked-up messes that worked once years ago and no one has checked it since. It is better to just build as if you are Linux or some generic UNIX. That would be via the "./configure". About 80% of the time, that works just fine. Usually the only time you need to make modifications is when the project has some hacked-up Mac support from ages ago.
If you are just building for your own machine, then this is pretty easy to manage. If you need to distribute it, then it will be more complicated. This is especially true if you are trying to do an iOS version. There are a number of different approaches, depending on what you need out of the project. I do all of my current work for distribution on both macOS and iOS, so I have the most complicated version. But if you don't need to distribute, you could even just do "./configure; sudo make install" and that will generally work. Any higher-level code that needs those libs should find them in /usr/local. If not, they can be easily modified to look there.
