I am trying to add alsa library to my Eclipse in order to cross-compile and debug in my iMX8X.
I have cross compiled the alsa-lib by
./configure --host=aarch64-unknown-linux-gnu --with-pcap=linux
I have added the library path where my libasound.so is in properties-> Cross GCC Linker -> libraries (search path), in my case /usr/lib, this is built
aarch64-linux-gnu-gcc -pthread -L/usr/lib -lasound -o "test1.elf" ./src/test1.o
but this error appears in my console and I dont know how to fix it,
/usr/lib/gcc-cross/aarch64-linux-gnu/9/../../../../aarch64-linux-gnu/bin/ld: no se puede encontrar -lasound
Should I try to compile alsa-utils, firmware, ...?
Or how can I debug this in order to use alsa snd_pcm functions?
Do I have to add some more files to the library definition?(like libasound.la or libasound.a)
Thanks in advance.
I have created an Ubuntu 20.04 Virtual Box image, compiled there alsa-lib, alsa-utils and alsa-tools libraries. I installed eclipse and link all the libraries in my linker. I managed to compile it by adding -L/usr/lib and -lasound again, deleting the previous one. Make sure where the compilation of your library is and link it in the Cross GCC Linker -> Libraries in a path, which in my case was /usr/lib. No idea why the previous one didnt work.
Related
Question
I want to override/clear g++ default search path for libraries, so that g++ does only search libraries under paths explicitly specified:
$ arm-linux-gnueabihf-g++ --print-search-dirs | grep libraries:
libraries: =/usr/lib/gcc-cross/arm-linux-gnueabihf/6/:/usr/lib/gcc-cross/arm-lin
ux-gnueabihf/6/../../../../arm-linux-gnueabihf/lib/arm-linux-gnueabihf/6/:/usr/l
ib/gcc-cross/arm-linux-gnueabihf/6/../../../../arm-linux-gnueabihf/lib/arm-linux
-gnueabihf/:/usr/lib/gcc-cross/arm-linux-gnueabihf/6/../../../../arm-linux-gnuea
bihf/lib/../lib/:/lib/arm-linux-gnueabihf/6/:/lib/arm-linux-gnueabihf/:/lib/../l
ib/:/usr/lib/arm-linux-gnueabihf/6/:/usr/lib/arm-linux-gnueabihf/:/usr/lib/../li
b/:/usr/lib/gcc-cross/arm-linux-gnueabihf/6/../../../../arm-linux-gnueabihf/lib/
:/lib/:/usr/lib/
Can this be done?
Background
I'm on Ubuntu 17.04 compiling c++ code for several cross-platform distributions.
I've installed Ubuntu g++-arm-linux-gnueabihf package, and created a target image under /opt/jessie_root, in this case for Jessie armhf. I also fixed all the links under this jessie_root image to be relative and not absolute.
I want to compile dynamic executables with the target rootfs libraries.
Initially I was compiling "fine" but I realized that I was linking to symbols on the host cross-toolchain libstdc++.
I'm using cmake, but for simplicity consider this commands:
/usr/bin/arm-linux-gnueabihf-g++ main.c
This will link to the host libstdc++ under /usr/lib/gcc-cross/arm-linux-gnueabihf/6/libstdc++.so, which is not desirable.
/usr/bin/arm-linux-gnueabihf-g++ main.cpp --sysroot=/opt/jessie_root -L=/usr/lib/gcc/arm-linux-gnueabihf/4.9 -D_GLIBCXX_USE_CXX11_ABI=0
This will link correctly to the target libstdc++ under /opt/jessie_root/usr/lib/gcc/arm-linux-gnueabihf/4.9/libstdc++.so, which I want.
The issue is that this seems a disaster waiting to happen, as if one of the default libs are not found on the target, the compiler will haply take one from the host cross-toolchain.
I could remove or rename them, but I don't want to mess on /usr/.
I have also played with GCC -nostdlib and LD -nostdlib, which seem to have different meanings. GCC -nostdlib is for libraries, and LD -nostdlib is for the search directories. LD -nostdlib have no effect, and GCC -nostdlib just forces me to specify the libraries manually, but it still keeps the search paths.
Naturally I could use another toolchain/compile my own, but I would prefer to stay on the packaged toolchain.
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 am trying to write a single CMakeLists.txt file for C++ compilation on Linux with G++ and on OSX with Clang.
I want to use the Target Library flags -Wl,--start-group and -Wl,--end-group with G++, but these give an error when linking with Clang: ld: unknown option: --start-group
The only results I can find choose to just delete these flags on Mac copies, but that doesn't allow easy project migration from linux to OSX. I tried to make these statements CMAKE conditions, but those are treated as literal libraries which are not found:
eg: $<IF($<NOT:APPLE>)> -Wl,--start-group $<ENDIF($<NOT:APPLE>)>
produces: c++: error: $<IF: No such file or directory
Is there a way to conditionally edit in the CMAKE TARGET_LINK_LIBRARIES field?
I'd try this:
if(${CMAKE_CXX_COMPILER_ID} STREQUAL "GNU")
set(START_GROUP "-Wl,--start-group")
set(END_GROUP "-Wl,--end-group")
else()
set(START_GROUP "")
set(END_GROUP "")
endif()
Then just replace those options with ${START_GROUP} and ${END_GROUP}, and they will only be used with the GNU compiler.
Don't switch based on platform if it's really the compiler that matters. Otherwise, Clang users on Linux won't be able to build your project.
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 ...
I am trying to compile an existing QT library with QT5.1 Beta on Ubuntu 12.04 with Clang.
This project compiles fine with QT4.8.4.
I am getting the below linker error when I compile the project with QT5.1 Beta.
/usr/bin/ld: cannot find -lQt5OpenGL
/usr/bin/ld: cannot find -lQt5Widgets
/usr/bin/ld: cannot find -lQt5Network
/usr/bin/ld: cannot find -lQt5Gui
/usr/bin/ld: cannot find -lQt5Core
My current system setup is as follows:
Installed the 64 bit linux pre-built package of QT5.1 Beta on my home directory
Added Qt5.1 qmake bin directory to PATH environment variable
Added QT5.1 lib directory to LD_LIBRARY_PATH
Installed Clang 3.3 and libc++
In QT Creator added a Kit with QT5.1 and Clang and built the project using this kit
I am getting the error on both launching the qtcreator from icon and bash.
The developer who was using this ubuntu system before had installed QT4 using apt-get.
I think QT4 got installed in the default OS directories and QT4 gets picked up always rather than QT5 when I build my project. I removed the QT4 packages that were under /usr/** path
When the build fails ,I see the below command being executed in qtcreator's compiler output window.
clang++ debug/moc-xxx.o -L -L/home/user/Qt5.1.0/5.1.0-beta1/gcc_64/lib -lQ5OpenGL -lQt5Widgets -lQt5Network -lQt5Gui -lGL -lpthread
Does the -L with no path tell the compiler to use the libs from the system's default paths?
What am I missing here?
You need to compile Qt with Clang first (Clang-3.2 example):
http://libre.tibirna.org/projects/qgit/wiki/Compile_Qt5_with_clang
because pre-built Linux Qt libraries are for gcc.
After building Qt you can configure the Kit for Qt Creator:
http://libre.tibirna.org/projects/qgit/wiki/Compile_QGit_with_Qt5_and_clang