Building a cross compile of binutils on OS X Yosemite - macos

I'm trying to build binutils for generating MIPS code on Mac OS X.
I found this site (http://www.theairportwiki.com/index.php/Building_a_cross_compile_of_GCC_for_MIPS_on_OS_X) from How to build GCC 4.8.x on Mac OS X host for MIPS target, and followed the instructions.
I install the gcc-4.8 from brew, and installed source code of binutils and gcc. This is the compilation option setup.
$ export CC=/usr/local/bin/gcc-4.8
$ export CXX=/usr/local/bin/g++-4.8
$ export CPP=/usr/local/bin/cpp-4.8
$ export LD=/usr/local/bin/gcc-4.8
$ export PREFIX=/opt/cross/gcc-mips
$ export CFLAGS=-Wno-error=deprecated-declarations
Then I configure, and make the bintuils.
The issue is that after building static libraries I have an error message that archive is not built for x86_64, and then I have a bunch of undefined symbol error.
ignoring file ./../intl/libintl.a, file was built for archive which is not the architecture being linked (x86_64): ./../intl/libintl.a
Undefined symbols for architecture x86_64:
"__bfd_abort", referenced from:
_fix_new_internal in write.o
_size_seg in write.o
Googling to find that I need to setup AR (archive) variable also from https://github.com/tpoechtrager/osxcross/issues/11. I added export AR=/usr/local/bin/gcc-ar-4.8, but I have another error message because gcc-ar-4.8 doesn't work.
/usr/local/bin/gcc-ar-4.8
/usr/local/bin/gcc-ar-4.8: Cannot find plugin 'liblto_plugin.so'
Googling again to find that gcc-ar doesn't work with Mac OS X (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56893).
gcc-ar is for use with newer GNU binutils only as that is the only ar which supports plugins.
Apple's ar does not support plugins (though it could be made to; it will be a different plugin interface than the GNU BFD
plugin interface which GCC supports right now).
I just created a dumb 'liblto_plugin.so' file in /usr/local/Cellar/gcc48/4.8.4/libexec/gcc/x86_64-apple-darwin14.3.0/4.8.4 directory to suppress the error message, but in this case it looks like that /usr/ar is invoked when I use /usr/bin/gcc-ar-4.8 to get the same architecture and undefined symbols error.
How to solve these issues? How to build cross compiler tools (gcc and binutils) on Mac OS X?

The static library generator for Mac OS X is not ar, but libtool -static. There is another SO post about this - Static library link issue with Mac OS X: symbol(s) not found for architecture x86_64.
The binutils has multiple libraries that are linked statically. So I replaced all the ar rc command with libtool -static -o to get the static libraries that do not cause errors.
In doing so, I had to make two modifications also.
Some library generate libtool script to conflict the Mac OS X's libtool, I had to rename the script.
Some object files do not contain symbols, I had to remove the objects.
Then I could get the binaries without any issue.

Related

How can I get boost to compile for an earlier deployment target on OSX?

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

Mac cross compiling (or alternatives) with golang

Ok so I'm trying to compile my Awesomium go wrapper on my mac (everything works fine on linux). My problem is, when I try to compile I get
ld: warning: ignoring file /Library/Frameworks//Awesomium.framework/Awesomium, file was built for i386 which is not the architecture being linked (x86_64): /Library/Frameworks//Awesomium.framework/Awesomium
Undefined symbols for architecture x86_64:
Fine. But that raises a few questions. First, I didn't have the option to download a x86_64 version for Mac, it was "the mac version" no architecture. Second, I checked a few other libraries and it seems like nothing is built x86_64.
Now I thought maybe I could make a i386 version just for osx but it seems it's extremely difficult, some say impossible, to cross compile cgo.
What are my options?
I'm not sure if you're going to run into any other problems with the universal binary, but building an i386 go toolchain is fairly easy.
http://golang.org/doc/install/source
You can then set the GOHOSTARCH and GOARCH environment variables, e.g.
GOHOSTARCH=386 GOARCH=386 ./all.bash

Compiling GREP 2.18 on OS X 10.9.2

When I attempt to build grep-2.18 on Mac OS X 10.9.2, make returns
ld: warning: ignoring file libgrep.a, file was built for archive which is not the architecture being linked (x86_64): libgrep.a
Undefined symbols for architecture x86_64:
It then lists what must be inside libgrep.a that got ignored. Please help, This has baffled me for ages.
Also, I'm the sort of person that is fussy and doesn't like using pre-built binaries, so please do not tell me to use MacPorts, Homebrew, etc...
build grep-2.20 with this configuration
./configure --prefix=$PREFIX --build=i386-apple-darwin CFLAGS=-m32

Haskell package missing c library

I'm having trouble building the hmatrix library on OS X Lion. Looking at the .cabal file, it requires the gsl library, so I installed it with macports. The .a files are in /opt/local/lib and the .h files are in /opt/local/include/gsl
As suggested here I changed the built-type from Custom to Simple. (without that change I get a similar error).
When I use cabal configure I get the following output:
* Missing C library: gsl
This problem can usually be solved by installing the system package that
provides this library (you may need the "-dev" version). If the library is
already installed but in a non-standard location then you can use the flags
--extra-include-dirs= and --extra-lib-dirs= to specify where it is.
So I tried cabal --extra-include-dirs=/opt/local/include --extra-lib-dirs=/opt/local/lib configure, but I still get the same error. I can compile and link a c program that includes gsl. What files is cabal looking for? If I have the right files, how do I tell it how to find them?
libgsl.a is a universal binary:
$ file /opt/local/lib/libgsl.a
/opt/local/lib/libgsl.a: Mach-O universal binary with 2 architectures
/opt/local/lib/libgsl.a (for architecture x86_64): current ar archive random library
/opt/local/lib/libgsl.a (for architecture i386): current ar archive random library
ghc looks like it's 64-bit:
$ ghc --info
[("Project name","The Glorious Glasgow Haskell Compilation System")
,("GCC extra via C opts"," -fwrapv")
,("C compiler command","/usr/bin/llvm-gcc")
,("C compiler flags"," -m64 -fno-stack-protector -m64")
,("ar command","/usr/bin/ar")
,("ar flags","clqs")
,("ar supports at file","NO")
,("touch command","touch")
,("dllwrap command","/bin/false")
,("windres command","/bin/false")
,("perl command","/usr/bin/perl")
,("target os","OSDarwin")
,("target arch","ArchX86_64")
,("target word size","8")
,("target has GNU nonexec stack","False")
,("target has subsections via symbols","True")
,("Project version","7.4.2")
,("Booter version","7.4.2")
,("Stage","2")
,("Build platform","x86_64-apple-darwin")
,("Host platform","x86_64-apple-darwin")
,("Target platform","x86_64-apple-darwin")
,("Have interpreter","YES")
,("Object splitting supported","NO")
,("Have native code generator","YES")
,("Support SMP","YES")
,("Unregisterised","NO")
,("Tables next to code","YES")
,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn")
,("Leading underscore","YES")
,("Debug on","False")
,("LibDir","/usr/local/Cellar/ghc/7.4.2/lib/ghc-7.4.2")
,("Global Package DB","/usr/local/Cellar/ghc/7.4.2/lib/ghc-7.4.2/package.conf.d")
,("Gcc Linker flags","[\"-m64\"]")
,("Ld Linker flags","[\"-arch\",\"x86_64\"]")
]
As an alternative to mac-ports you can use the nix package manager for mac. It does a pretty good job of taking care of the c dependancies for for the libraries available through it. In general I have been more happy with it then any other package manager on mac.
Unfortunately mac(darwin) unlike for linux does not have as many binaries available through nix so installing ghc often means waiting for it to compile.
The commands to install ghc and hmatrix after installation of nix are:
nix-env -iA nixpkgs-unstable.haskellPackages.ghc
nix-env -iA nixpkgs-unstable.haskellPackages.hmatrix
All of the needed dependencies will be taken care of for you.
I just tried it on my macbook pro and hmatrix seems to be working correctly in ghci after trying commands from the first few pages of the tutorial.
I'm not a mac person, but it really sounds like you haven't installed the "-dev" version. For a mac, I suspect you need to install gsl-devel in addition to gsl. If the problem persists, verify that you have libgsl0-dev on your library path.

Dylibs and OS X

I am trying to run a program called vowpal-wabbit (version 6.0) in mac os x.
I've used homebrew to install some things, such as lib tools and, importantly, boost.
However -- I'm finding that, even though
/usr/local/Cellar/boost/1.49.0/lib
Clearly has all the boost libs, (including lib boost_program_options.dylib)...
The error message i get when trying to run a binary is :
dyld: Library not loaded: libboost_program_options.dylib
I get the same (basically) error when running "make" to build this binary from scratch :
ld: library not found for -lboost_program_options
So ... I guess my question is : How can I get my compiled binary to "see" the libboost_program_options.dylib ? Or alternatively... how can I get vw (version 6.0) running on os x lion.
I'll guess that /usr/local/Cellar/boost/1.49.0/lib is not on either DYLD_LIBRARY_PATH or DYLD_FALLBACK_LIBRARY_PATH. You could export either of those in your environment, or you could symlink the Boost libraries from /usr/local/lib.
Be careful not to wipe out the contents of DYLD_FALLBACK_LIBRARY_PATH, though! From the dyld man page, the default value for this is $(HOME)/lib:/usr/local/lib:/lib:/usr/lib.

Resources