I keep encountering this weird linker error when compiling things on OS X using autotools. The error is this:
ld: symbol(s) not found for architecture x86_64
I tried looking this up, and everything I've found shows the user set something up wrong in their Xcode project and clang gets messed up, but I'm not using Xcode, so autoconf is failing somewhere. This happened to me with gcc-5.1, binutils, lame, and a few other stuff. What am I missing?
Here's an example, trying to compile binutils for a different target.
Related
Does anyone know how to do specify the Mac OS X SDK to build against with CMake? I have searched for cmake mac "base sdk" but this turned up nothing.
I am using CMake to generate Unix makefiles.
Update
On my 10.6 install, I see that /Developer/SDKs has the following:
MacOSX10.4u.sdk
MacOSX10.5.sdk
MacOSX10.6.sdk
Perhaps I can get CMake to pass one of these paths to the compiler somehow?
Also, my 10.7 install only has:
MacOSX10.6.sdk
MacOSX10.7.sdk
Does this mean that it can only build for these platforms?
Update 2
Damn, I just realised that actually I'm not using Xcode -- so this may affect some answers. Also, I am now trying with Mac OS X 10.8 developer preview (with some weird results, see my answer).
After trying sakra's valid answer (valid as far as CMake is suposed to behave) unsucessfully, I had a dig around and found that if I specify the --sysroot flag to the compiler, it seems to use the correct SDK!
However, I now see this error when I compile against 10.7 (which I don't see with 10.8):
Undefined symbols for architecture i386:
"_NXArgv", referenced from:
execSelfNonDaemonized() in libarch.a(CArchDaemonUnix.o)
CArchDaemonUnix::daemonize(char const*, int (*)(int, char const**)) in libarch.a(CArchDaemonUnix.o)
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/synergyc] Error 1
make[1]: *** [src/cmd/synergyc/CMakeFiles/synergyc.dir/all] Error 2
make: *** [all] Error 2
Note: CArchDaemonUnix is a class in Synergy (an open source project I'm working on).
Update:
Just tried this on my 10.6 install, and I was getting a linker error when trying to compile for 10.5 -- turns out you also need to specify the MACOSX_DEPLOYMENT_TARGET environment variable!
Anyway, here's what I'm doing when running on Mountain Lion (OSX 10.8) to compile for 10.7:
Command line:
MACOSX_DEPLOYMENT_TARGET=10.7
cmake -G "Unix Makefiles" -DCMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.7.sdk/ -DCMAKE_OSX_DEPLOYMENT_TARGET=10.7 ../..
CMakeLists.txt:
set(CMAKE_CXX_FLAGS "--sysroot ${CMAKE_OSX_SYSROOT} ${CMAKE_CXX_FLAGS}")
I hope this helps someone! :-)
Add the following commands on your CMakeLists.txt
set(CMAKE_OSX_SYSROOT macosx10.10)
set(CMAKE_OSX_DEPLOYMENT_TARGET "10.5")
This should be fine.
You can set the variable CMAKE_OSX_SYSROOT to the chosen SDK upon configuring the project. E.g.:
cmake -DCMAKE_OSX_SYSROOT=/Developer/SDKs/MacOSX10.4u.sdk/ ..
See the documentation here.
Also note that CMake versions before 2.8.8 do not support Xcode 4.3.
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.
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
I mostly work on linux and have no problems but want to occasionally use a Mac for work. Somehow gfortran does not work there, though. I installed it as instructed but when I try to compile something, this happens:
gfortran -o m_g_matrix2.x m_g_matrix.f90
ld: entry point (start) undefined. Usually in crt1.o for architecture x86_64
collect2: error: ld returned 1 exit status
I have no idea what this means and google search did not help. Did someone manage to get gfortran to work on Mac?
Thanks for the help!
I installed gcc binaries for yosemite from http://hpc.sourceforge.net
and also installed Xcode command-line tools as directed there.
gcc contains the gfortran compiler.
Seems to work well on macbook air with Yosemite.
JTN
I'm consistently getting errors across the board related to the following problem, on Mac osx 10.7.4 via a 2011 mac book pro.
these errors are mostly from mathematical related dev libs that compile and run example code without error on various linux machines, while using similar make files
the error i get is usually something on the lines of
ld: symbol(s) not found for architecture x86_64
this also occurs with various compilers and no matter how i compile the lib I link, clang, various versions of gcc even haskell's ghc
some libs that give me errors are
PETSC(which i compiled from source and none of the examples compile
with make test)
GSL(from macports) gives same error
FFTW... and the list goes on
I believe the culprit is that some where along the line something (maybe a compiler) was compiled via macports improperly,
for instance gcc -v states it was compiled Target: i686-apple-darwin11
--build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~28/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11
while every other compiler, clang , g++-mp-4.7 exc, says Target: x86_64-apple-darwin11
is there any solution to this problem?
is there a way to recompile everything enforcing 64 bit? Would that fix the above problem?
Mac OS X has its own build toolchain, so this probably is a path issue.
Check
which gcc
and compare the path with any library you know comes from mac ports (probably in /opt/bin).
As a solution, putting the /opt/bin path at the beginning of your $PATH should work out.