I want to distribute a gui app built with Haskell, but when I try to open it on a different Mac (with an older macOS) it fails.
This seems to be due to the minos value in the LC_BUILD_VERSION mach-o load-command:
% otool -l ./lamdu | grep minos
minos 11.0
How can I specify to GHC/Cabal/stack the deployment target to use (the equivalent to Clang's -mmacosx-version-min flag)?
Adding these lines to the .cabal file did the trick:
if os(darwin)
ld-options: -mmacosx-version-min=10.9
Even though the build through stack shows warnings that not everything (i.e the used Haskell libs) was build for this deployment target, the executable worked fine when testing on an older macOS
Related
this question has been asked before, but none of the answers seem to be currently working.. whether that's because they are incomplete, or things have changed, I don't know.
I build my code for a deployment target of 10.7 (my clients use their machines for music production, so they often prefer to stick with what they know works rather than updated with every new OS release).
I'm using boost.
So when I buid I get a bunch of warnings
ld: warning: object file (/usr/local/lib/libboost_filesystem.a(path.o)) was built for newer OSX version (10.10) than being linked (10.7)
ld: warning: object file (/usr/local/lib/libboost_system.a(error_code.o)) was built for newer OSX version (10.10) than being linked (10.7)
and so on.
So, I want to build boost (version 1.58 currently, unfortunately cmake is usually a couple of versions behind in what it can find) for a deployment target of 10.7
It seems the magic instruction is
macosx-version-min=10.7
except I can't make it work.
./bootstrap.sh
sudo ./b2 -a macosx-version-min=10.7 install
Just doesn't do it, nor do any of the other things I've tried (I'm not familar with how b2 works, so I'm grasping in the dark).
I expect I'm missing something simple, but some help would be much appreciated
regards
Jon
I ran into the same issue and could only fix it by building boost with the 10.7 library. I've used XCode 8.2.1. Here is what I did:
Modifying "Darwin.Jam". Look for this line: feature macosx-version-min : : propagated optional ;
and add this line below feature.extend macosx-version-min : 10.7 ;
Modify "Info.plist" in /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform and set <key>MinimumSDKVersion</key>
<string>10.11</string>
Make sure your XCode.app has the 10.7 SDK installed. This is the right location: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs You can extract or copy it from an earlier version of XCode.
Now build boost with these options: cxxflags="-stdlib=libc++ -std=c++11 -mmacosx-version-min=10.7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"
E.g. ./b2 -a cxxflags="-stdlib=libc++ -std=c++11 -mmacosx-version-min=10.7 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk"
The solution above will build Boost with the 10.7 SDK instead just setting the Target SDK to 10.7
I'm working on touching up homebrew's (OS X package manager) llvm formula. Unfortunately, something about the parts I added broke the build in a way I just cannot figure out.
tl;dr ld asks for a library containing a _wordexp symbol for iOS simulator, and I have absolutely no clue where it is, if it exists
Compilation consistently fails for me when the compiler is attempting to link the address sanitizer dylib for iOS Simulator.
Reproduction steps (OS X only as far as I know, don't have *nix systems handy):
install homebrew if it isn't already installed
replace homebrew's llvm formula with the WIP one above
Run brew install llvm --with-clang --with-lldb --verbose --debug
wait for the build to fail and ask you what to do
Drop into a debug shell
cd to projects/compiler-rt/lib/asan/CMakeFiles/clang_rt.asan_iossim_dynamic.dir
add the following line to link.txt
-Wl,-syslibroot /Applications/Xcode-beta.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk
go back up to asan
Run make
At this point on my machine, something like this pops up:
Undefined symbols for architecture x86_64:
"_wordexp", referenced from:
_wrap_wordexp in asan_interceptors.cc.o
substitution_wordexp in asan_interceptors.cc.o
(maybe you meant: _wrap_wordexp)
ld: symbol(s) not found for architecture x86_64
I thought that it was just a matter of adding another folder to the linker search path. Turns out it isn't that simple:
wordexp.h is in <path-to-iPhoneSimulator.sdk>/usr/include, but running
find . -type f -name "*.dylib" -print0 | xargs -0 nm | grep -n "T _wordexp" -B <large number> | less
in Xcode-beta.app showed that the only .dylibs in Xcode that exported a _wordexp symbol were in the WatchSimulator.platform folder
Running the same command in /usr showed that 3 libraries in /usr/lib/system exported _wordexp (libsystem_asl, libsystem_c, and libsystem_blocks), but the linker doesn't seem to care when I add /usr/lib/system to the search path even when the code is the x86_64 code it wants, and the corresponding dylibs I found for other platforms didn't contain _wordexp
Googling about about this particular symbol missing turned up mostly stuff about Apple implementing wordexp() with Perl
I think I remember seeing something in the llvm-dev mailing list archives about *BSD/OSX not implementing wordexp, but the header file is definitely there, wordexp() shows up in the manpages, and the functions declared in the header file seem to work just fine when compiling for OSX
The symbol is not in the libc++(abi) dylibs compiled earlier in the build
Every other part of the build compiles just fine except for the asan folder and its parents
What am I missing? Given that this error does not seem to be particularly common, there could be a chance it's my machine, but I'm hoping the chances are pretty low, because I wiped and reinstalled my computer this weekend.
(OS X 10.11, Xcode/CLT 7.1, mid-2012 Retina pro)
If more info is needed I'll be happy to provide it.
Edit 1: Simplified link.txt fix. Turns out setting sysroot for clang++ doesn't do so for ld
Turns out the error was a result of the way homebrew processed compiler flags. That and a few other problems have been fixed since, so this probably isn't too useful any more.
For those curious about how exactly this broke, homebrew tries to change compiler flags to suppress warnings and create a more consistent building experience. One of these changes was to remove any -isysroot or -system flags, because that was added by homebrew itself at a later stage. Unfortunately, homebrew assumed that only the OS X SDK would be used, so when the build expected to build something with the iPhone simulator SDK it was pointed to the OS X SDK.
I'm trying to compile a project from the command line. The default compiler LLVM-clang and i need to compile with LLVM-gcc42. Switching a compiler in Xcode is really easy. However, on command line it seems to be more problematic. To my understanding "/usr/bin/cc" and "/use/bin/gcc" are used for pointing c/c++ compilers. I noticed that "cc" was linked to "clang" in same directory. So, i changed "cc" to point at "gcc". Did not helped. When i run
$ gcc -v
i get response
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)
Target: x86_64-apple-darwin12.5.0
How do i change the clang to gcc?
My setup is:
MAC OS X 10.8.5
Xcode 4.6.2
Command line tools
EDIT 13.02.2014
The project is a QT project which uses mixture of third party c/c++ libraries. My task is to write a new objective C lib to it. The project is build with -spec macx-g++ parameter. The configuration scripts can be found /QTROOT/mkspecs/macx-g++ and /QTROOT/mkspecs/common. In g++-base.conf key variables are defined as:
QMAKE_CC = gcc
QMAKE_CXX = g++
Instead of changing links which can affect other programs use the full path to the llvm executables in your build script
e.g. if you have installed the command line tools
QMAKE_CC = /usr/bin/llvm-gcc-4.2
QMAKE_CXX = /usr/bin/llvm-g++-4.2
Okay, nailed the problem. Solution was simple. I deleted the old links from /usr/bin/gcc and /usr/bin/g++ and created new ones pointing to the proper compilers.
gcc -> /Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/bin/llvm-gcc-4.2
and
g++ -> /Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/bin/llvm-g++-4.2
I'm trying to build a static, universal Qt from source on Mac OS X 10.6 using the following command:
sh configure -static -opensource -universal
The problem, I have been told, is that PPC is not supported on 10.6 so I am getting many errors and the build eventually fails.
So I need to build for a different target version of OS X - 10.4 or 10.5. How can I do that? Do I need to add some parameters to my configure line and, if so, which ones?
Try using the -sdk option to configure. e.g.
./configure -sdk /Developer/SDKs/MacOSX10.5.sdk -opensource -universal
...if you want to make binaries targeting OSX 10.5 and later.
Statically linking is a separate issue again. I would not recommend it, especially since OSX already supports app bundles anyway, which I believe gives most of the same benefits to the end-user as static linking.
I'm using Xcode 3.2.3 on Mac OS X 10.6.6 on a Mac Pro to build revision 5fd480ef577f of GrowlTunes from the growl-development repository.
With a clean build from a virgin checkout, this is what I get:
% gdb build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
GNU gdb 6.3.50-20050815 (Apple version gdb-1469) (Wed May 5 04:41:34 UTC 2010)
[blah blah blah]
This GDB was configured as "--host=x86_64-apple-darwin --target=powerpc-apple-darwin"...Reading symbols for shared libraries ......... done
(gdb) run
Starting program: /Volumes/RAM Disk/growl-development/Extras/GrowlTunes/build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
Don't know how to run. Try "help target".
When I try it in Xcode, it apparently does some internal test that fails, because it doesn't even list GDB as an option. Since there are no other debuggers (in this version of Xcode) for Cocoa applications, the pop-up menus related to debugging in the target Info window are empty, and attempting to run the app does nothing—the Run button switches back to being the Run button immediately.
The target is built for 32-bit PowerPC and 64-bit Intel:
% file build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes: Mach-O universal binary with 2 architectures
build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes (for architecture ppc7400): Mach-O executable ppc
build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes (for architecture x86_64): Mach-O 64-bit executable x86_64
I can run it directly, either from the terminal or from Finder, but that doesn't help me step-by-step debug.
This isn't a cross compilation scenario; I mean to run the 64-bit Intel architecture, which is my machine's native architecture, not the PowerPC architecture.
I'm guessing this is some build misconfiguration somewhere in the project, but I've no clue what or where. Any suggestions?
Workaround from a contact of mine:
gdb -arch x86_64 build/Debug/GrowlTunes.app/Contents/MacOS/GrowlTunes
I'd still appreciate a solution that would enable me to run/debug the app in Xcode.
Switching the order of the architectures in the relevant build setting fixed the problem both in gdb and in Xcode. This is a lame solution, and I'd still welcome a better one, but at least it works.
At gdb prompt, try 'set arch x86_64' or 'set arch i386:x86-64' (without quotes of course; I am a total newbie with gdb, I am lurking for solutions for other problems)