I'm trying to build a new kernel and add a new system call to that built kernel and when I try to recompile using 'make' command after creating the new system call I get this error.
scripts/Makefile.build:44: /usr/src/linux-3.0.42/block/helloworld/Makefile: No such file or directory
make[1]: *** No rule to make target `/usr/src/linux-3.0.42/block/helloworld/Makefile'. Stop.
make: *** [block/helloworld] Error 2
If someone can help me with this I'll be thankful :)
Kernel modules use a different version of make than you are probably used to. It greatly simplifies things, but can be a bit confusing at first. Here is documentation for kernel make: http://lwn.net/Articles/21835/
Here is tutorial on a hello world module:
The c code: http://tldp.org/LDP/lkmpg/2.6/html/x121.html
The corresponding makefile: http://tldp.org/LDP/lkmpg/2.6/html/x181.html
Not to bring back an old post but I had a similar problem and I am surprised no one suggested this.
When editing the linux3-x-x/Makefile
you want to include your directory by modifying the line:
core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/
to
core-y += kernel/ mm/ fs/ ipc/ security/ crypto/ block/ helloworld/
A simple mistake is to forget THE SPACE after each directory block/_helloworld/
The underscore represents a SPACE
IF YOU do not have that space then you will get the above error no matter what.
Just thought I would add this incase others are searching around for a response
Related
I am trying to learn how to port GCC to new architectures. Most tutorials say that I only have to create three files named my_processor.c my_processor.h and my_processor.md; however when running ./configure --target=my_processor machine is not recognized.
Following an answer given in How to write your own code generator backend for gcc?, I added my configuration in config.sub and ./configure worked.
Unfortunately, when I use make, the terminal returns an error saying
checking if mkdir takes one argument... no
*** Configuration my_processor-unknown-none not supported
Makefile:4230: recipe for target 'configure-gcc' failed
make[1]: *** [configure-gcc] Error 1
make[1]: Leaving directory 'objdir'
Makefile:905: recipe for target 'all' failed
make: *** [all] Error 2
The problem seems to be due to a bad configuration in gcc/config.gcc, maybe because I added my architecture in a wrong place (there are multiple case ${target}, so not sure which choose) or because I am missing something.
The only information that I have found appears in https://gcc.gnu.org/onlinedocs/gcc-4.2.2/gccint/Back-End.html, but it is not complete enough.
So, how could I do to avoid this error?
Krister Walfridsson's blog has a detailed description of all the steps needed to create a new backend. The first in the series is about the 8 kinds of files to be changed or created. It's also suggested to follow the logic for a Moxie backend that might be easier to start with than risc-v.
I have a question very simliar to Cross compiler default include path setup but there wasn't the answer I was looking for.
I built a cross-compiler for openrisc. I have it in ~/openrisck/toolchain/
under there, I have bin(or32-linux-* excutables are here), include, lib, lib64, libexec, or32-linux, share.
under or32-linux, I have bin, include, lib, sys-root.
When I build busybox, I gave CONFIG_CROSS_COMPILER_PREFIX as "or32-linux-".
and CONFIG_SYSROOT as "$SYSROOT" which is ~/openrisk/toolchain/or32-linux/sys-root.
then I run 'make install' in buxybox source. Since the path includes the cross-compiler directory, it compiles for or32-linux-. But I have an error below
ckim : srctree = /home/ckim/openrisc/busybox
CC applets/applets.o
In file included from /home/ckim/openrisc/toolchain/bin/../lib/gcc/or32-linux/4.5.1-or32-1.0rc1/include-fixed/syslimits.h:7:0,
from /home/ckim/openrisc/toolchain/bin/../lib/gcc/or32-linux/4.5.1-or32-1.0rc1/include-fixed/limits.h:34,
from include/platform.h:141,
from include/libbb.h:13,
from include/busybox.h:8,
from applets/applets.c:9:
/home/ckim/openrisc/toolchain/bin/../lib/gcc/or32-linux/4.5.1-or32-1.0rc1/include-fixed/limits.h:169:61: fatal error: limits.h: No such file or directory
compilation terminated.
make[1]: *** [applets/applets.o] Error 1
make: *** [applets_dir] Error 2
which makes me thinks that Ah! the cross-compiler uses the include path relative to the executable. (see above bin/../lib/gcc/or32-linux/version/include-fixed)
So the include limits.h goes to the gcc's limits.h correctly. The last file syslimits.h has #include_next when the limits.h file have already been included. and the compiler complains that the file cannot be found.
Can somebody tell me how to solve this problem? (limits.h includes syslimits.h and syslimits.h includes limits.h .. )
EDIT : I ran 'make CROSS_COMPILE=or32-linux- CONFIG_PREFIX=$SYSROOT install'
then I got 'lutimes undeclared in coreutil/touch.c' error. Assuming the limit.h problem is gone, this means I should give these command line arguments because CROSS_COMPILE for make is different from CONFIG_CROSS_COMPILER_PREFIX in busybox configuration and make's CONFIG_PREFIX is different from CONFIG_SYSROOT for busybox configuration. so to remove the lutimes error, I ran 'make menuconfig' and removed CONFIG_TOUCH. Then I reran the make(make CROSS_COMPILE=or32-linux- CONFIG_PREFIX=$SYSROOT install), and this time got
procps/free.c: In function 'free_main':
procps/free.c:51:17: error: storage size of 'info' isn't known
procps/free.c:77:2: warning: implicit declaration of function 'sysinfo'
I found that in $SYSROOT/usr/include/sys/sysinfo.h, struct sysinfo is defined. I don't know why it says it's not defined. Any help would be deeply appreciated. Thanks!
For anyone who might be facing the same problem I had..
I tried about 3 times with the old toolchain but failed.
Yesterday, I got help from IRC (openrisc) and someone told me there is an updated toolchain for or1k. (not or32 which is old. I should have read the opencore page first..)
The page is
http://opencores.org/or1k/OpenRISC_GNU_tool_chain#Linux_.28uClibc.29_toolchain_.28or1k-linux-uclibc.29 (read from Linux (uClibc) toolchain (or1k-linux-uclibc))
I'm trying to compile gcc-code-assist which has the code completion feature in order to use it with emacs. However i have been getting this error message while compilinng
checking for exception model to use... configure: error: unable to detect exception model
make[1]: *** [configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory `/home/dev/workspace/trash/gcc-code-assist-0.1-4.4.4'
make: *** [all] Error 2
I'm running Ubuntu 12.04 64bit
what can i do to overcome this problem
I found the right way to compile it ...
I really didn't have much knowledge of how to compile gcc (my first time)
after reading through the FAQ of building gcc I found the problem.
it turned out that I had to run the configure script and make from outside the source directory
( I called it gcc-build) so the directory list looked like this
gcc-source/
gcc-build/
then everything compiled smoothly
here's the link to the FAQ http://gcc.gnu.org/wiki/FAQ#configure
I was compiling a source code, and it always fails at make command, below is the error message.
gcc: unrecognized option '-rdynamic'
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: \
warning: --export-dynamic is not supported for PE targets, \
did you mean --export-all-symbols?
/usr/lib/gcc/i686-pc-cygwin/4.5.3/../../../../i686-pc-cygwin/bin/ld: \
warning: --export-dynamic is not supported for PE targets, \
did you mean --export-all-symbols?
make[3]: Leaving directory `/home/alimjan/slim502/src'
make[2]: Leaving directory `/home/alimjan/slim502/src'
make[1]: Leaving directory `/home/alimjan/slim502/src'
Making all in lib
make[1]: Entering directory `/home/alimjan/slim502/lib'
Cannot execute /bin/lmntal
Makefile:422: recipe for target `config.il' failed
make[1]: *** [config.il] Error 1
make[1]: Leaving directory `/home/alimjan/slim502/lib'
Makefile:293: recipe for target `all-recursive' failed
make: *** [all-recursive] Error 1
(Above lines broken to display)
I could not solve this. I am new to make and don't know what to do?
Usually when a makefile output looks as severe as your output, then it is because of the environment of which it is being used on has changed -- it could perhaps be that some external files have been moved or deleted or it could be that the make is too big, especially if the make is recursive in nature ( stay away from recursive makefiles; go NR)
Anyway if I where you I would look into where the environment had changed -- perhaps if your project is in a version system - try a different branch
Trying to solve the problems in the makefile could be very difficult and so it is better to go back to a version that worked and then move on from there
I'm not really sure this is a problem with the makefile. The error is:
Cannot execute /bin/lmntal
I'm fairly sure if you tried to run "/bin/lmntal" yourself from the command line you'd get a similar error. It seems that your build requires some extra utility in order to run, that you don't have or which isn't working on your system. Does that file (/bin/lmntal) exist? Is it executable? Is it a script and if so, does the first line refer to an interpreter that exists and is executable? Is it a 32bit program (use file /bin/lmntal) while you're using a 64bit operating system and if so, do you have the 32bit versions of libc, etc. installed on your Ubuntu system? Or vice versa (if you have a 32bit Ubuntu and the utility is a 64bit program you won't be able to run it at all)?
Alternatively it could be that this program is supposed to be found somewhere else or named something else, and your makefile is at fault because some variables are not set; for example the makefile could say something like $(FOODIR)/bin/lmntal and for some reason the variable $(FOODIR) is not set.
If you provide the details above (file exists? Permissions? file output? Complete rule at line 422 of the makefile?) we can provide more help.
I'm using make to build a large project on OSX Lion. The scripts worked fine on OSX up to Snow Leopard, but now it fails.
What happens is that after building certain modules, I get an error similar to the following:
touch my.app/Contents/Resources
touch my.app
make[2]: write error
make[1]: *** [all] Error 1
make: *** [all] Error 1
If I then type make again it resumes from where it fails and builds successfully (until it hits another such error). It always happens for the same two modules of the project, and I can't for the life of me work out why.
Please let me know if there's any more information I can provide that would be helpful.
1st Update
Here's the output of make -d:
...
Finished prerequisites of target file `DesktopConn.o'.
Prerequisite `DesktopConn.cxx' is older than target `DesktopConn.o'.
No need to remake target `DesktopConn.o'.
Considering target file `List.o'.
Looking for an implicit rule for `List.o'.
Trying pattern rule with stem `List'.
Trying implicit prerequisite `/bin/sh: line 1: 6733 Segmentation fault: 11 make all
Reaping losing child 0x102d0ae70 PID 6471
make[1]: *** [all] Error 1
Removing child 0x102d0ae70 PID 6471 from chain.
Reaping losing child 0x10560ee20 PID 6342
make: *** [all] Error 1
Removing child 0x10560ee20 PID 6342 from chain.
I've put the whole make -d output (extremely verbose) on pastebin.
2nd Update
I've uploaded the Makefile too.
3rd Update
I've downloaded the source for make, built from source on my machine. It still fails at the same point. I've also tried using the make binary from Snow Leopard.
Try taking the SEGV at face value. make is either dereferencing an out-of-bounds pointer, or trying to write memory somewhere out of bounds, or it is trying to extend the stack beyond the process stack size limit. There's nothing you can do about the first two without debugging GNU make, but you can increase the stack limit. Using bash:
ulimit -s hard
raises the soft limit to the hard limit, giving you as much stack space as possible. Try it and see if make can run to completion without crashing.
llvm is the default compiler in Lion, I believe, but was not in previous versions you mentioned. Occam's razor says try it using:
CC=gcc make
Edit:
Found this, which I think is related. See answer #1, 3 edits: here. It refers to building Ruby, but I think the underlying issue is the same. It's possible you'll need to download a different version of GCC if this is the issue.