When attempting to compile GNU GCC 5.3.0 I encounter the following error when it tries to build libjavamath.la.
/bin/bash ../../../libtool --tag=CC --mode=link /home/borish/Downloads/gcc-build/./gcc/xgcc -B/home/borish/Downloads/gcc-build/./gcc/ -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -Iyes/include -g -O2 -module -version-info 0:0:0 -no-undefined -Lyes/lib -lgmp -avoid-version -o libjavamath.la -rpath /usr/local/lib/../lib64/gcj-5.3.0-16 gnu_java_math_GMP.lo ../../../native/jni/classpath/jcl.lo
../../../libtool: line 5209: cd: yes/lib: No such file or directory
libtool: link: cannot determine absolute directory name of `yes/lib'
Makefile:403: recipe for target 'libjavamath.la' failed
This is on a Debian 8.4 system with GCC 4.9.2-10 installed. I believe I have satisfied all of the prerequisites, and Google wasn't been much help.
Any thoughts?
Update:
I used the following for running the configuration script:
../gcc-5.3.0/configure --disable-multilib --with-mpc --with-isl --with-mpfr --with-gmp
It sounds like you didn't run "configure" correctly. For example:
https://software.ecmwf.int/issues/browse/SUP-676
OK, I see a problem already, the "--with-jasper" option must point the
to the prefix of the "jasper" installation, for example
$./configure --with-jasper=/usr/local/jasper --with-png-support.
Otherwise the value "yes" is set as prefix..
For example, if you look here:
http://www.gnu.org/software/libc/manual/html_node/Configuring-and-compiling.html
you'll see that a flag like ‘--with-headers=directory’ REQUIRES YOU TO ENTER A DIRECTORY PATH. I suspect the same thing is happening with your "-with-mpc" etc.
SUGGESTION: clean your build directory, and (carefully!) re-run ./configure.
The culprit appears to be the --with-gmp, --with-mpc and --with-mpfr switches when initiating the configure script. I suspect since libgmp is a prerequisite for libmpc and libmpfr, a bug feature in the configure script will include the offending -I and -L directives. Inclusion of any of them will result in the following in the root Makefile
HOST_GMPLIBS = -Lyes/lib -lmpc -lmpfr -lgmp
HOST_GMPINC = -Iyes/include
I haven't confirmed this to be the case in any of the other Makefiles, but I suspect something similar is going on elsewhere which is what I ran into when it attempted to building libjavamath.la.
The work around is to omit those switches from the configure invocation. They should be included in any event since the configure script will fail if they aren't present on the host.
Related
I'm doing all this on a VLE and below is what I'm working with:
Running OS: Linux Centos 7
GCC:4.8.5 & 7.1.0
I'm trying to use GNU autotools (libtool, autoconf, automake) to build a project in 32-bit using gcc-7.1.0. Also, as a requirement, I must do this on Centos 7 and use gcc-7.1.0.
Apparently, the latest version of gcc that can be officially upgraded through yum is 4.8.5. However, I successfully installed gcc-7.1.0 from the official source and even included --enable-multiarch --with-list-multilib=m32,m64 --enable-multilib during configure.
The issue I'm running into is that the autotools seem to want to use the 64-bit libraries even though I'm including -m32 compiler switch in CXXFLAGS, CFLAGS, and LDFLAGS. The reason I think it's using 64-bit libraries at linking is that I get the error below:
libtool: link: g++ -m32 -fPIC -Wall -Wextra -Weffc++ -Werror -std=c++03 -O2 -o fldprog fldprog-icpprog.o ../../ ../seal3/fld/src/.libs/libbsp_fld.a -lpci /usr/local/lib/../lib64/libstdc++.so -lm -Wl,-rpath -Wl,/usr/local/lib /../lib64 -Wl,-rpath -Wl,/usr/local/lib/../lib64
/usr/local/lib/../lib64/libstdc++.so: error adding symbols: File in wrong format
And when I rename /usr/local/lib64 to lib64_something, the program will compile without any errors. However, I want to find a permanent solution.
I've searched the internet for answers but none of them seem to really work. I've tried including -L/usr/local/lib to AM_LDFLAGS, AM_CFLAGS in configure.ac
I'd appreciate any input. Thank you.
Edit:Revised
I am trying to compile some code within a Conda environment, where I
previously installed the compiler package gcc_linux-64.
However, even after deactivating and reactivating again the environment,
gcc is still /usr/bin/gcc.
What should I do to have Conda working as expected, ie. using the tool
I install ? Like it is for other software like git or whatever.
Any help would be appreciated, thanks in advance !
If you do:
export CONDA_BUILD=1
conda activate <name-of-env-in-which-gcc_linux-64-is-installed>
You will see:
INFO: activate-binutils_linux-64.sh made the following environmental changes:
+ADDR2LINE=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-addr2line
+AR=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-ar
+AS=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-as
+CXXFILT=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-c++filt
+ELFEDIT=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-elfedit
+GPROF=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-gprof
+LD=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-ld
+LD_GOLD=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-ld.gold
+NM=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-nm
+OBJCOPY=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-objcopy
+OBJDUMP=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-objdump
+RANLIB=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-ranlib
+READELF=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-readelf
+SIZE=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-size
+STRINGS=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-strings
+STRIP=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-strip
INFO: activate-gcc_linux-64.sh made the following environmental changes:
+CC=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-cc
+CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-strong -fno-plt -O2 -pipe -I/include -fdebug-prefix-map=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}-${PKG_VERSION} -fdebug-prefix-map=${PREFIX}=/usr/local/src/conda-prefix
+CPP=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-cpp
+CPPFLAGS=-DNDEBUG -D_FORTIFY_SOURCE=2 -O2
+DEBUG_CFLAGS=-march=nocona -mtune=haswell -ftree-vectorize -fPIC -fstack-protector-all -fno-plt -Og -g -Wall -Wextra -fvar-tracking-assignments -pipe -I/include -fdebug-prefix-map=${SRC_DIR}=/usr/local/src/conda/${PKG_NAME}-${PKG_VERSION} -fdebug-prefix-map=${PREFIX}=/usr/local/src/conda-prefix
+DEBUG_CPPFLAGS=-D_DEBUG -D_FORTIFY_SOURCE=2 -Og
+GCC=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-gcc
+GCC_AR=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-gcc-ar
+GCC_NM=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-gcc-nm
+GCC_RANLIB=/root/m3/envs/test/bin/x86_64-conda_cos6-linux-gnu-gcc-ranlib
+LDFLAGS=-Wl,-O2 -Wl,--sort-common -Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,--disable-new-dtags -Wl,-rpath,/lib -L/lib
+_CONDA_PYTHON_SYSCONFIGDATA_NAME=_sysconfigdata_x86_64_conda_cos6_linux_gnu
In your make file, you could use variables like $CC instead.
The issue is the name of the gcc compiler that conda installs. Because it isn't just gcc, it's some long complicated thing, eg. x86_64-conda_cos6-linux-gnu-gcc, it won't override the system executable, even if your conda directory is earlier in your PATH variable.
The solution is to softlink your conda gcc compiler into your local binary directory, eg. ln -s path/to/conda/gcc ~/.local/bin/gcc, and then put that ahead of your system binary directory in your PATH variable, eg. export PATH=$HOME/.local/bin:$PATH where your shell is sourced, ie. ~/.bashrc, ~/.bash_profile, ~/.zshrc, etc.
This will then point to your conda executable before the system one, and should have the appropriate name to override it.
Keep in mind that if you delete your environment, or replace / update the gcc installed in it, you will need to update the softlink accordingly. Unless you need lots of different gcc versions, I'd just install it to your base env, do the soft link, and don't touch it after that. Hacky, but it works.
Im using poky version of yocto, and adding zbar library in my yocto build. I found a readymade recipe at http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-support/zbar/zbar_0.10.bb and modified it a bit to get working with poky. I got it working fine with imagemagick, and the compiled zbarimg works on the target board.
The modified recipe is available here: http://paste.ubuntu.com/25725000/
When I proceed configuring python support (--with-python) to the build, some dependency issues crept up, which Im unable to resolve.
It appears as if the compiler doesn't find the appropriate headers, since the include paths don't contain appropriate folder.
The full compiler command is:
arm-poky-linux-gnueabi-libtool: compile: arm-poky-linux-gnueabi-gcc -march=armv7-a -mfloat-abi=hard -mfpu=neon -mtune=cortex-a7 --sysroot=/home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/sysroots/pico-imx6ul-emmc -DHAVE_CONFIG_H -I. -I/home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/zbar/0.10-r0/zbar-0.10 -I./include -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -D_FORTIFY_SOURCE=2 -g -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror=format-security -I/usr/include/python2.7 -I/usr/include/python2.7 -I/home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/zbar/0.10-r0/zbar-0.10/include -Wall -Wno-parentheses -O2 -pipe -g -feliminate-unused-debug-types -c /home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/work/cortexa7hf-vfp-neon-poky-linux-gnueabi/zbar/0.10-r0/zbar-0.10/python/symbol.c -fPIC -DPIC -o python/.libs/python_zbar_la-symbol.o
You can see that sysroot variable is set, and it appears like the right location, and there is /usr/include/python2.7 there, though its pointing right at the host system include path.
There is a warning from compiler: cc1: warning: include location "/usr/include/python2.7" is unsafe for cross-compilation [-Wpoison-system-directories] which I don't know why it happens, but it seems like the python2.7 folder is appropriately looked at, just not under the sysroot (my host system doesn't have /usr/lib/python2.7)
If I go to the sysroot include (/home/jlumme/imx_build/build-x11-pico-imx6ul/tmp/sysroots/pico-imx6ul-emmc/usr/include/) folder, I can see that it has a subfolder python2.7. If under this usr/include folder I add a symlink Python.h -> python2.7/Python.h, the compiler will complain about the next header file which is not found.
So to me it seems, all I should do is add the appropriate 'sysroot' + usr/include/python2.7 as include search folder it would compile happily - but Im not sure how..
The full compilation log is available here: http://paste.ubuntu.com/25725014/
This is a bug in the zbar configure script.
Try inheriting pythonnative so the configure script can run a compatible Python to know where to look.
I am trying to compile a Python PCL module which builds some C++ source. I am getting this error:
$ python setup.py install
running install
running build
running build_py
running build_ext
skipping 'pcl/_pcl.cpp' Cython extension (up-to-date)
building 'pcl._pcl' extension
/usr/bin/clang -fno-strict-aliasing -fno-common -dynamic -g -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -I/Library/Python/2.7/site-packages/numpy/core/include -I/usr/local/Cellar/pcl/HEAD/include/pcl-1.8 -I/usr/local/Cellar/eigen/3.2.3/include/eigen3 -I/usr/local/Cellar/pcl/HEAD/include/pcl-1.8 -I/usr/local/Cellar/flann/1.8.4/include -I/usr/local/Cellar/pcl/HEAD/include/pcl-1.8 -I/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c pcl/_pcl.cpp -o build/temp.macosx-10.6-intel-2.7/pcl/_pcl.o
pcl/_pcl.cpp:244:10: fatal error: 'boost/smart_ptr/shared_ptr.hpp' file not
found
#include "boost/smart_ptr/shared_ptr.hpp"
^
1 error generated.
error: command '/usr/bin/clang'
For whatever reason clang isn't looking in /usr/local/include where it most definitely would find the boost headers. As you can see it is linking all the other dependencies fine. What can I add that so clang will find boost?
On OSX 10.10, nothing fancy happening anywhere. Boost was probably installed by homebrew, but the files are all in /usr/local/include/boost as I'd expect.
Check the output of /usr/bin/clang++ -v some_test_file.cpp but chances are /usr/local/include isn't in the standard search path of the compiler.
You'll need to add -I/usr/local/include to CXXFLAGS or CPPFLAGS or whatever appropriate place in your build script or environment. It seems the python build script is failing to properly detect Boost.
If the above is not true (and /usr/local/include does show up in the output), make sure /usr/local/include/boost/smart_ptr/shared_ptr.hpp exists.
Running the build script from ELLCC results in this error
gcc -DHAVE_CONFIG_H -I. -I../../../src/binutils/binutils -I. -I../../../src/binutils/binutils -I../bfd -I../../../src/binutils/binutils/../bfd -I../../../src/binutils/binutils/../include -I./../intl -DLOCALEDIR="\"/Library/Caches/Homebrew/ellcc--svn-HEAD/lib/share/locale\"" -Dbin_dummy_emulation=bin_vanilla_emulation -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -Wno-unused-value -Wno-shadow -MT nm.o -MD -MP -MF .deps/nm.Tpo -c -o nm.o ../../../src/binutils/binutils/nm.c
../../../src/binutils/binutils/nm.c:1690:28: error: 'sbrk' is deprecated
[-Werror,-Wdeprecated-declarations]
char *lim = (char *) sbrk (0);
^
/usr/include/unistd.h:582:7: note: 'sbrk' declared here
void *sbrk(int);
^
The following compilers have been used with the same result:
gcc 4.8
llvm-gcc 2.8
llvm 3.3
I had the same issue compiling binutils-2.24 on Mac OSX Mavericks 13.2.0 with clang. Thanks to Richard Pennington's suggestion, I was able to get binutils to compile by specifying a few other -Wno-error arguments to gcc by setting CFLAGS before running configure. Namely, these are the commands I ran to build and install binutils:
CFLAGS="-Wno-error=deprecated-declarations -Wno-error=unused-variable -Wno-error=unused-function" ./configure --prefix=/usr/local/toolchain-arm-linux-elf --target=arm-linux-elf
make
make install
EDIT: I just noticed that the binutils configure script accepts an --disable-werror argument, which disables gcc turning warnings into errors, and removes the need for the settings CFLAGS. With this argument, building could be done as follows:
./configure --prefix=/usr/local/toolchain-arm-linux-elf --target=arm-linux-elf --disable-werror
make
make install
This error is occurring because sbrk() is deprecated on OSX, -Werror is enabled for the binutils build, and the compiler (in this case "gcc" is an alias for clang) rightly complains about the use of sbrk(). I'll be looking into eliminating this error this weekend when I won't have to be at my day job. ;-)
I looked into it a bit more. This happened because the latest version of OS X (Mavericks) uses clang as its compiler and /usr/include/unistd.h has a deprecated declaration of sbrk().
The solution was to add a -Wno-error=deprecated-declarations option to the CFLAGS for binutils. I also had to make a few other changes to complete the Max OS build. You can find the latest stuff in the ELLCC subversion tree.