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.
Related
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 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.
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.
I have received an old code on the Mac and trying to compile it on OS X 10.6, in the code there are few calls to OpenSSL library (such as SSL_write()) I added the headers (#include ) in those files and check my version of OpenSSL shows me "0.9.8r" (I know Apple has it's own framework for this library crypto' ) but why I get the Link error as this:
sockets::TcpSocket::TryWrite(char const*, unsigned long) in TcpSocket.o
I know the code should compile against this library in /usr/lib but it doesn't, do I missing path or other setting in Xcode?
There are no libraries in /usr/bin. I assume you mean /usr/lib. You generally do not compile against /usr/lib, however. You usually compile against a specific SDK, which has its own copy of /usr/lib and /usr/include. The SDK header files you use is generally passed in the -isysroot parameter. If you're building in Xcode, these settings are set primarily via the "Base SDK" and "OS X Deployment Target." Without more specifics of how you're building, I'm not certain where else to point you, though. In particular, what does the compile and link lines look like for the relevant file?
In Xcode, don't try to link against specific system libraries by path. You should always link against system libraries using the Link Phase panel of the build settings, and selecting from the SDK list of libraries. Selecting specific paths in the Link Phase panel almost always leads to problems.
I'd like to compile a fortran code with gfortran so that it will work on both Mac OS X 10.5 and 10.6. Is there a way to do this? I tried compiling on 10.6 and get this message when I run the executable on 10.5:
dyld: unknown required load command 0x80000022
Trace/BPT trap
What version of 10.5 are you on? According to this (0x22) is a dynamic load function that got added at 10.5.6. You could try upgrading to >10.5.6 and see if the problem persists.
Also where did you get your gfortran from? In the numpy community the ones from att.com are highly recommended and the builds from hpc are generally to be avoided.
The application was incorrectly built on OS X 10.6 machine for a 10.5 machine. The developer can fix this by considering three things:
Using the correct compiler parameters:
gcc-4.2 -mmacosx-version-min=10.5 -isysroot /Developer/SDKs/MacOSX10.5.sdk ...
Using the correct linker settings (setting environment variable before link command). This is required, so that the OS X 10.6 linker will not use the loader command 'LC_DYLD_INFO_ONLY' (=0x80000022), because OS X 10.5 does not understand this command:
export MACOSX_DEPLOYMENT_TARGET=10.5
(or setenv MACOSX_DEPLOYMENT_TARGET=10.5)
After this is fixed, one can check if the application was correctly built for OS X 10.5 by running 'otool':
otool -l binary
The correct binary should not contain any 'LC_DYLD_INFO_ONLY' load commands (only 'LC_DYLD_INFO' commands).
(also see my blog article http://grauonline.de/wordpress/?p=71 )