I'm trying to build a project that depends on SDL2 library. I've installed and linked it using homebrew:
> ls /usr/local/lib | grep SDL2
libSDL2-2.0.0.dylib
libSDL2.a
libSDL2.dylib
libSDL2_test.a
libSDL2main.a
I also added /usr/local/lib to my /etc/paths and ~/.bash_profile as well:
> cat /etc/paths
/usr/local/lib
/usr/local/bin
/usr/bin
/bin
/usr/sbin
/sbin
However, when I try to build the project, I still get this error:
error: linking with `cc` failed: exit code: 1
note: cc '-m64' '-L' (...) '-lSDL2'
ld: library not found for -lSDL2
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Why does it happen and how can I fix it?
I fixed the issue by adding /usr/local/lib to my $LIBRARY_PATH:
For bash, in ~/.bash_profile:
export LIBRARY_PATH="$LIBRARY_PATH:/usr/local/lib"
And for fish shell, in ~/.config/fish/config.fish:
set -g -x LIBRARY_PATH $LIBRARY_PATH /usr/local/lib
/etc/paths is for executable files, not shared libraries. Same with the $PATH environmental variable set in .bash_profile. These are the paths searched for programs when you type a command in the terminal.
What you need to do is change the linkers link path. See the answer to this question for details on how to set up the link path.
Related
I've reproduced this symptom on two computers now, cmake seems to no longer look in /usr/local/lib (or more properly, $(brew --prefix)/lib) for Homebrew-provided libraries since upgrading my machine to macOS Mojave.
Although there are ways to circumvent this (e.g. search for homebrew prefix using EXECUTE_PROCESS; add the result to LINK_LIBRARIES(...) command) none are ideal. What changed in Mojave to break this behavior?
The temporary workaround is to add the following to CMakeLists.txt:
# WARNING: Don't hard-code this path
LINK_DIRECTORIES(/usr/local/lib)
I've already tried brew doctor and updated all homebrew packages to no avail.
The specific error that cmake (make) shows is:
ld: library not found for -l<somelib>
I've asked the question on the Homebrew forums and the Apple developer forums.
Ran into a related (?) issue while trying to pip install psycopg2 in a Django app under OS X Mojave (10.14). I was getting the following errors:
ld: library not found for -lssl
clang: error: linker command failed with exit code 1 (use -v to see invocation)
error: command 'clang' failed with exit status 1
The short explanation: « As of High Sierra, /usr/local is no longer
chown-able... »
The solution: change permissions for /usr/local to allow Homebrew to
create links.
I adapted the solution to my needs. Then I was finally able to run pip install psycopg2. Here is the sequence of commands (update: inside your project root i.e. where you see manage.py).
First
sudo chown -R $(whoami) $(brew --prefix)/*
Then
brew reinstall openssl
export LDFLAGS="-L/usr/local/opt/openssl/lib"
export CPPFLAGS="-I/usr/local/opt/openssl/include"
pip install psycopg2
I've isolated this to the following change in the VERBOSE=1 make logs...
High Sierra (<=10.13) and below did NOT use the -isysroot command.
Mojave (>=10.14) DOES use the -isysroot command.
From gnu.org:
-isysroot <dir>
This option is like the --sysroot option, but applies only to header files (except for Darwin targets, where it applies to both header files and libraries). See the --sysroot option for more information.
So this flag specifically clobbers the lib search path only on Apple. This results in the compilation never looking in the standard ld locations, which can be seen by typing ld -v dummy.
Library search paths:
/usr/lib
/usr/local/lib
Why does cmake do this? My thought is it was to fix the /usr/local/include issues introduced with the new Mojave SDK behavior.
Unfortunately, I can't find a cmake compile flag to add the default library search paths back in. For now the only solution I've found is to add the following to my project:
IF(APPLE)
# Fix linking on 10.14+. See https://stackoverflow.com/questions/54068035
LINK_DIRECTORIES(/usr/local/lib)
ENDIF()
I'm not sure if this is a behavior that warrants an upstream cmake patch. If there is a better solution, please provide it.
So, I downloaded libSoil from https://github.com/smibarber/libSOIL and ran make, then sudo make install in Terminal. No errors, seemed to go fine.
But when I try and add libSOIL.dylib to the "Link Binary With Libraries" list in my XCode project, I get a linker error when I try to compile.
It says:
ld: library not found for -lSOIL
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I managed to install and link GLFW3 to my project without any problems, so I'm not sure what the problem is here.
I figured out the problem: my header search path was at /usr/local/Cellar/glfw3/3.1/include instead of /usr/local/include
I am installing the Moses Translation Software on my Mac OS X 10.9.5 with Xcode 6.1. The instructions say that I need g++ and Boost installed. Once I do that, I git clone, "cd" into the directory, and then type ./bjam -j8. First, I verified I have the prerequisites. First, g++ (I just clicked the TAB to see what was available):
$ g++
g++ g++-4.9
Then boost:
$ brew install boost
Warning: boost-1.56.0 already installed
Then I tried installing:
$ ./bjam -j8
Tip: install tcmalloc for faster threading. See BUILD-INSTRUCTIONS.txt for more information.
mkdir: bin: File exists
...patience...
...patience...
...found 4469 targets...
...updating 155 targets...
darwin.link lm/bin/darwin-4.2.1/release/debug-symbols-on/link-static/threading-multi/query
ld: library not found for -lboost_thread
clang: error: linker command failed with exit code 1 (use -v to see invocation)
// Additional error messages...
...failed darwin.link mert/bin/darwin-4.2.1/release/debug-symbols-on/link-static/threading-multi/util_test...
...skipped <pmert/bin/darwin-4.2.1/release/debug-symbols-on/link-static/threading-multi>util_test.passed for lack of <pmert/bin/darwin-4.2.1/release/debug-symbols-on/link-static/threading-multi>util_test...
darwin.link mert/bin/darwin-4.2.1/release/debug-symbols-on/link-static/threading-multi/vocabulary_test
ld: library not found for -lboost_thread
clang: error: linker command failed with exit code 1 (use -v to see invocation)
"g++" -o "mert/bin/darwin-4.2.1/release/debug-symbols-on/link-static/threading-multi/vocabulary_test" "mert/bin/darwin-4.2.1/release/debug-symbols-on/link-static/threading-multi/VocabularyTest.o" "mert/bin/darwin-4.2.1/release/debug-symbols-on/link-static/threading-multi/libmert_lib.a" -lboost_unit_test_framework -llzma -lbz2 -ldl -lboost_system -lz -lboost_thread -lm -liconv -g -Wl,-dead_strip -no_dead_strip_inits_and_terms
...failed darwin.link mert/bin/darwin-4.2.1/release/debug-symbols-on/link-static/threading-multi/vocabulary_test...
...skipped <pmert/bin/darwin-4.2.1/release/debug-symbols-on/link-static/threading-multi>vocabulary_test.passed for lack of <pmert/bin/darwin-4.2.1/release/debug-symbols-on/link-static/threading-multi>vocabulary_test...
...failed updating 72 targets...
...skipped 83 targets...
The build failed. If you need support, run:
./jam-files/bjam -j8 --debug-configuration -d2 |gzip >build.log.gz
then attach build.log.gz to your e-mail.
You MUST do 3 things before sending to the mailing list:
1. Subscribe to the mailing list at http://mailman.mit.edu/mailman/listinfo/moses-support
2. Attach build.log.gz to your e-mail
3. Say what is the EXACT command you executed when you got the error
ERROR
There's a ton of error messages not shown (condensed into "// Additional error messages"), and they are all of the form "ld: library not found for -lboost_thread". So it's clear that something can't find a boost-related library, but I don't know how to fix this. Does anyone have suggestions? I literally just copied a couple of lines from the installation instructions, and Moses is popular enough such that an obvious error in the installation instructions would have been caught long ago.
Additional comment: On the installation instructions page, they list a command where they can force an installer to find the boost library:
./bjam --with-boost=~/workspace/temp/boost_1_55_0 -j8
My boost is in
/usr/local/Cellar/boost/1.56.0/
I tried substituting the --with-boost= argument with the above file path, but that did not work either (I got the same errors).
I'm going to post this on the Moses mailing list but I'd also want to ask here because I have gotten this same error ("library not found ... clang: error: linker command failed with exit code 1") with other software and it would be helpful for me to learn a general strategy for making sure that clang can find my libraries.
This package expects a non-standard layout of boost (or maybe that's the standard liayout for installed boost on many systems, but it certainly isn't the default layout for boost in my working directories):
bjam --help says:
--with-boost=/path/to/boost
If Boost is in a non-standard location, specify it here. This directory is
expected to contain include and lib or lib64.
When my Boost build tree is in
/home/sehe/custom/boost/boost // headeers
/home/sehe/custom/boost/stage
/home/sehe/custom/boost/stage/lib // libraries
I have created a "forwarding" directory - so I'm not required to install boost:
mkdir /tmp/boost-moses
cd /tmp/boost-moses/
ln -sfv /home/sehe/custom/boost/stage/lib lib
ln -sfv /home/sehe/custom/boost include
Now I could trigger a build in the mosesdecoder directory with
./bjam --with-boost=/tmp/boost-moses
It's not said here which Moses version ComputerScientist compiled, but his last comment hit the nail. When I was about to compile version 2.1.1, I needed to rewrite Jamroot file and jam-files/boost-build/tools/mpi.jam and change all the boost_mpi mentions to boost_mpi-mt. It seems to me that boost-1.55 used different library style then boost-1.56 and Moses was in that version adapted to 1.55.
However I am not able to compile Moses 3.0 with either boost-1.55 or boost-1.56 now because of undefined reference to boost::filesystem::path::stem().
Unfortunatelly I can not post this as a comment to previous answer...
I am getting a link error when trying to build the sdc tutorial file. I've installed the gnat gpl using the install script. And the .o files exist in /usr/lib/x86_64-linux-gnu.
How do I configure to get the linker to see? I've tried adding to the path.
here's the output:
gnatmake -d -P/home/steve/workspace/ada/tutorial/sdc.gpr -XBuild=DEBUG sdc.adb
gnatbind -static -x /home/steve/workspace/ada/tutorial/obj/sdc.ali
gnatlink /home/steve/workspace/ada/tutorial/obj/sdc.ali -g -o /home/steve/workspace/ada/tutorial/obj/sdc
/usr/gnat/libexec/gcc/x86_64-pc-linux-gnu/4.7.4/ld: cannot find crt1.o: No such file or directory
/usr/gnat/libexec/gcc/x86_64-pc-linux-gnu/4.7.4/ld: cannot find crti.o: No such file or directory
/usr/gnat/libexec/gcc/x86_64-pc-linux-gnu/4.7.4/ld: cannot find -lc
/usr/gnat/libexec/gcc/x86_64-pc-linux-gnu/4.7.4/ld: cannot find crtn.o: No such file or directory
collect2: error: ld returned 1 exit status
gnatlink: error when calling /usr/gnat/bin/gcc
gnatmake: *** link failed.
[2013-11-29 08:47:55] process exited with status 4 (elapsed time: 00.21s)
This is in general a sign that there was a problem during the installation. Removing your install (/usr/gnat) and reinstalling might fix the issue.
The answer comes late, but hopefully will be useful to someone else seeing the same issue later on.
I have downloaded the boost library (version 1.46.1), but I don't know how to link it through xcode.I found an old question says to put the -lfftw3 flag, so I've put it.
I also added the path: /home/Documents/C++/boost_1_46_1 (it's the directory where I have put the library), but I am getting an error from the linker:
ld: warning: directory not found for option '-L/home/ramy/Documents/C++/boost_1_46_1'
ld: library not found for -lfftw3
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Command /Developer/usr/bin/clang++ failed with exit code 1
So the question are two:
1)How to manage xcode to link boost?
2)Where to put the library in file system? In linux there was /usr/lib, here there isn't this path, should I put it in /Developer/usr/lib?
Or for those who are looking for a quick answer (and are on linux), the magic is simply to add the following flags:
-l boost_system