To compile my own gcc, I require gmp. Therefore, I downloaded a tarball of gmp, and installed it by the usual steps of configure, make and make install. However, afterwards, I can't see any gmp in my system by typing 'which gmp'. So my question is where is gmp hidden? I am using CentOS 5.6.
EDIT
OK, I can see the header and library files of gmp in /usr/local/include and /usr/local/lib. I used --with-gmp-include=/usr/local/include --with-gmp-lib=/usr/local/lib but the gcc's configure still complains about not finding gmp. What is going on here?
Try to change
-–with-gmp=
to
-–with-gmp-prefix=
Thanks to doober
I think you should run ./configure script with some params:
./configure --prefix=/usr
default prefix is /usr/local
and if your system is 64-bit:
./configure --prefix=/usr --libdir=/usr/lib64
After that 'make && make install' should install everything in proper locations.
You're right that you need --with-gmp-xxx switches.
You may also need to set to set run-path to /usr/local/lib or wherever you install gmp if it's not in the default runtime linker locations:
$ export LD_RUN_PATH=/usr/local/lib
$ configure ...
$ make ...
The crucial point here that is only mentioned in one passing comment (by #Mat) is that gmp is a library. It is not a binary. So the resource that is produced is a bunch of libgmp* files in $prefix/lib.
There is no $prefix/bin/gmp...
Related
I am trying to compile GCC for i586-elf but every time I run the 'configure' file with this command:
./configure --target=$TARGET --prefix=$PREFIX --disable-nls --enable
languages=c --without-headers --with-gmp=$PREFIX --with-mpc=$PREFIX
--with-mpfr=$PREFIX
Then it gives me this error:
checking for the correct version of gmp.h... yes
checking for the correct version of mpfr.h... yes
checking for the correct version of mpc.h... yes
checking for the correct version of the gmp/mpfr/mpc libraries... no.
Although I have specified where gmp, mpfr, and mpc are located. And I have the latest versions of them. Is there anything I am missing?
Unless you really care about specific gmp/mpfr etc versions I suggest you run the contrib/download_prerequisites script from the top-level GCC source directory and then omit the --with-gmp=$PREFIX --with-mpc=$PREFIX --with-mpfr=$PREFIX from your configure line. The download_prerequisites script will download and unpack the right versions of the libraries that your GCC version needs and it will create the right symlinks in the right places
I am building a package with CMake (3.0.2). This package relies on boost_python and some others. There is an older version in /usr/lib64 and I have another newer version in my own directory /home/x/opt/boost-1.56/lib. There is an symbol link /home/x/opt/boost-1.56/lib64 to deal with the multi-arch gcc.
However, even if I set BOOST_ROOT=/home/x/opt/boost-1.56/lib, and in CMakeCache.txt there is
//Boost python library (release)
Boost_PYTHON_LIBRARY_RELEASE:FILEPATH=/home/x/opt/boost-1.56/lib/libboost_python.a
The generated link.txt contains such a line, instead of the full path:
-Wl,-Bstatic -lboost_python
And when make, it links to the one under /usr/lib64/, which is wrong.
Question:
How to make CMake to use the full path? As documented, only when libraries under system default folders are dealt with -Bstatic, which should not be my case.
Why -Wl,-Bstatic -lboost_python does not work even I have "/home/x/opt/boost-1.56/lib" in LD_LIBRARY_PATH and LIBRARY_PATH? From my limited knowledge they should override the system default.
Information:
gcc --print-search-dir gives:
/home/x/opt/boost-1.56/lib/x86_64-unknown-linux-gnu/4.9.2/
/home/x/opt/boost-1.56/lib/../lib64/
/lib/x86_64-unknown-linux-gnu/4.9.2/
/lib/../lib64/
/usr/lib/x86_64-unknown-linux-gnu/4.9.2/
/usr/lib/../lib64/
/home/x/opt/boost-1.56/lib/
/lib/
/usr/lib/
set(Boost_NO_SYSTEM_PATHS ON)
This will allow it to ignore everything but BOOST_ROOT
Solution (partially only):
CMake uses -Bstatic if there it thinks that the boost libraries it chooses are in the system path, including that related to enviromental variables. Else it use the full path.
I still cannot find why LIBRARY_PATH cannot override the system
So to make it work, REMOVE everything in LIBRARY_PATH and LD_LIBRARY_PATH will do the trick: CMake will use full path in that case.
Add this at the beginn oingf your top level CMakeLists.txt
cmake_minimum_required(VERSION 3.3)
and use cmake 3.3.0 or later.
Interestingly, with cmake 3.11.1 set(Boost_NO_SYSTEM_PATHS ON) did not work for me.
I am trying to build a cross compiler. I follow this tutorial: http://wiki.osdev.org/GCC_Cross-Compiler
I installed binutils in in /opt/cross. now I try to install gcc-4.7.4 with mpfr-2.4.2. I used commands to prepare and configure:
export PREFIX="$HOME/opt/cross"
export TARGET=i686-elf
export PATH="$PREFIX/bin:$PATH"
mv gmp-4.3.2 gcc-4.7.4/gmp
mv mpfr-2.4.2 gcc-4.7.4/mpfr
mv mpc-0.8.1 gcc-4.7.4/mpc
# i am in usr/src directory
mkdir build-gcc
cd build-gcc
../gcc-4.7.4/configure --target=$TARGET --prefix="$PREFIX" --disable-nls --enable-languages=c,c++ --without-headers
Now, i use make all-gcc to build, but I receive following error: configure: error: libmpfr not found or uses a different ABI (including static vs shared).
Why is this happening and how I can fix it?
Thanks!
You can check how "configure" checks if libmpfr is available (where configure looks for it) or just give the path to your libmpfr - with probably --enable-libmpfr=/path/ or something like this.
The second option is to give gcc configure option to disable using of mpfr (--disable-mpfr ?)
I assume that you are trying to compile gcc for another architecture than your host. Maybe gcc configure found libmpfr but it is mpfr from your host and not from your target architecture? You may take a look into config.log file if there is any and check which mpfr is using by configure.
Did you try to link libraries with export LD_LIBRARY_PATH=./gcc-4.7.4/mpfr/.libs
I compiled eglibc-2.11.3 on Debian squeeze, but do not see the libc-2.11.3.so. I believe that this is symlinked to from libc.so.6.
Not a c expert, so bear with me. These are the steps I took according to the included install file plus debian patch:
apt-get source libc6 # gets me eglibc-2.11.3
In build directory:
../configure --prefix=/usr
make -f ../debian/rules patch
make
I didn't see any errors before it gave me back the prompt, am I missing something?
do not see the libc-2.11.3.so
The library is linked as libc.so.6 (should be in the directory in which you executed make).
make install is what should create libc-2.11.3.so and a symlink libc.so.6 in the installation directory.
You may want to try make install PREFIX=/tmp/glibc-install and examine the resulting install tree, to make sure everything is where you expect it.
In debian/quiltrc change
QUILT_PATCH_OPTS="--unified-reject-files"
to become
QUILT_PATCH_OPTS="--reject-format=unified"
I've compiled clang to use it as a cross compiler for ARM (by configuring it with ./configure --target=armv7l-unknown-linux-gnueabihf ), but when I try to compile any C code, it tries to use /usr/bin/as. I already have binutils compiled for ARM, and they are in a separate directory. How do I direct clang (or llvm) to use the assembler that I specify?
try passing the --host option to configure which will cause all the cc ar etc utilities to prefix with armv7l-unknown-linux-gnueabihf-
eg:
./configure --host=armv7l-unknown-linux-gnueabihf --build=i686-unknown-linux-gnu
Since you are using configure with hopefully autotools take a look at:
automake Cross compiling
I've always had trouble configuring from the source directory using ./configure and gave up in the end. These days I always configure from a separate directory i.e. ..//configure although I'm told it's recommended to use an absolute path for configure.
Your ARM binutils should be installed in the same prefix you're using for clang and make sure that they're in the path when you configure & build clang - i.e. PATH=/some/prefix/bin:$PATH; /configure --target=armv7l-unknown-linux-gnueabihf. If you're keeping them in separate directories for packaging purposes then make install DESTDIR= should help.
I don't generally build clang but the buildscripts I use for devkitARM might be helpful - http://sourceforge.net/p/devkitpro/buildscripts/ci/c372699fc7b4de90eb044314ce5bed04db640291/tree/