I'm trying to build boost library under Arch Linux
$ uname -a
Linux wincode 2.6.37-ARCH #1 SMP PREEMPT Fri Feb 25 07:53:43 CET 2011 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5200+ AuthenticAMD GNU/Linux
$ python --version
Python 3.2
$ ls /usr/include/python
python2.7/ python3.2mu/
$ ls /usr/lib/python
python2.6/ python2.7/ python3.1/ python3.2/
I'm building it using aur-repo. The auto-compile script could be found here.
Now I get:
./boost/python/*:50:23: fatal error: pyconfig.h: No such file or directory
compilation terminated.
at almost any file from boost.python library. So something is wrong with python and boost can't find it. At the end of the compiling I got:
...failed updating 336 targets...
...skipped 48 targets...
...updated 13264 targets...
Any help?
Quick google search comes up with http://lists.boost.org/boost-build/2006/04/13457.php.
Basically, add your python include directory to the include search paths.
Related
i created executable "standalone" file in NixOS (x86_64) using "ocamlopt" native compiler with option -linkall. and the generated program is executed in NixOS. so far so good
after that i tried to execute this file under Lubuntu
lubuntu#lubuntu:~/Documents$ uname -a
Linux lubuntu 4.18.0-10-generic #11-Ubuntu SMP Thu Oct 11 15:13:55 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
but recieved:
lubuntu#lubuntu:~/Documents$ ./a.out
bash: ./a.out: No such file or directory
i am quite sure that architecture is suitable:
lubuntu#lubuntu:~/Documents$ objdump -h a.out
a.out: file format elf64-x86-64
what i did wrong? on NixOS, on OCaml, on Lubuntu?
Tnx in advance
UDP: my NixOS distro:
$> uname -a
Linux cat 4.19.36 #1-NixOS SMP Sat Apr 20 07:16:05 UTC 2019 x86_64 GNU/Linux
ocaml:
$> ocamlopt -v
The OCaml native-code compiler, version 4.06.1
UDP2:
$> readelf -a a.out | grep ld-
[Requesting program interpreter: /nix/store/681354n3k44r8z90m35hm8945vsp95h1-glibc-2.27/lib/ld-linux-x86-64.so.2]
"No such file or directory" (ENOENT) when trying to execute a file that does exist usually means that its dynamic linker path (ELF interpreter) doesn't exist. It's exactly the same error for the same reason you'd get from executing a text file that started with #!/non-existant/path
Use strace ./a.out to see that the only system call is the execve which fails.
Most GNU/Linux distros use /lib64/ld-linux-x86-64.so.2. For example file /bin/ls on my Arch GNU/Linux desktop shows:
/bin/ls: ELF 64-bit LSB pie executable, x86-64, version 1 (SYSV),
dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2,
BuildID[sha1]=4fef2dc9762eb7d4593f402a65cc02bb3d4c48de, for GNU/Linux
3.2.0, stripped
Presumably NixOS, or at least ocamlopt on NixOS, uses a different path. Use file to check. (Or readelf -a to show the ELF program headers will also dump the interpreter path.)
ldd can also show the interpreter path, but IIRC fails if the path isn't valid.
I'm trying to create a recipe for the library here: https://github.com/hyrise/sql-parser
I'm building for OSX 10.13.
My build.sh looks like this:
#!/bin/bash
make VERBOSE=1
make DESTDIR="$PREFIX" install
I've also set up my SDK as per here: https://docs.conda.io/projects/conda-build/en/latest/resources/compiler-tools.html#macos-sdk
I can build the project fine outside of conda build, however conda build fails with the below issue:
x86_64-apple-darwin13.4.0-clang++ -std=c++1z -Wall -Werror -O3 -fPIC -c -o src/SQLParser.o src/SQLParser.cpp
In file included from src/SQLParser.cpp:2:
In file included from src/SQLParser.h:4:
In file included from src/SQLParserResult.h:4:
In file included from src/sql/SQLStatement.h:4:
In file included from /Users/j/miniconda3/envs/p37/conda-bld/sql-parser_1583094509703/_build_env/bin/../include/c++/v1/vector:265:
In file included from /Users/j/miniconda3/envs/p37/conda-bld/sql-parser_1583094509703/_build_env/bin/../include/c++/v1/iosfwd:90:
/Users/j/miniconda3/envs/p37/conda-bld/sql-parser_1583094509703/_build_env/bin/../include/c++/v1/wchar.h:119:15: fatal error: 'wchar.h' file not found
#include_next <wchar.h>
^~~~~~~~~
1 error generated.
make: *** [Makefile:66: src/SQLParser.o] Error 1
I can see wchar.h is in that dir
JMBA:v1 j$ ls -l /Users/j/miniconda3/envs/p37/conda-bld/sql-parser_1583094509703/_build_env/bin/../include/c++/v1 | grep wchar
-rw-rw-r-- 41 j staff 6272 28 Oct 2018 cwchar
-rw-rw-r-- 41 j staff 8080 28 Oct 2018 wchar.h
Any help on this would be appreciated.
You need to find a way to get -I$BUILD_PREFIX/include to the invocation of g++ / gcc
I am running a Virtual Machine of Ubuntu 18.04 via Oracle VirtualBox.
I need Eclipse (including cdt) for a c++ project. So I ran the following statement on the console:
sudo apt-get install eclipse eclipse-cdt g++
Then I waited until it finished installing. Afterwards, I tried to run Eclipse, which caused the following error:
An error has occurred. See the log file
/home/matthias/.eclipse/org.eclipse.platform_3.8_155965261/configuration/1540208856928.log
So, I checked the log file. It says the following:
!SESSION Mon Oct 22 13:38:43 CEST 2018
----------------------------------------- !ENTRY org.eclipse.equinox.launcher 4 0 2018-10-22 13:38:43.262 !MESSAGE
Exception launching the Eclipse Platform: !STACK
java.lang.ClassNotFoundException:
org.eclipse.core.runtime.adaptor.EclipseStarter at
java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:466)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:566)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:499)
at org.eclipse.equinox.launcher.Main.invokeFramework(Main.java:626)
at org.eclipse.equinox.launcher.Main.basicRun(Main.java:584) at
org.eclipse.equinox.launcher.Main.run(Main.java:1438) at
org.eclipse.equinox.launcher.Main.main(Main.java:1414)
Unfortunately, I am an absolute beginner with Ubuntu, as well as c++. I have no idea what could cause this problem. Can anybody help me?
I found that on Ubuntu18.04 this is due to a packaging problem (debugged with the help of a talented coworker). The fix was to manually install files from the older libequinox-osgi-java_3.8.1-8 package, to keep packaging happy.
Locate and get the .deb file
Examine contents of package vs. the system for overlaps
Manually extract deb into '/'
Commands:
$ cd /tmp
$ wget http://archive.ubuntu.com/ubuntu/pool/universe/e/eclipse/libequinox-osgi-java_3.8.1-8_all.deb
$ dpkg -c /tmp/libequinox-osgi-java_3.8.1-8_all.deb
$ dpkg -L libequinox-osgi-java
$ cd /
$ sudo dpkg -x /tmp/libequinox-osgi-java_3.8.1-8_all.deb
Notes:
Here we see commands to show eclipse depends on eclipse-rcp, which depends on libequinox-osgi-java (>= 3.9.1), which are all installed:
$ lsb_release -rc
Release: 18.04
Codename: bionic
$ apt-rdepends eclipse 2>&1 | egrep '^eclipse-rcp|libequinox-osgi-java'
eclipse-rcp
Depends: libequinox-osgi-java (>= 3.9.1)
libequinox-osgi-java
$ dpkg-query -W eclipse eclipse-rcp libequinox-osgi-java
eclipse 3.8.1-11
eclipse-rcp 3.8.1-11
libequinox-osgi-java 3.9.1-1
These commands show that the out-of-the box eclipse stubbornly insists on loading the older osgi_3.8.1.dist.jar despite not being able to stat it or open it:
$ strace -f -e trace=file /usr/lib/eclipse/eclipse -debug -clean -initialize 2>&1 |
egrep '^Framework.located|file:.*osgi_3.*jar|stat.*osgi_3.*jar'
[pid 117096] stat("/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar", 0x7f4f0ca95540) = -1 ENOENT (No such file or directory)
[pid 117096] stat("/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar", 0x7f4f0ca954c0) = -1 ENOENT (No such file or directory)
[pid 117096] stat("/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar", 0x7f4f0ca95550) = -1 ENOENT (No such file or directory)
[pid 117096] stat("/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar", 0x7f4f0ca954d0) = -1 ENOENT (No such file or directory)
Framework located:
file:/usr/lib/eclipse/plugins/org.eclipse.osgi_3.8.1.dist.jar
...
The older package just happens to be the same package used in the Ubuntu16.04 eclipse packages. We tried a few different ways to force install both older and newer packages, etc. but this made packaging unhappy and the manual extract Just Worked(tm).
Following this howto I'm cross-compiling a bluetooth application for Raspberry Pi (ARM). When I try to link with libbluetooth I get the error below. Even the simplest helloworld application (without bluetooth code) won't link.
arm-linux-gnueabihf-g++ -c hello.cpp -o hello.o
arm-linux-gnueabihf-g++ hello.o -o hello -lbluetooth -L/home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf
/home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.so: undefined reference to `__fdelt_chk#GLIBC_2.15'
sbf#sbf-VirtualBox ~/raspberrypi/projects/test $ ls -al /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth*
-rw-r--r-- 1 sbf sbf 132886 May 27 2016 /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.a
lrwxrwxrwx 1 sbf sbf 23 Nov 24 21:20 /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.so -> libbluetooth.so.3.17.11
lrwxrwxrwx 1 sbf sbf 23 Nov 24 21:20 /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.so.3 -> libbluetooth.so.3.17.11
-rw-r--r-- 1 sbf sbf 103376 May 27 2016 /home/sbf/raspberrypi/rootfs/usr/lib/arm-linux-gnueabihf/libbluetooth.so.3.17.11
Edit (added):
GLIBC Version 2.19
pi#raspberrypi:~ $ ldd --version
ldd (Debian GLIBC 2.19-18+deb8u6) 2.19
What's going wrong?
I was experiencing the same issue yesterday trying to link libbluetooth using raspberry pi tools.
To solve this I downloaded a newer version of Linaro dev tools (6.1.1) than what is supplied by the raspberry pi tools repository.
Here is the link to the latest linaro toolchain release
Download "gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf.tar.xz" and put that folder in your raspberrypi/tools/arm-bcm2708/ directory along with the other toolchains.
Then set compiler/linker paths to point to the new directory.
(I am using cmake)
SET(CMAKE_C_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER $ENV{HOME}/raspberrypi/tools/arm-bcm2708/gcc-linaro-6.1.1-2016.08-x86_64_arm-linux-gnueabihf/bin/arm-linux-gnueabihf-g++)
(edit) I had trouble running my executable with this version of the toolchain compiled since jessie doesn't support gcc versions 5 or 6. Instead try using this release https://releases.linaro.org/components/toolchain/binaries/4.9-2016.02/arm-linux-gnueabihf/
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...