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
Related
I am creating a C library which is to be built with cmake, using Mac OS for development. In the CMakeList.txt, I have the following
#htslib
find_package(htslib REQUIRED)
include_directories(${HTSLIB_INCLUDE_DIR})
target_link_libraries(projectname ${HTSlib_LIBRARIES})
which outputs upon cmake ..
Found hstlib
However, upon make, I'm getting linker errors:
clang: error: linker command failed with exit code 1 (use -v to see invocation)
So...it can find the library, and the library is definitely installed with sudo make install, but there are linking errors only with this library.
(1) I'm guessing that find_package(htslib REQUIRED) is finding something else. How do I find out what?
(2) How do I explicitly write in CMakeList.txt to find the library which I know has been installed correctly?
Use VERBOSE=1 make to see the linker output. Search for -lhtslib
Read the documentation for the specific Find<LIB>.cmake.
Your specific questions:
"How do I find what CMake found": Use cmake-gui or ccmake. They both show the same info, but one is a GUI and the other is a Curses interface. In the advanced mode ("t" on ccmake) you will find all the variables for the searched packages. Additionally, you may use MESSAGE(STATUS "Found htslib at: ${htslib_LIBRARIES}").
"How to explicitly write in CMakeLists.txt where the library is?" Please, do not do that! CMake is meant for abstracting exactly this kind of information away. You have two options, first the good one: configure cmake on the command line (or in the GUIs mentioned above) to get a CMAKE_MODULES_PATH or a more specific hint to the library -D htslib_PATH=/usr/local/.../ (pointing to the dir where libhts.dylib resides). The worse solution would be to provide a HINT to find_package. find_package(htslib REQUIRED PATH /usr/local/lib) or find_package(htslib REQUIRED HINT /usr/local/lib /some/second/path/where/it/may/be).
Solution
Your linked project has a custom FindHTSlib.cmake link. This one uses pkg_config to configure the library. To replicate your problem, I used brew to install htslib. The pkg-config file can be found (for me, but brew info htslib tells you) under /usr/local/Cellar/htslib/1.8/lib/htslib.pc. So, let's give CMake the required hint.
I couldn't test this, because for me it found the htslib package directly with no further hints.
git clone https://github.com/D-Lo/bamdb # I am using version f5f03d0
mkdir -p bamdb/build; cd bamdb/build
brew install ck htslib lmdb
cmake .. # -G Ninja recommended, but needs brew install ninja
make # lot's of missing symbols
I would recommend to change in CMakeLists.txt the minimum required version of CMake from 2.8 to 3.10 (or at least 3.6).
This is the error I get:
[ 62%] Linking C shared library libbamdb.dylib
/usr/local/Cellar/cmake/3.11.1/bin/cmake -E cmake_link_script CMakeFiles/libbamdb.dir/link.txt --verbose=1
/Library/Developer/CommandLineTools/usr/bin/cc -Wall -g -std=gnu99 -fPIC -dynamiclib -Wl,-headerpad_max_install_names -o libbamdb.dylib -install_name #rpath/libbamdb.dylib CMakeFiles/libbamdb.dir/src/bam_api.c.o CMakeFiles/libbamdb.dir/src/bam_lmdb.c.o CMakeFiles/libbamdb.dir/src/bamdb.c.o
Undefined symbols for architecture x86_64:
"_bam_destroy1", referenced from:
_get_bam_row in bam_api.c.o
_deserialize_func in bam_lmdb.c.o
This can be fixed by adding the following line in the CMakeLists.txt, after the line add_library(libbamdb ${SOURCES}):
target_link_libraries(libbamdb ${LIBS})
Some further notes: you now have a library with a main function. This is because ${SOURCES} is used to build the executable and the library. That can have unexpected side effects. Unless it's needed, don't do it.
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'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/
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...
My sysadmin recently installed a new version of GCC, in /lusr/opt/gcc-4.4.3. I tested it as follows:
mike#canon:~$ cat test.c
int main(){
return 0;
}
mike#canon:~$ gcc test.c
/lusr/opt/gcc-4.4.3/libexec/gcc/i686-pc-linux-gnu/4.4.3/cc1: error while loading shared libraries: libmpfr.so.1: cannot open shared object file: No such file or directory
After informing my sysadmin about this, he said to add /lusr/opt/mpfr-2.4.2/lib:/lusr/opt/gmp-4.3.2/lib to my LD_LIBRARY_PATH. After doing this, I get the following error:
mike#canon:~$ gcc test.c
cc1: error: unrecognized command line option "-L/lusr/opt/mpfr-2.4.2/lib"
First, my sysadmin wasn't entirely sure this was the best workaround(though he did say it worked for him...), so is there a better solution?
Second, why am I getting a linker error from cc, and how can I fix it?
Some information which may be helpful:
mike#canon:~$ env | grep mpfr
OLDPWD=/lusr/opt/mpfr-2.4.2/lib
LD_LIBRARY_PATH=/lusr/opt/mpfr-2.4.2/lib:/lusr/opt/gmp-4.3.2/lib:
mike#canon:~$ echo $LDFLAGS
(the above is a blank line)
I would suggest that your sysadmin needs to install the GMP and MPFR libraries from the build machine into the same location on your machine. (There's also the MPC library which you may also need.) Alternatively, your sysadmin needs to install a rebuild of GCC - preferably version 4.5.2 since that is (AFAIK) current - with the correct settings for where the GMP and MPFR libraries will be installed on your machine.
You shouldn't need to set LD_LIBRARY_PATH to use GCC. If you need to do so, it indicates that it was not built for the machine where it is running. Key libraries are missing.
To go further with your debugging, you probably need to use:
gcc -v test.c
This will show you the command lines executed. There is no call for the -L option (which affects the way programs are linked) to be passed to the phase 1 compiler.
This looks like some buggy argument parsing by gcc (it shouldn't complain about -Lfoo).
Can you try setting
LD_LIBRARY_PATH=\ /lusr/opt/mpfr-2.4.2/lib:/lusr/opt/gmp-4.3.2/lib
so that there's a leading space before that mpfr library path?