I'm unable to execute a C program on my ARM Cortex A7 running buildroot.
After executing I get this error:
./mcp23017
Could not open file (1): No such file or directory
After searching I found out that I'm missing the correct interpreter on my buildroot.
#cd /lib
ls
dhcpcd
libform.so libncurses.so.6.0
ld-uClibc-1.0.28.so libform.so.6 libpanel.so
ld-uClibc.so.0 libform.so.6.0 libpanel.so.6
ld-uClibc.so.1 libgcc_s.so libpanel.so.6.0
libatomic.so libgcc_s.so.1 libuClibc-1.0.28.so
libatomic.so.1 libmagic.so libz.so
libatomic.so.1.2.0 libmagic.so.1 libz.so.1
libc.so.0 libmagic.so.1.0.0 libz.so.1.2.11
libc.so.1 libmenu.so modules
libcurl.so libmenu.so.6 os-release
libcurl.so.4 libmenu.so.6.0 terminfo
libcurl.so.4.5.0 libncurses.so
libcurses.so libncurses.so.6
I'm really stuck, could you tell me how I can cross compile with uclibc on my i386 laptop?
Or do I have other options?
You must build your program with the cross-compiler provided by Buildroot, so that it uses the libraries matching the ones available on your ARM target. The compiler is host/bin/arm-linux-gcc.
Related
I've started a fresh C project with CLion and wanted to use MPI. Since I am on Windows, I installed MS-MPI (the MSMPI and the SDK), and have my CMakeLists.txt as follows:
cmake_minimum_required(VERSION 3.10)
project(ppc)
set(CMAKE_C_STANDARD 11)
find_package(MPI REQUIRED)
add_executable(ppc main.c)
target_link_libraries(main PRIVATE MPI::MPI_C)
The problem is that whenever I try to import/reload the project, I get the following error:
C:\Users\frani\AppData\Local\JetBrains\CLion2020.2\cygwin_cmake\bin\cmake.exe -DCMAKE_BUILD_TYPE=Debug -DCMAKE_MAKE_PROGRAM=/usr/bin/make.exe -DCMAKE_CXX_COMPILER=/usr/bin/g++.exe -G "CodeBlocks - Unix Makefiles" /cygdrive/d/Dev/CLionProjects/ppc
-- Could NOT find MPI_C (missing: MPI_C_LIB_NAMES MPI_C_HEADER_DIR MPI_C_WORKS)
-- Could NOT find MPI_CXX (missing: MPI_CXX_LIB_NAMES MPI_CXX_HEADER_DIR MPI_CXX_WORKS)
CMake Error at /cygdrive/c/Users/frani/AppData/Local/JetBrains/CLion2020.2/cygwin_cmake/share/cmake-3.17.3/Modules/FindPackageHandleStandardArgs.cmake:164 (message):
Could NOT find MPI (missing: MPI_C_FOUND MPI_CXX_FOUND)
Reason given by package: MPI component 'Fortran' was requested, but language Fortran is not enabled.
Call Stack (most recent call first):
/cygdrive/c/Users/frani/AppData/Local/JetBrains/CLion2020.2/cygwin_cmake/share/cmake-3.17.3/Modules/FindPackageHandleStandardArgs.cmake:445 (_FPHSA_FAILURE_MESSAGE)
/cygdrive/c/Users/frani/AppData/Local/JetBrains/CLion2020.2/cygwin_cmake/share/cmake-3.17.3/Modules/FindMPI.cmake:1717 (find_package_handle_standard_args)
CMakeLists.txt:6 (find_package)
-- Configuring incomplete, errors occurred!
See also "/cygdrive/d/Dev/CLionProjects/ppc/cmake-build-debug/CMakeFiles/CMakeOutput.log".
See also "/cygdrive/d/Dev/CLionProjects/ppc/cmake-build-debug/CMakeFiles/CMakeError.log".
[Finished]
What is wrong with my file?
Try to add this after your project declaration:
enable_language(Fortran)
(https://cmake.org/cmake/help/latest/command/enable_language.html)
I have a C library which is created with
cc -fPIC -g -O3 -c -o obj/my_lib.o my_lib.c
g++ -shared -Wl,-soname,libmy_lib.so.1 obj/my_lib.o -o libmy_lib.so.1.8.0
This library is packaged into debian packages with dpkg-buildpackage producing libmy_lib1-1.deb, libmy_lib1-dev-1.deb, and libmy_lib1-dbgsym-1.ddeb. Installing all of those packages, I can then compile/link a simple test program that calls into the library. This works. Running the test program works.
However, when I run GDB on the test program (on the same computer), I see
gdb$ break main
Breakpoint 1 at 0x87e: file test.c, line 10.
gdb$ info sharedlibrary
No shared libraries loaded at this time.
gdb$ r
Starting program: /tmp/a.out
Breakpoint 1, main () at test.c:10
10 my_library_func();
gdb$ info sharedlibrary
From To Syms Read Shared Object Library
0x00007ffff7dd5f10 0x00007ffff7df4b20 Yes /lib64/ld-linux-x86-64.so.2
0x00007ffff7bac9a0 0x00007ffff7bad438 Yes /usr/lib/x86_64-linux-gnu/libmy_lib.so.1
0x00007ffff74532d0 0x00007ffff75cbc3c Yes /lib/x86_64-linux-gnu/libc.so.6
0x00007ffff709fa80 0x00007ffff715e2f5 Yes /lib/x86_64-linux-gnu/libm.so.6
0x00007ffff6e7eac0 0x00007ffff6e8f36d Yes /lib/x86_64-linux-gnu/libgcc_s.so.1
(*): Shared library is missing debugging information.
gdb$ s
my_library_func () at my_lib.c:299
299 my_lib.c: No such file or directory.
As you can see, GDB knows about the debug symbols for the library. However, it does not know about the source file for the library. How should I running GDB to it can resolve the C source code?
You need to also tell gdb where the source files are. Which means you also need the source files, not just the debugging symbols.
It's important that the sources you download are the actual ones used to compile the library, because debugging information only contains filename and line number. If you give gdb a file where the line numbers don't correspond (a different version, for example), the source lines printed by gdb will be very confusing. It has no way to know they are wrong. You should be able to use the src deb with the same version number as the library debs.
Once you have the source files, tell gdb where to look for them with
directory /path/to/source/files
You can specify several paths. Read help directory inside gdb.
Since you'll need to do this often, put that line into a gdbinit file. You'll probably want to use .gdbinit in your current directory, but .gdbinit in your home directory might also be a possibility. Gdb uses both.
If you're working with a library whose source is spread over a subdirectory tree, you might find it useful to set a substitution path:
set substitute-path /your/file/path /original/file/path
Again, more help is available with help set substitute-path.
GDB searches a number of default directory paths to locate the specified sourcefile. You can add paths using the directory command: https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html
I am trying to run a c code on my Windows laptop using the 64-bit MinGW compiler. There are a few lines in the beginning of the code that direct to other files such as:
#include <openssl/e_os2.h>
When compiling the code the following error shows up:
C:\MinGW\bin\openssl\apps>gcc s_server.c
s_server.c:21:27: fatal error: openssl/e_os2.h: No such file or directory
#include <openssl/e_os2.h>
^
compilation terminated.
I made sure the files were in the correct locations, however the error still occurs. I am thinking the error occurs because I am running a 32-bit binary on a 64-bit system. Are there any ways to work around this issue given that I don't have a Linux system?
C:\MinGW\bin\openssl\apps>gcc s_server.c
s_server.c:21:27: fatal error: openssl/e_os2.h: No such file or directory
#include <openssl/e_os2.h>
^
compilation terminated.
I believe you need a -I argument during compile. The headers are not located in the apps/ directory. Instead, they are located at ../include/ (relative to apps/).
So maybe a compile command like:
# from apps/ directory
gcc -I ../include/ s_server.c
You will probably have additional problems because you need to link against libssl and libcrypto. Be aware you will still have work to do.
Here is what it looks like on Linux:
openssl$ find . -name e_os2.h
./include/openssl/e_os2.h
openssl$ cd apps
apps$ ls ../include/openssl/e_os2.h
../include/openssl/e_os2.h
Since the relative path is ../include/openssl/e_os2.h and the source file #include "openssl/e_os2.h", you only need to include ../include using -I.
I am running a 32-bit binary on a 64-bit system...
You need to build OpenSSL as 32-bit. Run ./Configure LIST to get a list of MinGW targets. Then, configure with the appropriate triplet.
You may need to add -m32 to the command line for your program.
I am trying to use the Intel MKL libraries for the first time. I am using CMake to build a simple project in which MKL is used. I work in the KDevelop 4.6 environment.
The project is built and installed without errors. Linking the libraries is thus succesful. While executing within KDevelop, I get the following error:
Error while loading shared libraries: libmkl_intel_lp64.so: cannot open shared object file: No such file or directory
The CMakeLists file looks essentially as follows:
project(testmkl)
cmake_minimum_required(VERSION 2.6)
enable_language(Fortran)
set(CMAKE_C_FLAGS "-std=c99 -Wall -lpthread")
set(CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake")
# MKL
find_package(MKL REQUIRED)
include_directories(${MKL_INCLUDE_DIR})
find_package(M REQUIRED)
include_directories(${M_INCLUDES})
add_executable(testmkl ./main.c)
target_link_libraries(testmkl ${M_LIBRARIES} ${MKL_BLAS} ${MKL_LAPACK} ${MKL_INTEL} ${MKL_SEQUENTIAL} ${MKL_CORE})
install(TARGETS testmkl DESTINATION .)
libmkl_intel_lp64.so is found in the first folder of the LP_LIBRARY_PATH environment variable, so I wouldn't expect any error during the execution. Actually, when running the program from the command window, everything seems to work fine.
The ldd output for the executable is:
>> ldd ./testmkl
linux-vdso.so.1 => (0x00007fff951fe000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003061a00000)
libm.so.6 => /lib64/libm.so.6 (0x0000003061200000)
libmkl_intel_lp64.so => /opt/intel/composer_xe_2013_sp1.0.080/mkl/lib/intel64/libmkl_intel_lp64.so (0x00007f6f65ef6000)
libmkl_sequential.so => /opt/intel/composer_xe_2013_sp1.0.080/mkl/lib/intel64/libmkl_sequential.so (0x00007f6f65846000)
libmkl_core.so => /opt/intel/composer_xe_2013_sp1.0.080/mkl/lib/intel64/libmkl_core.so (0x00007f6f64317000)
libc.so.6 => /lib64/libc.so.6 (0x0000003060e00000)
/lib64/ld-linux-x86-64.so.2 (0x0000003060600000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003061600000)
The linked libraries are thus correctly found. Why won't the program work in the KDevelop environment?
Any help is welcome, thanks!
First one short question: are you excuting your program from a terminal or trying to execute from KDE gui (e.g. by double-click)?
On many linux OS, now LD_LIBRARY_PATH is deprecated. LD finds the dependencies thanks to what is listed in /etc/ld.so.conf and /etc/ld.so.conf.d . You may have to add a script somewhere there to include your libraries. In fact you just have to add the path to your libraries in those scripts.
example from /etc/ld.so.conf/libc.conf:
# libc default configuration
/usr/local/lib
This may work for you.
edit:
you shoud also run ldconfig to update the LD database and/or use ldconfig -v, which does the same but with extended output
edit2: ldconfig may require root privileges to be understood by the GUI
I had the same problem and now it solved through configuration of environment variable in kdevelop.
Go to project->open configuration
Select make tab
Click setting icon in Active environment profile bar and add your environment variable:
LD_LIBRARY_PATH = /your/shared/library/path
I built the latest glibc and now i'm having some trouble with functions in coreutils like ls or cat or anything else like vim.
My error is
-bash-4.0$ cat
cat: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): Invalid argument
and I built, glibc without errors with the following configure
../glibc/configure --prefix=/home/ex/uid377/glibbuilt
On older versions, like 2.14, running the utilities results in a segmentation fault.
-bash-4.0$ ./pwd
./pwd: /lib64/libc.so.6: version `GLIBC_2.14' not found (required by ./pwd)
-bash-4.0$ LD_LIBRARY_PATH=/home/ex/uid377/glibc/lib/:${LD_LIBRARY_PATH}
-bash-4.0$ ./pwd
Segmentation fault (core dumped)
Edit
Kernel Version
-bash-4.0$ uname -r
2.6.32.26-175.fc12.x86_64
Having multiple versions of glibc on a single system is possible, but slightly tricky, as explained in this answer. In particular, this:
LD_LIBRARY_PATH=/home/ex/uid377/glibc/lib/:${LD_LIBRARY_PATH}
is expected to crash, because your ld-linux-x86-64.so.2 will not match your libc.so.6
cat: error while loading shared libraries: __vdso_time: invalid mode for dlopen(): ...
It's not clear how you built this cat, but it's most likely the exact same problem: you are picking some libraries from /lib64, and some from /home/ex/uid377/glibc/lib. Don't do that. You must link all the programs that will use /home/ex/uid377/glibc/lib/libc.so.6 with -Wl,--dynamic-linker=/home/ex/uid377/glibc/lib/ld-linux-x86-64.so.2.
You can trace which libraries are currently being loaded by running:
env LD_DEBUG=files,libs ./cat