I am trying to cross compile libpng for RaspberryPi on Ubuntu 14.04 (x_64) with zlib
but configure fails with
configure:11400: arm-linux-gnueabihf-gcc -o conftest -g -O2 -I/home/user/RPI_DEV/lib/include conftest.c -lz -lm >&5
/home/user/RPI_DEV/xtools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian-x64/bin/../lib/gcc/arm-linux-gnueabihf/4.8.3/../../../../arm-linux-gnueabihf/bin/ld: cannot find -lz
collect2: error: ld returned 1 exit status
configure:11400: $? = 1
configure: failed program was:
....
Because I am using toolchain for arm, arm-ld cant find zlib.
Is there any option for configure not to compile with shared lib but to try with static lib (eg. -static -lz).
Command is
./configure --enable-static=true --enable-shared=false --with-zlib-include="/home/user/RPI_DEV/lib/include" --with-zlib-lib="/home/user/RPI_DEV/lib/lib" LDFLGS="-L/home/user/RPI_DEV/lib/lib" CPPFLAGS="-I/home/user/RPI_DEV/lib/include" -enable-static --host=arm-linux-gnueabihf --prefix=/home/user/RPI_DEV/lib --exec-prefix=/home/user/RPI_DEV/lib
You need to cross build and install zlib into your toolchain before trying to use it in another project.
What you are doing might work but only if you spell LDFLAGS correctly:
LDFLGS="-L/home/user/RPI_DEV/lib/lib"
Note the missing 'A'. I don't know why your second attempt worked, given you had the same misspelling; possibly you had a correct LDFLAGS in your environment?
Anyway there should be a Ubuntu cross-development guide somewhere that explains how to do this. It's slightly off topic but for Gentoo you use 'crossdev' to install the toolchain then a crossdev specific version of the normal package installation mechanism ([host]-emerge) to install zlib into the toolchain.
Also, the arguments --with-zlib-include and --with-zlib-lib are not supported by any current version of libpng I can find. If you are cross-compiling libpng for an RPi (or, indeed, any ARM system) you should be using the latest version of 1.6 that you can find.
Unless someone solves this the RIGHT way, this is hack I've done.
Open configure.ac file
Find and comment out line
AC_CHECK_LIB(z, zlibVersion, , AC_ERROR([zlib not installed]))
Configure will pass wihout check for zlib and then add zlib by hand
LDFLGS="-L/home/user/RPI_DEV/lib/lib -L/home/user/RPI_DEV/lib/lib/libz.a"
Run autoconf
Run ./configure ...
Related
the issue
I started a C project on my local Ubuntu machine. After I completed the first version(the building is ok), I decided to upload the code to a server which runs a CentOS 7 to implement more features.
The code and the makefiles are the same on both sides.
But the code building on the remote shows the error as follows:
/usr/bin/ld: cannot find -ldl
/usr/bin/ld: cannot find -lc
collect2: error: ld returned 1 exit status
building tools and environment
OS: centos7
toolchain : gcc
What I tried to fix this
yum install glibc-devel
But it did not work.
How should I fix this?
Edit , I got a workaround
I found the makefile I wrote a week ago is a little bit strange on LDFLAGS,
LDFLAGS += -L$(LIBPATH)
LDFLAGS += -static -lxxx -lyyy -ldl
xxx and yyy is the static library name I need to link.
I modified the makefile to
LDFLAGS += -L$(LIBPATH)
LDFLAGS += -l:libxxx.a -l:libyyy.a -ldl
Now it works fine.
-static requires the glibc-static package, not just glibc-devel. But static linking has many limitations (particularly in combination with dlopen), and you should avoid it if at all possible. (It is explicitly unsupported on Red Hat Enterprise Linux.)
I am currently trying to use Oracle Linux 6 OS on a SPARC S7 server to run the NPB benchmarks (with OpenMP multithreading support). The OS comes preloaded with gcc 4.4.7, which is missing the Niagara 7 optimizations. I downloaded devtoolset-3 from the Oracle Yum Repository, which has gcc 4.9.2 installed in /opt/rh/devtoolset-3/root/usr/bin. However, when I compile the NPB benchmark using the newer gcc, it automatically links to libraries associated with the older gcc 4.4.7 (located in /usr/lib). This caused my program to segfault during execution. I believe that it is because libgomp 4.4.7 is incompatible with libgomp 4.9.2. I have tried several ways of linking to the libraries in the gcc 4.9.2 folder (which is /opt/rh/devtoolset-3/root/usr/lib/gcc); none of the methods work:
-Xlinker -rpath=lib_location
-Wl -Bstatic
-L lib_location
The closest I got was when using -Wl -Bstatic ~/libgomp.a or -static -L ~/libgomp.a. It fails to find libraries such as libm that reside in the default gcc lib folder (usr/lib).
The actual command used to link is:
/opt/rh/devtoolset-3/root/usr/bin/gcc -O3 -fopenmp -mcmodel=medmid -static -L/opt/rh/devtoolset-3/root/usr/lib/gcc/sparc64-redhat-linux/4.9.2 -o ../bin/bt.W.x bt.o initialize.o exact_solution.o exact_rhs.o set_constants.o adi.o rhs.o x_solve.o y_solve.o solve_subs.o z_solve.o add.o error.o verify.o ../common/print_results.o ../common/c_timers.o ../common/wtime.o -lm -L/opt/rh/devtoolset-3/root/usr/lib/gcc/sparc64-redhat-linux/4.9.2/lib/
/opt/rh/devtoolset-3/root/usr/libexec/gcc/sparc64-redhat-linux/4.9.2/ld: cannot find -lm
/opt/rh/devtoolset-3/root/usr/libexec/gcc/sparc64-redhat-linux/4.9.2/ld: cannot find -lrt
/opt/rh/devtoolset-3/root/usr/libexec/gcc/sparc64-redhat-linux/4.9.2/ld: cannot find -lpthread
/opt/rh/devtoolset-3/root/usr/libexec/gcc/sparc64-redhat-linux/4.9.2/ld: cannot find -lc
Is there a way I can link just the libgomp library from gcc 4.9.2 while linking the remaining libraries from gcc 4.4.7?
The devtoolset compilers are all using the system libgcc, libstdc++, version 4.4.7, and can therefore not compile e.g. c++11.
I guess the gcc53-c++-5.3.0-1.el6.x86_64.rpm will do. Comes with the internal */gcc53/lib64{libgcc_s.so**, libgomp.so**, libstdc++} (version 5.3.0) ... Provides /usr/bin/{ gcc53, g++53 }
The package was created a year ago ... well tested, as extra compiler. Download link : https://drive.google.com/file/d/0B7S255p3kFXNbTBneHgwSzBodFE/view?usp=sharing
If you're going to do the -Wl,-Bstatic thing, make sure to follow it immediately by -Wl,-Bdynamic to reset to normal after your added library argument. By default, not all system libraries have static versions installed, which is why you get e.g. cannot find -lc.
So you can try this as a modification of your workaround:
-Wl,-Bstatic ~/libgomp.a -Wl,-Bdynamic
Not pretty, and this question deserves a much better answer (this is still pretty much a hack), but it should get the job done for now.
I'm trying to use clang++ as drop-in replacement for G++. I'm compiling for AArch64, but for linking, clang seems to invoke the native (x86) /usr/bin/ld instead of that from AArch64 GCC suite. The clang command line looks like:
clang++ -target aarch64-linux-gnu -v \
-gcc-toolchain /path/to/aarch64/gcc \
--sysroot=/path/to/aarch64/gcc/aarch64-linux-gnu/libc \
<some other options> <obj files>
And from the verbose output, I get:
Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4)
Target: aarch64--linux-gnu
Thread model: posix
Found candidate GCC installation: /path/to/aarch64/gcc/lib/gcc/aarch64-linux-gnu/4.9.3
Selected GCC installation: /path/to/aarch64/gcc/lib/gcc/aarch64-linux-gnu/4.9.3
"/usr/bin/ld" --sysroot=/path/to/aarch64/gcc/aarch64-linux-gnu/libc ...
I don't get why clang got around choosing the native linker. The link fails for obvious reasons that object files are AArch64 ELF. Compilation lines similar to the above, but they go OK.
Any thoughts?
PS: I'm a novice clang user
I managed to find a solution: GCC accepts -B option to point to the search path where it'd try to locate the utilities. It turns out--although not documented--that clang too accepts this option. For me, having -B point to AArch64 binutils solved the problem. Another suggestion was to add the AArch64 binutils in $PATH.
I'm trying to build a package on lauchpad. For it to build I need to set a static path using the LDADD variable in automake:
relay_LDADD = /usr/lib/x86_64-linux-gnu/libm.so /usr/lib/x86_64-linux-gnu/libX11.so.6 $(RELAY_LIBS)
This compiles on the 64 bit build but fails on the 32 bit build. I tried using PKG_CHECK_MODULES but it says
No package 'm' found
No package 'X11' found
Consider adjusting the PKG_CONFIG_PATH environment variable if you
installed software in a non-standard prefix.
I know it not a non standard path since launchpad is doing the building? How can I get this to work?
The build failed without the libraries specified even though the package specifies them in the build-requires.
You have tried to outwit the buid-system, and it has outwitted you.
It's generally a bad idea to hard-code paths.
Debian (and ubuntu is just a derivative), has started to ship binaries (like libraries) in architecture-dependent directories, to allow installations for multiple architectures on a single system.
These libraries are installed into /usr/lib/<host-triplet>, where <host-triplet> depends on the architecture; e.g. x86_64-linux-gnu is the amd64 architecture for systems with a linux and the gnu tools.
a 32bit system would typically have a host-triplet of i386-linux-gnu.
Since you are hard-coding the library path to a 64bit location( /usr/lib/x86_64-linux-gnu/libm.so) this fails on all systems but 64bit/linux/gnu.
Instead you should just tell the linker to link against the m library (libm), resp the X11 library (libX11).
Let the linker care for the correct architecture to pick:
relay_LDADD = -lm -lX11 $(RELAY_LIBS)
In general, if you want to link against a library foo, that provides a library-file libfoo.so you would use -lfoo (stripping away the leading lib and the trailing .so).
However, sometimes this is not enough; in those cases your library might use pkg-config to provide the full CFLAGS and LDFLAGS needed to compile/link against this library.
e.g. if I want to use libquicktime:
$ pkg-config --cflags libquicktime
-I/usr/include/lqt
$ pkg-config --libs libquicktime
-lquicktime -lpthread -lm -lz -ldl
So I would use something like:
myprog_CFLAGS += $(shell pkg-config --cflags libquicktime)
myprog_LDADD += $(shell pkg-config --libs libquicktime)
That would work in any GNU(?) Makefile (not related to autotools).
In an autotools project, you would probably move the pkg-config check into configure, using the m4-macro PKG_CHECK_MODULES
I'm not a linux expert but I'm running into the following problem which I hope to get solved here. My system has gcc 4.4 and I had to install an older version of gcc (gcc 4.2) on my home space so I can build a simulation tool.
Anyway, everything went well and I was able to build the tool.
However, when I now try to link statically using '-static' gcc option I get errors such as:
/usr/local/bin/ld: cannot find -lm
/usr/local/bin/ld: cannot find -lc
collect2: ld returned 1 exit status
I installed the dev package for glibc using (assuming the static version of the libraries will be installed)
$ yum install glibc-devel glibc-static
But I still get the errors.
I don't know where to go from here.
By the way, I added the local version of gcc (ie gcc 4.2) to PATH and the libs to the LD_LIBRARY_PATH and LIBRARY_PATH.
Do I need to get glibc and install it locally too, if so which version should I get?
Thanks