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...
Related
I am just starting out with libtorch and seem to have run into a rather serious linker issue. Previously, I was able to at least build other projects with torch (that others had created), but now that I've tried to create my own simple file, nothing seems to be building anymore.
I have manually installed the latest MacOS build in my root directory:
/Users/jlenz/libtorch/share/cmake/Torch
I am using CLion and have the following CmakeLists.txt:
cmake_minimum_required(VERSION 3.23)
project(midi_plugin)
set(CMAKE_CXX_STANDARD 17)
add_executable(midi_plugin main.cpp)
set(CMAKE_PREFIX_PATH "~/libtorch/share/cmake")
find_package(Torch REQUIRED)
target_link_libraries(midi_plugin "${TORCH_LIBRARIES}")
One thing that is noticeable, although the cmake 'succesfully' builds, it displays this in the process:
-- MKL_ARCH: intel64
-- MKL_ROOT /Users/jlenz/opt/miniconda3
-- MKL_LINK: dynamic
-- MKL_INTERFACE_FULL: intel_ilp64
-- MKL_THREADING: intel_thread
-- MKL_MPI: mpich
Once I try to build the project (which is just 'hello world' with torch included) I get the following error:
FAILED: midi_plugin
: && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -g -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.1.sdk -mmacosx-version-min=12.5 -Wl,-search_paths_first -Wl,-headerpad_max_install_names CMakeFiles/midi_plugin.dir/main.cpp.o -o midi_plugin -Wl,-rpath,/Users/jlenz/libtorch/lib /Users/jlenz/libtorch/lib/libc10.dylib /Users/jlenz/libtorch/lib/libkineto.a /Users/jlenz/libtorch/lib/libtorch.dylib /Users/jlenz/libtorch/lib/libtorch_cpu.dylib /Users/jlenz/libtorch/lib/libc10.dylib -lmkl_intel_ilp64 -lmkl_core -lmkl_intel_thread && :
ld: library not found for -lmkl_intel_ilp64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Would anyone know how to solve this? I have tried addressing it with a colleague who has used libtorch quite a bit and he can't identify the issue either. Many thanks in advance.
Posting my solution here in case someone else runs into a similar issue.
It turns out the issue was with my brew installation of torch, which was being referenced implicitly. To fix it, all I had to do was:
Brew install pytorch
It asked permission to overwrite some files that had issues, which I granted. Afterwards, all of my Torch projects are working perfectly.
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.
I am attempting to build tools from the CCtools collection for OSX, under OSX. I am doing this for research purposes.
When I run the makefile for the entire project I get a linker error:
=========== /Applications/Xcode.app/Contents/Developer/usr/bin/make all for misc =============
cc -Os -DLTO_SUPPORT -DTRIE_SUPPORT -g -Wall -I. -I./../include -I. -I/usr/local/include -c -o ./lipo.o lipo.c
cc -nostdlib -r \
-o ./lipo.private.o \
./lipo.o -L./../libstuff -lstuff
cc -o ./lipo.NEW \
./lipo.private.o
Undefined symbols for architecture x86_64:
"_is_llvm_bitcode_from_memory", referenced from:
_main in lipo.private.o
_check_archive in lipo.private.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [lipo.NEW] Error 1
make: *** [all] Error 1
Running the make files of the individual tools nets me a similar linker error. This occurs for all versions of the CCtools I have tried (Including 877.5, the latest source, and 862, the version that my installed tools are at.)
What am I missing to make the tools compile?
How can I coax the linker to let me know what library I am missing?
Where can I find instruction to make the tools compile?
Additional info:
I have XCode and developer tools installed, and I build projects all the time.
I also have gcc installed from brew.
I must be missing something stupid.
I cannot give you the exact solution for your version 877.5 but the overall problem is that the compilation requires some of the LLVM code on your machine. It might be as simple as missing include directories for the LLVM headers or can require linking some of the LLVM libraries. In your case, they seem to be related to LLVM Bitcode somehow.
In my case, I have just built a subset of the more recent version cctools-895. It complained about a missing symbol related to LLVM's llvm-c/lto.h header. The error went away when I added the following to the problematic file's compilation rules:
-I/opt/llvm-7.0.0/include/
The version of LLVM 7 was a random guess that worked because I had it on my machine. You might want to tailor your include paths to point to the correct version of LLVM that the cctools are supposed to be built with.
The easiest way to get the LLVM on your machine is to get a binary version from the LLVM Download page.
I've just compiled latest reps of LLVM, Clang and libc++. Now however I have no idea how to configure the environment to use them. I've added in $PATH the one to compiled binaries and have set the
$D_LIBRARY_PATH=$(llvm-config --libdir)
but anyway when I test run 'clang' with example file it uses some '/usr/bin/ld' linker which I have no idea what is it (as I've uninstalled 'g++' because thought it was the problem (before 'clang' used some linker from it) and I don't have any other C++ compilers).
So now how do I point out the right 'llvm-ld', libc++ include and library paths? I don't want to pass some complex arguments every-time. Perhaps I should set some environment variables.
I'm also using KDevelop with the same effect.
Don't judge me if this sounds stupid but it's my first time with Linux (have always used Windows before). I'm using latest 'OpenSUSE' dist.
Update - here is the output window of CodeLite using clang compiler:
/bin/sh -c 'make -j 2 -e -f Makefile'
----------Building project:[ ClangTest - Debug ]---------- make[1]: Entering directory
'/run/media/bs_ld/8688602a-296d-40e1-bd37-c90e69f45769/Workspace/CL_C++_WP/ClangTest'
clang++ -c
"/run/media/bs_ld/8688602a-296d-40e1-bd37-c90e69f45769/Workspace/CL_C++_WP/ClangTest/main.cpp"
-stdlib=libc++ -o ./Debug/main.cpp.o -I. -I/run/media/bs_ld/8688602a-296d-40e1-bd37-c90e69f45769/Build/include/c++/v1/
clang++ -o ./Debug/ClangTest #"ClangTest.txt" -L.
-L/run/media/bs_ld/8688602a-296d-40e1-bd37-c90e69f45769/Build/lib/ /usr/bin/ld: cannot find crtbegin.o: No such file or directory
/usr/bin/ld: cannot find -lstdc++ /usr/bin/ld: cannot find -lgcc_s
/usr/bin/ld: cannot find -lgcc clang-3.7: error: linker command failed
with exit code 1 (use -v to see invocation) ClangTest.mk:76: recipe
for target 'Debug/ClangTest' failed make[1]: * [Debug/ClangTest]
Error 1 make[1]: Leaving directory
'/run/media/bs_ld/8688602a-296d-40e1-bd37-c90e69f45769/Workspace/CL_C++_WP/ClangTest'
Makefile:4: recipe for target 'All' failed make: * [All] Error 2 0
errors, 0 warnings
You should be able to run make install with perhaps an optional DESTDIR=/...... so that it doesn't clobber your system files.
Since you're on OpenSUSE, you might as well use your distribution's build services, and install the SVN version of LLVM-Clang from here. You should be able to find libc++ and LLVM itself as well.
Otherwise, make install DESTDIR=/opt/llvm should work, and then you can add /opt/llvm/bin/ to PATH and use libc++ by adding this compile and link option: -stdlib=libc++. You'll need something like /opt/llvm/lib in LD_LIBRARY_PATH as well to find the libc++ so.
This should work pretty much out of the box, but I have only ever used my distribution's packages, not a self-built Clang to do this.
Note that Clang still uses your system linker, ld, and this is fine. Currently, LLVM does not yet provide a fully functional alternative to this program, but they are working on it.
EDIT: It seems you uninstalled too much: Clang also uses the GCC crtbegin and crtend object files. So just install GCC again along with glibc and its dev package.
I am still having trouble building the Portaudio library on my system, which is OSX 10.7.5 with Xcode 4.3.2, having Command Line Tools installed and having SDK10.6 and SDK10.7 under
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
I describe shortly (also for others that run into the same problem) what I have done so far (following different solutions I have found on the web).
1) I downloaded "Portaudio" / pa_stable_v19_20111121.tgz (last stable release) from:
www.portaudio.com/download.html
2) I read the instructions on building Portaudio here:
www.portaudio.com/docs/v19-doxydocs/compile_mac_coreaudio.html
and tried to compile from a Terminal window with the suggested command:
./configure && make
This resulted (not so surprisingly) in a lot of errors ending with:
llvm-gcc-4.2: error trying to exec '/usr/bin/../llvm-gcc-4.2/bin/powerpc-apple-darwin11-llvm-gcc-4.2': execvp: No such file or directory
lipo: can't open input file: /var/folders/1_/xkp08ky561jg02zjjrpsxg940000gn/T//ccPxCTrJ.out (No such file or directory)
make: * [src/hostapi/coreaudio/pa_mac_core.lo] Error 1
This happens because "ppc" is not supported anymore since OSX 10.5. Moreover the "Developer" folder doesn't exist on OSX 10.7 and everything that was in the Developer folder has moved to
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/
3) I downloaded a patch (mac_configure_patch.txt) to fix "configure" from:
https://www.assembla.com/spaces/portaudio/tickets/216#/activity/ticket:
and copied it to the portaudio directory and applied it by typing in Terminal:
$ patch < mac_configure_patch.txt
A confirmation message said:
patching file configure.in
So everything seems fine. But still Portaudio is trying to build for "ppc".
4) Now I set the ARCHFLAGS, CFLAGS, LDFLAGS to only build for architecture i386 as follows (disabling universal build):
$ MACOSX_DEPLOYMENT_TARGET="10.7" ARCHFLAGS="-arch i386" CFLAGS="-O2 -g -Wall -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -arch i386 -mmacosx-version-min=10.7" LDFLAGS="-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sd -arch i386 -mmacosx-version-min=10.7" ./configure --disable-mac-universal
5) Further I found that:
A): "#include AudioToolbox.h" in ".include/pa_mac_core.h" should be UNCOMMENTED
B): that "-wError" from "Makefile" (not Makefile.in) should be removed.
accoding to:
http://www.fluxforge.com/blog/building-portaudio-under-os-x-107-lion
6) Now I try to build (using: "sudo make"), compilation starts but but fails with:
ld: framework not found CoreAudio
collect2: ld returned 1 exit status
make: * [lib/libportaudio.la] Error 1
7) So I try to point to the framework using "-F/System/Library/Frameworks -framework CoreAudio"
leading to the following Terminal command:
$ MACOSX_DEPLOYMENT_TARGET="10.7" ARCHFLAGS="-arch i386" CFLAGS="-O2 -g -Wall -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -arch i386 -mmacosx-version-min=10.7" LDFLAGS="-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sd -arch i386 -mmacosx-version-min=10.7 -F/System/Library/Frameworks -framework CoreAudio" ./configure --disable-mac-universal
which seems to fix the CoreAudio framework issue but results in another error saying:
ld: library not found for -lSystem
collect2: ld returned 1 exit status
make: * [lib/libportaudio.la] Error 1
I am now stuck at this point. Did anyone experience the same problems when trying to build Portaudio on OSX 10.7 using SDK10.6 or SDK10.7. Did anyone find a solution to how to build Portaudio from Terminal?
I am very thankful for any hints!!!
Thanks in advance!
Try the latest svn. If that doesn't work right off the bat, you might need to muck with some of the flags.
eg, in configure.in:
change -Werror to -Wall
add -Wno-deprecated (you shouldn't need this, but just in case)
then run
./configure --disable-mac-universal
and make as usual.
OK, finally I solved the issue. Hope the solution will help others as well. I just forgot to also add the path to the CoreAudio framework to the CFLAGS. Here is the final configure/build command for building portaudio on OSX 10.7.5 using SDK10.7 for architecture i386 & x86_64:
Open a Terminal window in the portaudio directory and type:
MACOSX_DEPLOYMENT_TARGET="10.7" ARCHFLAGS="-arch i386" CFLAGS="-O2 -g -Wall -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -arch i386 -mmacosx-version-min=10.7 -F/System/Library/Frameworks -framework CoreAudio" LDFLAGS="-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk -arch i386 -mmacosx-version-min=10.7 -F/System/Library/Frameworks -framework CoreAudio" ./configure --disable-mac-universal
If this has finished, you need to edit Makefile and change the mention of -Werror to -Wall.
Then:
make
Voila. There you have your "libportaudio.la" in the portaudio/lib directory. You can now type
sudo make install
(you'll be asked to confirm using your password)
to put the library in the system directory.
Finally you can mess around with Portaudio!
Have fun!
Tried your instructions on Mac OSX Mountain Lion (10.8), and it was progressing a lot in compilation but then was failing with:
In file included from ./test/patest_sine_channelmaps.c:53:
./include/pa_mac_core.h:100:1: error: unknown type name 'AudioDeviceID'
AudioDeviceID PaMacCore_GetStreamInputDevice( PaStream* s );
^
./include/pa_mac_core.h:109:1: error: unknown type name 'AudioDeviceID'
AudioDeviceID PaMacCore_GetStreamOutputDevice( PaStream* s );
^
2 errors generated.
make: *** [bin/patest_sine_channelmaps] Error 1
However, I figured out you can simply use Homebrew (apt-like packet manager for OSX) and it will do the dirty job like a charm. Find binaries and headers in the specified install directory :)
$ brew install portaudio
Warning: It appears you have MacPorts or Fink installed.
Software installed with other package managers causes known problems for
Homebrew. If a formula fails to build, uninstall MacPorts/Fink and try again.
==> Downloading http://www.portaudio.com/archives/pa_stable_v19_20111121.tgz
######################################################################## 100.0%
==> Downloading patches
######################################################################## 100.0%
==> Patching
patching file include/pa_mac_core.h
==> ./configure --prefix=/usr/local/Cellar/portaudio/19.20111121 --enable-mac-un
==> make install
/usr/local/Cellar/portaudio/19.20111121: 8 files, 316K, built in 20 seconds