Here's what I did.
In path ./linux-5.7
mkdir hello
cd hello
vim hello.c
#include <linux/kernel.h>
asmlinkage long sys_hello(void) {
printk ("\n\nHello Kernel\n\n");
return 0;
}
vim Makefile
obj-y := hello.o
vim arch/x86/entry/syscalls/syscall_64.tbl
439 common hello sys_hello
vim include/linux/syscalls.h
asmlinkage long sys_hello(void);
...
...
Compile the kernel
make -j4
Error ...
ld: arch/x86/entry/syscall_64.o:(.rodata+0xdb8): undefined reference to `__x64_sys_hello'
make: *** [Makefile:1113: vmlinux] Error 1
What's wrong here...
...
...
...
I experienced similar problem, but the solution from Joseph's comment didn't work out for me. So, this answer is for those who tried Joseph's one but had not made progress.
Here's steps that I took based on Kernel document
After you put __x64_ in front of the entry point, if you got an error such as
ld: arch/x86/entry/syscall_64.o:(.rodata+0xdc8): undefined reference to `__x64___x64_sys_my_syscall'
ld: arch/x86/entry/syscall_x32.o:(.rodata+0xdc8): undefined reference to `__x64___x64_sys_my_syscall'
make: *** [Makefile:1179: vmlinux] Error 1
then rather then put __x64_ in front of entry point of your syscall, put syscall into both of your arch/x86/entry/syscalls/syscall_64.tbl and arch/x86/entry/syscalls/syscall_32.tbl without any prefix such as
- At the `arch/x86/entry/syscalls/syscall_64.tbl`,
441 common my_syscall sys_my_syscall
- At the arch/x86/entry/syscalls/syscall_32.tbl`
441 i386 my_syscall sys_my_syscall
After this, if you still have same problem, then add your syscall into general syscall table: syscall list that shared among several architectures.
Put following in include/uapi/asm-generic/unistd.h:
#define __NR_my_syscall 441
__SYSCALL(__NR_my_syscall, sys_my_syscall)
Note that the kernel version I used is WSL2-Linux-Kernel-linux-msft-wsl-5.10.60.1 and it's built in x64 architechture.
I'm quite novice in OS and linux kernel, so this is just what worked for me and I don't know the exact mechanisim of it; sorry for no mechanisim explanation.
Related
A complete newbie here. I am learning to read the codes on suckless.org. They are written in C, and are most quite short, so I think it's a good start.
The problem is I know too little to start with. Wandering around on the site, I found that the suckless community has their own coreutils, which are also very short. echo.c on this page is one of the shortests. I include its header here:
/* See LICENSE file for copyright and license details. */
#include <stdio.h>
#include <string.h>
#include "util.h"
I'd like to compile it and see how this version of echo works, and come back to understand the code. The goal is to repeat this process until I'm comfortable enough to read the source codes of their their larger programs like sent, dmenu, dwm.
In the code, the header #include "util.h" suggests me to put util.h, which is another file in the link above, together with echo.c. I also include arg.h and compat.h because the header of util.h says
#include <sys/types.h>
#include <regex.h>
#include <stddef.h>
#include <stdio.h>
#include "arg.h"
#include "compat.h"
I further checked arg.h and compat.h. Neither of them includes customized header files, so I think I'm good to go. Now the folder tree looks like
$ tree
.
├── arg.h
├── compat.h
├── echo.c
└── util.h
and I run $ gcc echo.c -o echo.o. However, I got an error
/usr/bin/ld: /tmp/cc2VjXNO.o: in function `main':
echo.c:(.text+0x20): undefined reference to `argv0'
/usr/bin/ld: echo.c:(.text+0x27): undefined reference to `argv0'
/usr/bin/ld: echo.c:(.text+0x8d): undefined reference to `putword'
/usr/bin/ld: echo.c:(.text+0xc8): undefined reference to `fshut'
collect2: error: ld returned 1 exit status
Apparently, these undefined arguments are in those header files. Searching around on the net, I further tried
$ gcc -c . echo.c -o echo.o
gcc: warning: .: linker input file unused because linking not done
It spits a warning, but anyway an echo.o is delivered. I chmod it to executable, and run it by $ ./echo.o, but my shell complains
zsh: exec format error: ./echo.o
I spent another hour trying to solve this.. by try and error, but in vain. Would you please point out what's going on? And what should I do?
(Any other suggestions will also be very appreciated.)
You try to compile a program with library that you don't have. The header you're using needs a dynamic or static library (either .a or .o on linux). That's why you get linker input file unused because linking not done.
zsh: exec format error: ./echo.o if you use .o extension with -o argument, you're either making or linking a .o object file (static lib). With gcc -c . echo.c -o echo.o, you're creating a static library (called object) that you won't be able to execute.
By the way, I'd stay away for now from this kind of code, it's very not friendly user for a learner.
I am attempting to run NPB benchmarking on my RHEL7.3 install but come into a similar issue as the question asked here
Error while building NAS benchmarks
Trying to make the BT benchmark, which is in fortran, I get the following error:
cd BT; make NPROCS=16 CLASS=W SUBTYPE= VERSION=
make[1]: Entering directory '/mnt/npb_install/NPB3.3-MPI/BT'
make[2]: Entering directory '/mnt/npb_install/NPB3.3-MPI/sys'
make[2]: Nothing to be done for 'all'
make[2]: Leaving directory '/mnt/npb_install/NPB3.3-MPI/sys'
../sys/setparams bt 16 W
make[2]: Entering directory '/mnt/npb_install/NPB3.3-MPI/BT'
make[3]: Entering directory '/mnt/npb_install/NPB3.3-MPI/BT'
gfortran -O -o ../bin/bt.W.16 bt.o make_set.o initialize.o exact_solution.o exact_rhs.o set_constants.o adi.o define.o copy_faces.o rhs.o solve_subs.o x_solve.o y_solve.o z_solve.o add.o error.o verifiy.o setup_mpi.o ../common/print_results.o ../common/timers.o btio.o -L/usr/lib/openmpi-x84_64/ -lmpi
/bin/ld: cannot find -lmpi
collect2: error: ld returned 1 exit status
make[3]: *** [bt-bt] Error 1
make[3]: Leaving direc.......
However I am not using Intel MPI but rather OpenMPI, though I don't full understand the implication of that.
My make.def file has the following mpi related settings
#-------------------------------------
# This is the fortran compiler usedd for MPI programs
#-----------------------------------------
MPIF77 = gfortran
# This links MPI fortran programs; usually the same as ${MPIF77}
FLINK = ${MPIF77}
#------------------------------------------
# These macros are passed to the linker to help link with MPI correctly
#-------------------------------------------
FMPI_LIB = -L/usr/lib/openmpi/lib/ -lmpi
#-----------------------------------------
# These macros are passed to the compiler to help find 'mpif.h'
#------------------------------------------
FMPI_INC = -I/usr/include/openmpi-x86_64/
Similar to those posted in the above question.
From the error, I assume that the input parameters -lmpi is not a valid input parameter for gfortran when compiling but removing it leads to a screen full of undefined references like:
file.f:(.text+0x123): undefined reference to 'mpi_whatever_'
Is it possible to compile NPB with gfortran? Or am I clearly doing something wrong here?
I have seen that using ifort is another option but I thought I'd ask the question before moving towards that possible solution
After hacking at it I resolved the issue with the following fixes, not sure what did it.
OpenMPI may have not been installed properly (was unable to call mpicc or other wrappers/comps), to fix it I ran the following commands
module avail
#displayed the openmpi-x86_64 module
module add open-x86_64
which mpirun
#displayed location of mpirun
The more likely fix was simply changing gfortran in the make.def file to mpif77
/*
* hello-1.c - The simplest kernel module.
*/
#include <linux/module.h> /* Needed by all modules */
#include <linux/kernel.h> /* Needed for KERN_INFO */
int init_module(void)
{
printk(KERN_INFO "Hello world 1.\n");
/*
* A non 0 return means init_module failed; module can't be loaded.
*/
return 0;
}
void cleanup_module(void)
{
printk(KERN_INFO "Goodbye world 1.\n");
}
MAKEFILE
obj-m += hello.o
all:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) modules
clean:
make -C /lib/modules/$(shell uname -r)/build M=$(PWD) clean
After the make command I am getting the following error. What is the reason for this error and how can i resolve this?
make -C /lib/modules/2.6.32-358.el6.x86_64/build M=/home/hello modules
make: *** /lib/modules/2.6.32-358.el6.x86_64/build: No such file or directory. Stop.
make: *** [all] Error 2
-C option in make command instruct to change directory to one provided with -C. In your case, it is /lib/modules/2.6.32-358.el6.x86_64/build. But when it tries to change to that directory, compilation gives error with "No such file or directory", which means that you don't have build directory at /lib/modules/2.6.32-358.el6.x86_64/.
A lot of time it happens that build in the given path may not be a directory, but it may be a soft link pointing to a kernel source code directory.
So you need to check either there should be build directory at the required path which contains kernel source or it should be a soft link to kernel source.
Apart from all those build related comments, there are few things you have to follow while writing a kernel module. Your code will not work as you expect even after you fix those build issues. Why? you have the init and cleanup routines built, but you haven't specified/directed which one is your init routine and which is cleanup.
You have to do that this way,
at the end of the file add these two line.
module_init ( foo_init_fn);
module_exit ( bar_exit_fn);
Also, you have to specify the module license details etc. like below
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Copyright (c) 2006 by xxxx xxxxx, Inc.");
MODULE_DESCRIPTION("klm_vdc");
I am porting an application from Solaris to Linux
The object files which are linked do not have a main() defined. But compilation and linking is done properly in Solaris and executable is generated. In Linux I get this error
/usr/lib/gcc/x86_64-redhat-linux/4.1.2/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
My problem is, I cannot include new .c/.o files since its a huge application and has been running for years. How can I get rid of this error?
Code extractes of makefile:
RPCAPPN = api
LINK = cc
$(RPCAPPN)_server: $(RPCAPIOBJ)
$(LINK) -g $(RPCAPIOBJ) -o $(RPCAPPN)_server $(IDALIBS) $(LIBS) $(ORALIBS) $(COMMONLIB) $(LIBAPI) $(CCLIB) $(THREADLIB) $(DBSERVERLIB) $(ENCLIB)
Try adding -nostartfiles to your linker options, i.e.
$(LINK) -nostartfiles -g ...
From the gcc documentation:
-nostartfiles
Do not use the standard system startup files when linking. The standard system libraries are used normally, unless -nostdlib or -nodefaultlibs is used.
This causes crt1.o not to be linked (it's normally linked by default) - normally only used when you implement your own _start code.
-shared link option must be used when you compile a .so
The issue for me was, I by mistake put int main() in a namespace. Make sure don't do that otherwise you will get this annoying link error.
Hope this helps anyone :)
I had similar result when trying to build a new test project with boost, and it turned out that I was missing one declaration :
#define BOOST_TEST_MODULE <yourtestName>
I had this same problem when creating my c project, and I forgot to save my main.c file, so there was no main function.
I had a similar result when compiling a Fortran program that had C++ components linked in. In my case, CMake failed to detect that Fortran should be used for the final linking. The messages returned by make then ended with
[100%] Linking CXX executable myprogram
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
make[3]: *** [myprogram] Error 1
make[2]: *** [CMakeFiles/myprogram.dir/all] Error 2
make[1]: *** [CMakeFiles/myprogram.dir/rule] Error 2
make: *** [myprogram] Error 2
The solution was to add
set_target_properties(myprogram PROPERTIES LINKER_LANGUAGE Fortran)
to the CMakeLists.txt, so that make prints out:
[100%] Linking Fortran executable myprogram
[100%] Built target myprogram
I had the same issue with a large CMake project, after I moved some functions from one code file to another. I deleted the build folder, recreated it and rebuilt. Then it worked.
Generally, with suddenly appearing linker errors, try completely deleting your build folder and rebuilding first. That can save you the headaches from trying to hunt down an error that actually simply shouldn't be there: There might be CMake cache variables floating around that have the wrong values, or something was renamed and not deleted, ...
I had the same issue as to OP but on on FreeBSD 13.1.
What solved the issue was simply adding:
int main()
{
}
Since the .cpp file was only an object file containing definitions and declarations using:
extern "C"
{
<all definitions and declarations code goes here>
}
Every time I tried compiling this, the compiler kept throwing the same error as to OP.
So all I did was add an empty main() function all the way at the bottom and code compiled with no errors.
I'm attempting to install the following Haskell package on Windows using Cygwin: HaskellCuda
You can install the package using "cabal install cuda".
Here is the output I get (you may have to "cuda install c2hs" first):
$ cabal install
Configuring cuda-0.4.0.2...
checking for gcc... C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.
Resolving dependencies...
cabal.exe: Error: some packages failed to install:
cuda-0.4.0.2 failed during the configure step. The exception was:
ExitFailure 77
The relevant part from the log file is:
configure:1758: checking for gcc
configure:1785: result: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe
configure:2022: checking for C compiler version
configure:2029: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe --version >&5
configure: line 2030: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe: command not found
configure:2035: $? = 127
configure:2042: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe -v >&5
configure: line 2043: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe: command not found
configure:2045: $? = 127
configure:2052: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe -V >&5
configure: line 2053: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe: command not found
configure:2055: $? = 127
configure:2078: checking for C compiler default output file name
configure:2105: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe -fno-stack-protector conftest.c >&5
configure: line 2106: C:\Haskell\2011.4.0.0\mingw\bin\gcc.exe: command not found
configure:2108: $? = 127
configure:2146: result:
configure: failed program was: [source elided]
If I go to Cygwin and type
gcc --version
I get something reasonable. The problem appears to be more with the path I guess, but I'm not sure what/how to fix it. I should also note that using "cabal install cuda-0.2.2", an older version of this package, I get past this step (but get a different error later).
To replicate, make sure you install the Haskell Platform in a path without spaces, otherwise you will probably get a different error. That's the only thing I've figured out so far.
Any help with this would be GREATLY appreciated, I've spent about a week so far and haven't gotten anywhere.
EDIT:
$PATH = C:\Haskell\2011.4.0.0\mingw\bin;
C:\Haskell\2011.4.0.0\lib\extralibs\bin;
C:\Haskell\2011.4.0.0\bin;
C:\CUDA\v4.0\bin\;
C:\cygwin\bin\;
...
I managed to get it to install, but it isn't pretty and I don't really understand why it won't work out of the "autoconf" box.
For starters, rather than installing with "cabal install" (using a local copy), I used the sequence
>runhaskell Setup.hs configure
>runhaskell Setup.hs build
>runhaskell Setup.hs install
The main reason for this is because it is simple to change the $CC variable in the configure script using the argument in Setup.hs. I suspected the $CC was the variable giving me the problem. I changed:
[("CC", ccProg)
to
[("CC", "/cygdrive/c/cygwin/bin/gcc.exe")
in Setup.hs, which is the gcc that comes with Cygwin. My initial suspicion was that autoconf didn't like the Windows-style path to gcc, which it was using based on the log file above. I also discovered though that of the multiple copies of gcc on my computer (one in Haskell/mingw, one in a separate installation of mingw, and whichever version $PATH was pointing to, ONLY the cygwin gcc was able to successfully compile the test file that checked for . Using the cygwin gcc, I could run
gcc hello.c
on any file that included (WITHOUT an external include directive), whereas with any other copy of gcc, even something like
gcc -I/cygdrive/c/..../include hello.c
was not able to find . No idea why.
Just changing the $CC to the Cygwin gcc fixed almost all of the errors. The next errors occurred when "checking for library containing cudaRuntimeGetVersion/cuGetDriverVersion".
The file configure was trying to compile was
#define PACKAGE_NAME "Haskell CUDA bindings"
#define PACKAGE_TARNAME "cuda"
#define PACKAGE_VERSION "0.4.0.0"
#define PACKAGE_STRING "Haskell CUDA bindings 0.4.0.0"
#define PACKAGE_BUGREPORT "tmcdonell#cse.unsw.edu.au"
#define STDC_HEADERS 1
#define HAVE_SYS_TYPES_H 1
#define HAVE_SYS_STAT_H 1
#define HAVE_STDLIB_H 1
#define HAVE_STRING_H 1
#define HAVE_MEMORY_H 1
#define HAVE_STRINGS_H 1
#define HAVE_INTTYPES_H 1
#define HAVE_STDINT_H 1
#define HAVE_UNISTD_H 1
#define HAVE_CUDA_H 1
#define HAVE_CUDA_RUNTIME_API_H 1
/* end confdefs.h. */
/* Override any GCC internal prototype to avoid an error.
Use char because int might match the return type of a GCC
builtin and then its argument prototype would still apply. */
#ifdef __cplusplus
extern "C"
#endif
char cudaRuntimeGetVersion ();
int main ()
{
return cudaRuntimeGetVersion ();
;
return 0;
}
using the command:
/cygdrive/c/cygwin/bin/gcc.exe -o conftest.exe -fno-stack-protector
-I/cygdrive/c/CUDA/v4.0/include -L/cygdrive/c/CUDA/v4.0/lib conftest.c -lcudart
The error (from the log file) is
/cygdrive/c/Users/crockeea/AppData/Local/Temp/ccKMQJiq.o:conftest.c:(.text+0xc):
undefined reference to `_cudaRuntimeGetVersion'
I'm a little rusty on my C, but it seems like they aren't include the appropriate header file here. That probably isn't right because the same file works on Unix based systems when running configure, but it's my best guess. Also, editing configure to make this file include cuda.h just results in a different error about multiple definitions of cudaRuntimeGetVersion. So my hack was to comment out the lines in the configure file with references to cudaRuntimeGetVersion/cuGetDriverVersion. I put C-comments into the C files that the configure file was going to compile (it is easy enough to find the source code for these in the configure file based on line numbers from the log file). I don't know the consequences of modifying the configure file in this way.
This allowed me to get past the 'build' phase. More comments if I run into any other issues.