These are the steps I am doing to compile the linux source on my machine :
1. Copy the config file from /boot to /usr/src/kernels/2.6.29.4-167.fc11.i586/ directory
2. make oldconfig
3. make
Step 3 fails with the following error :
make[1]: *** No rule to make target `missing-syscalls'. Stop.
Compiling on a x86 box.
Any suggestions ?
Please feel free to close this question if it does not belong here.
As archaic as it may sound it appears that currently in order to get kernel source on a system you have to manually select the source you want. One supposes that people don't build kernels as often as they used to and of course you may want to develop a kernel that does not match the version that you are running..
So for example I wanted to install VBox on my CentOS 6.2 box and while most kernel modules can be compiled without complete sources this update failed.
So I found this wiki page:
http://wiki.centos.org/HowTos/I_need_the_Kernel_Source
It doesn't list 6.2 and the naming conventions have changed on the final directory name so to get the 6.2 kernel source you go to http://vault.centos.org/6.2/updates/Source/ and select the version you want. If you want source for a different version go to http://vault.centos.org/ and navigate from there.
The docs recommend against doing an rpm-build on the kernel sources.
Make a new config file. Maybe the old one isn't working?
I have not been able to answer why this error happens :
Step 3 fails with the following error : make[1]: *** No rule to make target `missing-syscalls'. Stop.
But I was able to compile the vanilla version fine, without the above error.
I asked the same question on serverfault as well, which has a more detailed explanation of the steps taken : https://serverfault.com/questions/61354/missing-syscalls-error-during-kernel-compilation
since kernel 3.x.x this message appears if trying to build external modules having only single Makefile prepared.
Instead, according to this manual,
splitting into Kbuild (where all the source files are listed, example):
obj-m := module_source.c
and simple Makefile (having only default make directive, example):
default:
$(MAKE) -C $(KDIR) M=$$PWD
will solve the problem.
just in case, external module build directive would be following:
make -C <kernel source path> -M=<module source folder>
example: make -C . -M=extra/
Related
I got a BMC project which need to use AST2600. I just start to handle u-boot.
When I enter blow instruction. I got a error when make.
export ARCH=arm
export CROSS_COMPILE=arm-openbmc-linux-gnueabi-
make ast2600_openbmc_defconfig
make
Result:
make: arm-openbmc-linux-gnueabi-gcc: Command not found
/bin/sh: 1: arm-openbmc-linux-gnueabi-gcc: not found
dirname: missing operand
Try 'dirname --help' for more information.
scripts/kconfig/conf --syncconfig Kconfig
CHK include/config.h
CFG u-boot.cfg
/bin/sh: 1: arm-openbmc-linux-gnueabi-gcc: not found
make[1]: *** [scripts/Makefile.autoconf:77: u-boot.cfg] Error 1
make: *** No rule to make target 'include/config/auto.conf', needed by 'include/config/uboot.release'. Stop.
The project from https://github.com/AspeedTech-BMC/u-boot
It seems like I miss a toolchain for arm-openbmc-linux-gnueabi-gcc. Does anyone have idea?
From an openbmc perspectives, I almost never build the uboots independently of from the bitbake/yocto project, (and when I do, I build projects in x86) Manually building should work, but openbmc (using bitbake/yocto) already has an automated process for building this project with the gcc tool chain that works for the AST2600 here and here
If you are planning on using openbmc I would recomened starting with these instructions.
In step 3 make sure to specify an platform with ast2600 (such as the
evb-ast2600)
Then in step 4 make you can just built uboot rather then a whole image. Something like bitbake u-boot-aspeed-sdk_2019.04, or you can build the whole image, and it take longer but you will have a copy of uboot.
If you have any more question feel free to reach out us in the open bmc email list https://lists.ozlabs.org/listinfo/openbmc, or to our discord https://discord.gg/69Km47zH98.
If you have an answer for this, or further information, I'd welcome it. I'm following advice from here, to offer some unsolicited help by posting this question then an answer I've already found for it.
I have a bare-metal ARM board for which I'm building a cross-toolchain, from sources for GNU binutils, gcc and gdb, and for SourceWare's Newlib. I got those four working and cross-built a DoNothing.c into an ELF file - but I couldn't disassemble it with this:
$ arm-none-eabi-objdump -S DoNothing.elf
The error was:
$ arm-none-eabi-objdump: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory
I'll follow up with a solution.
The error was correct - my system didn't have libdebuginfod.so.1 installed - but I have another cross-binutils, installed from binary for a different target, and its objdump -S works fine on the same host. Why would one build of objdump complain about missing that shared library, when clearly not all builds of objdump need it?
First I tried rebuilding cross binutils, specifying --without-debuginfod as a configure option. No change, which seems odd: surely that should build tools that not only don't use debuginfod but which don't depend on it in any way. (If someone can answer that, or point out what I've misunderstood, it may help people.)
Next I figured debuginfod was inescapable (for my cross-tools built from source at least), so I'd install it to get rid of the error. It's a component of the elfutils package, but installing the latest elfutils available for my Ubuntu 20.04 system didn't bring libdebuginfod.so.1 with it.
I found a later one, for Arch Linux, whose package contents suggested it would - but its package format doesn't match Ubuntu's and installing it was going to involve a lot of work. Instead I opted to build it from the Arch Linux source package. However, running ./configure on that gave a couple of infuriatingly similar errors:
configure: checking libdebuginfod dependencies, --disable-libdebuginfod or --enable-libdebuginfo=dummy to skip
...
configure: error: dependencies not found, use --disable-libdebuginfod to disable or --enable-libdebuginfod=dummy to build a (bootstrap) dummy library.
No combination of those suggestions would allow configure for elfutils-0.182 to run to completion.
The problem of course was my own lack of understanding. The solution came from the Linux From Scratch project: what worked was to issue configure with both of the suggested options, like this:
$ ./configure --prefix=/usr \
--disable-debuginfod \
--enable-libdebuginfod=dummy \
--libdir=/lib
That gave a clean configure; make worked first time, as did make check and then sudo make install which of course installed libdebuginfod.so.1 as required. I then had an arm-none-eabi-objdump which disassembles cross-compiled ELF files without complaining.
I have a problem by compiling a driver (WLAN-dongle Edimax ac600).
I´m using an Archlinux on my raspberry-pi and want to install my dongle for 5Ghz. During comiling the driver I get this message. I tried to install the linux-headers without success. (in other threads it will be a solution)
Here is my output of make:
[root#raspberry_pi_1 rtl8812AU]# make make ARCH=arm CROSS_COMPILE= -C
/lib/modules/4.9.43-1-ARCH/build M=/root/rtl8812AU modules make[1]:
*** /lib/modules/4.9.43-1-ARCH/build: No such file or directory. Stop. make: *** [Makefile:1576: modules] Error 2
I found out that my pi has a two-arch...-directories:
4.9.43-1-ARCH/
4.9.51-1-ARCH/
Only the second one has the build directory...
How can I fix the problem?!
thanks a lot,
a Linux noob...
[Reputation is too low to post comment]
Use uname -r to make sure which version of the kernel you use.
If it's 4.9.43 : you have newer version of the kernel and this confuse your installer. You should reboot on the 51 one
If it's 4.9.51 : You messed up your installation step and are trying to compile for an old target. You should review the compilation process and change every mention of the 4.9.43 to 4.9.51 since it's the version you use.
If you upgrade your kernel, you may have to rebuild the thing again (You may like to have script in the future ;) ) with the new kernel version.
im on BSP v1.1
yocto is 1.6
I'm trying to set up the cross compile toolchain to compile character driver code
but the output i get is
[mark#localhost ~]$ ${CC} first.c -o first
first.c:1:24: fatal error: linux/init.h: No such file or directory
.#include
^ compilation terminated.
I think the issue is that
the header is not in the toolchain
/opt/iot-devkit/1.6.1/sysroots/i586-poky-linux/usr/include/linux/~
there is no at this location
I think something has to be added as IMAGE_INSTALL or IMAGE_FEATURE but i dont know what
am I on the right track ?
does anyone know what i have to add ?
or am i completely off tracks altogether?
Well, first and foremost, you can never build a kernel module by just running ${CC} on it. You should always use a Makefile, which redirects most of its work to the kernel source Makefil.
Create a Makefile for you module, consisting of something similar to:
obj-m += hello-1.o
all:
make -C $(KERNEL_SRC M=$(PWD) modules
clean:
make -C $(KERNEL_SRC) M=$(PWD) clean
Example taken from The Linux Kernel Module Programming Guide (Note that the actual commands needs to have a tab character for indentation).
Then you'll have to define KERNEL_SRC to be /opt/iot-devkit/1.6.1/sysroots/i586-poky-linux/usr/src/kernel/, either in the Makefile, or from your make call. (Using a variable like KERNEL_SRC will ensure that your module recipe automatically picks the right location when building using bitbake).
To manually build your kernel module:
Source the environment-* file for your SDK.
Go to you modules directory.
KERNEL_SRC=/opt/iot-devkit/1.6.1/sysroots/i586-poky-linux/usr/src/kernel LDFLAGS="" make
However, this will fail, as fixdep can't be found. We'll fix this manually.
cd /opt/iot-devkit/1.6.1/sysroots/i586-poky-linux/usr/src/kernel
make silentoldconfig scripts
Go back to your modules directory.
KERNEL_SRC=/opt/iot-devkit/1.6.1/sysroots/i586-poky-linux/usr/src/kernel LDFLAGS="" make
This should now produce hello.ko which you should be able to insmod on the Galileo board.
I have searched this but the questions I found are about getting the toolchain to work, my problem is that it works on all but a few directories. Also I am not building Linux.
I am trying to move a project from a Linux machine to Windows to make people happy. The same project builds fine under Linux (Ubuntu 12.04) using the Linux Binary for the same toolchain (I recently reloaded both toolchains from the same directory at Mentor to be sure, see details below).
I installed Cygwin, got the packages, set up paths, etc. In general the build works for 90% of the project BUT as make traverses the directory, it finds everything except two files (to clarify, these two are the first files in their respective directories, so I assume the problem will apply to the whole directory). The log below shows the first fail:
if I take lwip out of the build then it blows up on the next one
if I take the next one out of the build then everything else (quite a bit) compiles; then the linker fails on the two missing items as expected.
More precisely, e.g.
it finds /home/Nadi/project/version-2.9/external/freertos/Source/portable/GCC/ARM_CM3_MPU/port.c
but not /home/Nadi/project/version-2.9/external/lwip/src/api/api_lib.c
from the directory that I am running make, "ls" finds the file that the compiler cannot.
log:
$ make
external/freertos
external/lwip
[cc] Debug/api_lib.o
arm-none-eabi-gcc.exe: error: /home/Nadi/project/version-2.9/external/lwip/src/api/api_lib.c: No such file or directory
arm-none-eabi-gcc.exe: fatal error: no input files compilation terminated.
Makefile:189: recipe for target `Debug/api_lib.o' failed
make[2]: *** [Debug/api_lib.o] Error 1
Makefile:37: recipe for target `lwip_world' failed
make[1]: *** [lwip_world] Error 2
Makefile:160: recipe for target `extern' failed
make: *** [extern] Error 2
Details:
GCC Chain : arm-none-eabi-gcc ; gcc version 4.7.2 (Sourcery CodeBench Lite 2012.09-63)
Cygwin : CYGWIN_NT-6.1-WOW64
Although it might not help in this particular case, I faced similar problem with CodeSourcery's gcc not recognising Cygwin's paths like /cygdrive/d/foo.c at all - installation of cygpath package and setting environment variable export CYGPATH=c:/cygwin32/bin/cygpath (or set CYGPATH=c:/cygwin32/bin/cygpath in windows console) solved all the issues.
Be sure to define path to cygpath executable in exactly same way as above, regardless of Cygwin or Windows console used.
The details of my previous comment is that you're in for a lot of trouble using the windows/cygwin combo with Sourcery based cross-compilers. You can read more about this at SamyGo. Some of the issues using Windows, presented in all gory detail there, are:
Uses ACL to set file permissions and ownership (Not Linux compatible.)
Has it's own way of creating symbolic links (Not Linux compatible.)
Uses a non case-sensitive default for its fixed NTFS drives.
(Often and silently break archives originally compressed under Linux.)
Uses the Win32 (non POSIX) standard for file paths (Not Linux compatible.)
Uses the 2 characters Carriage-Return and New-Line ("\r" & "\n") for
End-of-Line (EOL) representation, contrary to POSIX, which uses only NL.
So in order not to waste time doing 3rd party debugging, you'd be much better off building your own cross-compiler from scratch, as shown in the XDA links in that other post. Since the advent of Android's, this is no longer difficult.