I'm running Linux on spike as described at: http://riscv.org/download.html#tab_linux. With busybox I have a powerful tool to run several usefull tools. The next thing I am trying to achieve, is to run my own program on riscv/Linux. Therefore I wrote a little program:
#include <stdio.h>
int main(void) {
printf("Hello world!\n");
return 0; }
compiled it with riscv64-unknown-linux-gnu-gcc and added the binary to the root.img of riscv/Linux. The Problem I now have is, that if I want to execute the program under riscv/Linux threw ./hello, the following message appears on my shell:
-/bin/ash: ./hello: not found
My Question now is (1) what am I doing wrong and (2) is there at all a possibility to run a program on riscv/Linux the way I am trying accomplish it?
My guess is that your hello program is dynamically linked to a runtime library that is missing from your root file system.
You can use 'ldd' to find which dynamic libraries your application is linked with and make sure all of them are present on the root file system or simply compile the hello program statically.
Related
I'm trying to cross-compile from WSL and Linux to Win32 using i686-w64-mingw32-gcc. The program is dependent on some DLL:s that I have downloaded, and are known to work when used for an exe cross-compiled on Cygwin. Compilation and linking works without throwing any errors or warnings, but when I run the resulting executable on Windows (by double-clicking on it in an Explorer window) I get a Windows-error-prompt:
The procedure entry point DeleteCriticalSection could not be located in the DLL...
and then it points to the program (the .exe) itself, not a DLL (message translated from Swedish ;-).
When I do the exact same thing on Cygwin with the same archive for the DLL:s and the same DLL:s the resulting exe works as it should.
The new(ish) Dependencies shows some red lines for COMCTL32 and OLEAUT32, but those are the same for both.
A very simple windows GUI app compiles and runs, so it's not the cross-compile as such that is causing the issue. The DLL:s in combination with WSL/Ubuntu/GNU cross-compilation seems to be the culprit.
Instructions
EDIT: after explicitly following my own instructions and explicitly re-installing the cross-compilation tool-chain the instructions below no longer creates a faulty exe. But the original problem remains.
I'm happy to take any ideas on what to try next.
Here are instructions to repeat what I have. Create an empty directory in WSL and run
$ sudo apt install binutils-mingw-w64-i686 gcc-mingw-w64-i686
$ wget https://github.com/DavidKinder/Windows-Glk/releases/download/1.50/WindowsGlk-150.zip
$ unzip WindowsGlk-150.zip
Then create startup.c with the following content
#include <unistd.h>
#include "glk.h"
#include "WinGlk.h"
int winglk_startup_code(const char* cmdline)
{
return 1;
}
void glk_main(void) {
sleep(10);
}
(Fix the capitalized include of "glk.h" in Glk.c or you'll get an error.)
Compile and link with
$ i686-w64-mingw32-gcc -mwindows -I Include/ Glk.c startup.c Glk.lib
to get an a.exe. The message only shows up in Gui-mode so you need to run it from an explorer window:
explorer.exe .
and double-click on a.exe.
WSL and Linux vs. Cygwin
I've done the same cross-compilation on a "real" Ubuntu 20.04 and getting the same problem. Again, doing the exact same steps in Cygwin produces a runable exe. This points to a cross-compilation problem with some facet of
what the exe and the DLL:s are doing. (There is no code in the exe that does anything with critical sections. Could this be an API mismatch?)
Since the DLL:s are the same it is reasonable to suspect the actual cross-compilation of sources in my program.
Is there anything in the cross-compilation toolchain on Linux that might differ? Which Windows run-times and API-versions are targeted?
I'm happy to take any ideas on what to try next.
I have an executable provided as is. The creators have compiled it with minimal dependencies and no symbols. When I load it in gdb it sais:
...(no debugging symbols found)...done.
I would like to do step-by-step debugging in the assembler code with the optional exit point in case the execution does leave the shared executable. The reason I need this is because I have an executable which segfaults and I have no other means of tackling the problem.
I have created a minimalist example (simple.c++):
#include <stdlib.h>
#include <iostream>
int main () {
std::cout << "Hello World!" << std::endl;
return EXIT_SUCCESS;
}
and compile it with:
g++ -static -O3 simple.c++ -o simple
strip simple
Thank You in Advance.
I would like to do step-by-step debugging in the assembler code
What is stopping you from doing just that?
readelf -h a.out will tell you what address the start is at. Set a breakpoint there and continue with stepi or nexti.
This will actually take a really long time, so a more efficient approach might be go backwards from the crash point, rather than forward from start. That is, run the binary until crash point, then figure out how you got there, set a breakpoint earlier, and re-run. Reverse debugging may also help.
i am trying to know the size of task_struct. thus i have downloaded the linux source code from the website and i have generated the head files via typing the command make headers_install into terminal in the source code file root directory.
#include<stdio.h>
#include<linux/sched.h>
int main()
{
printf("%d\n",sizeof(struct task_struct)).
return 0;
}
typing the command to the termial to compile and source code gcc -g -I *path/to/linux*-source/usr/include test.c -o test. However the terminal shows struct task_struct does not define stuff.
Could any guys to help me to figure it out? Really appreciated.
This struct is for kernel internal use only. It's definition is pretty long and largely varies depending on kernel configuration. So, the struct size also varies depending on kernel configuration, and you can't get it from user-space.
Unless, you extract kernel config, which is bad idea, as for me. The better one is to write a kernel module.
I cross-compiled a Helloworld executable for ARM. It worked well on my friend's development board, but failed with a " segmentation fault " on my board. The two boards are slightly different in both hardware and software.
My question is, how can I debug in my board? Is it relatively easy to debug such a simple program? Does it indicate that there's nothing wrong with the executable and the problem most probably lies in the filesystem of my board?
Below is the code:
#include <QApplication>
#include <QPushButton>
int main(int argc, char *argv[])
{
QApplication app(argc, argv);
QPushButton hello("Hello world");
hello.resize(100, 30);
hello.show();
return app.exec();
}
And the executable is generated by the following commands:
qmake -project
qmake
make
most probably gdb is ported to be run on ARM target but in case lack of that or for easy debugging, you should use gdb remote debugging.
http://sourceware.org/gdb/onlinedocs/gdb/Remote-Debugging.html#Remote-Debugging
Gdbserver is the application should be run on target. the following is demonstration howto use it. (copied from wikipedia)
Target settings:
remote$ gdbserver :2345 hello_world
Process hello_world created; pid = 2509
Listening on port 2345
Host settings:
local$ gdb -q hello_world
Reading symbols from /home/user/hello_world...done.
(gdb) target remote 192.168.0.11:2345
Remote debugging using 192.168.0.11:2345
0x002f3850 in ?? () from /lib/ld-linux.so.2
(gdb) continue
Continuing.
Program received signal SIGSEGV, Segmentation fault.
0x08048414 in main () at hello_world.c:10
10 printf("x[%d] = %g\n", i, x[i]);
(gdb)
So you mentioned after LD_LIBRARY_PATH your issue was resolved. And before setting the LD_LIBRARY_PATH if your application gives error can not find libQt then it means you do not have Qt, but your application is giving this Seg Fault that mean you have library but not the right one so we can say you have multiple installations of Qt on your filesystem.
The one to which you have pointed now is correctly compiled for your current hardware but the other one is not compiled for your hardware causing the Segfault and this installation is in your library search path.
One possible reason of this seg fault can be determined from below.
Following are some CFLAGS which if not set correctly for any particular hardware, the compiled application / library causes Seg faults at run time.
-march
-mtune
-mfpu
So if your binary / library is compiled with say -march=armv5a and you are running it on ARM9 then it will crash like this.
Also note that not all application uses these flags, usually these flags are optimization flags and are used by base system libraries (i.e Qt, Glib, bison, Gtk etc....).
Even if you write a simple C based hello world application and your glibc is not compiled for your hardware you will get the Seg fault.
Answer from Author:
What caused this "segmentation fault" is exactly the software difference of the board. Specifically, the environmenat variable LD_LIBRARY_PATH was predefined in the failed board. And I added my path by the command
export LD_LIBRARY_PATH=$LD_LIBRARAY_PATH:/my/qt/path
Thus the predefined paths caused the problem ( still don't know in what way ).
If I change the command to
export LD_LIBRARY_PATH=/my/qt/path
the executable works.
As a general rule you shouldn't create objects derived from QObject on the stack as the QMetaObject system manages the life-time of objects with a parent-child relationship, and will therefore risk free()ing memory on the stack.
I need to get the processor number in my program with C/C++ language. My code
like as follow:
#include <unistd.h>
int main()
{
int processorNum = sysconf(_SC_NPROCESSORS_CONF);
return 0;
}
when i compile it , it had two errors:
error: '_SC_NPROCESSORS_CONF' was not declared in this scope
error: 'sysconf' was not declared in this scope
so ,what should i do.
ps: my complier's version is gcc version 4.3.2 (Debian 4.3.2-1.1).should i link a library file
ps: Hi all, excuse me ,i made some mistakes. i forgot the head file.
1、The most reliable way is to read /proc/cpuinfo file. like grep processor proc/cpuinfo
2、use command lscpu