Does Pintos have to be installed in a different way for the second Project (User Programs)? Whenever I try to run pintos -f -q on my installation, I get an error where Pintos doesn't recognize the arguments "-f".
Back to tcg accelerator.
PiLo hda1
Loading..........
Kernel command line: -f -q
Kernel PANIC at ../../threads/init.c:264 in parse_options(): unknown option `-f' (use -h for help)
Call stack: 0xc00283de.
The `backtrace' program can make call stacks useful.
Read "Backtraces" in the "Debugging Tools" chapter
of the Pintos documentation for more information.
This is where all the arguments are handled by Pintos:
http://www.cse.iitd.ernet.in/~sbansal/csl373/pintos/doc/pintos_html/init_8c-source.html
I can't find the definition of FILESYS anywhere either. Can someone please help me out here?
In utils/pintos change line number 259 to /home/<your home username>/<pintos dir>/src/userprog/build/kernel.bin
In utils/Pintos.pm change line number 362 to /home/<your home username>/<pintos dir>/src/userprog/build/loader.bin
Run make in userprog, utils again.
Had the same problem
You need to point the Kernel and Loader to the Kernel and Loader in userprog/build instead of threads/build as done while installing pintos
Related
I am trying to install Inotify2 on freeBSD, but test step throws error.
cpan install Linux::Inotify2
It throws the following error:
root#freebsd12sabin:~/.cpan/build/Linux-Inotify2-2.1-6 # make test
"/usr/local/bin/perl" -MExtUtils::Command::MM -e 'cp_nonempty' -- Inotify2.bs blib/arch/auto/Linux/Inotify2/Inotify2.bs 644
PERL_DL_NONLAZY=1 "/usr/local/bin/perl" "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness(0, 'blib/lib', 'blib/arch')" t/*.t
t/00_load.t ..... Can't load '/root/.cpan/build/Linux-Inotify2-2.1-6/blib/arch/auto/Linux/Inotify2/Inotify2.so' for module Linux::Inotify2: /root/.cpan/build/Linux-Inotify2-2.1-6/blib/arch/auto/Linux/Inotify2/Inotify2.so: Undefined symbol "inotify_init" at /usr/local/lib/perl5/5.30/mach/DynaLoader.pm line 193.
at /root/.cpan/build/Linux-Inotify2-2.1-6/blib/lib/Linux/Inotify2.pm line 97.
BEGIN failed--compilation aborted at /root/.cpan/build/Linux-Inotify2-2.1-6/blib/lib/Linux/Inotify2.pm line 97.
Is there anyway I can proceed?
You need to use alternatives that work on the OS.
File::ChangeNotify with IO::KQueue
gamin and Sys::Gamin
Actually, there is devel/libinotify library, which implements inotify interface on FreeBSD via kevent API. So, there might be possible to build this extension.
If you got to Undefined symbol "inotify_init" stage, the only thing left is to install libinotify package and then add proper -l flag to build command line. I'm not familiar with Perl build system, so I can't advise on how to do that.
Inotify is a Linux specific API. You can't use it on FreeBSD (or any other OS not using a Linux kernel) because that kernel doesn't provide those syscalls.
I am trying to compile my led wrapper function program file with including linux/leds.h
using including kernel space header files
gcc -I /usr/src/linux-headers-3.13.0-44-generic/include/ example.c
by compiling it flooded the console with errors in many headers file those are depended on leds.h. Can any one please help me to compile this C file which is using kernel space header files in user space.
Thanks in advance. :)
This won't work.
First of all, don't use kernel-mode headers in user-mode programs, except for the (processed?) ones provided for userspace after kernel compilation. Kernel-mode headers depend on the kernel build system to work.
I tried this, just for curiosity, although I did already knew why it won't work (tl;dr, I use the Ubuntu-patched 3.13.0-24 kernel):
$ cd /usr/src/linux-headers-3.13.0-24/
$ echo '#include <linux/leds.h>' | gcc -E -x c -o - - -Iinclude
The preprocessor claims that <asm/linkage.h> is missing, and, correct me if I'm wrong, that header is generated by the kernel build system.
If you want, you can solve this by creating a kernel module that uses <linux/leds.h> et al, then export a userspace API through the module (usually done through /proc or /sys) and use that API to implement your usermode code's logic.
Hope this helps!
Thanks KemyLand, You were right that we can not use kernel space header file in user space. But your approach couldn't work for me. firstly it asked for asm/linkage.h, i included the path of it explicitly but again compilation terminated on another header file and i did same. But at last i blocked on some errors in headers files, which were not expected as i didn't make any changes in those files. but finally i got the solution. basically we have to do Interfacing functions between kernel space and the hardware device. I had to generate make file for it. obj-m :=file_name.o and compiled it by following command make -C /usr/src/linux-headers-3.13.0-44-generic/ -C /usr/include/ M=pwd modules it generated 4 files file_name.mod.o , file_name.o, file_name.ko, file_name.mod.c. and then loaded the module as root by insmod file_name.ko. for checking the loaded module type command lsmod. I can also execute it by typing command insmod ./file_name.o or can remove by rmmod file_name
In Debian 7 and in Linux Mint 16 I don't get any parameters/options when typing
man insmod
or
insmod --help
But I know there are parameters, e.g insmod --probe
Where can I get complete manpages for my system or which distribution provides complete manpages?
insmod was before provided by the module-init-tools project which has been replaced by the kmod project. The "new" insmod from kmod does not provide this options anymore.
Found a hint on Arch news about the change. This will apply for Debian too:
With module-init-tools being declared a dead project by its current maintainer, a new project has stepped up to take its place: kmod. This is intended to be a drop-in replacement, though deprecated functionality in module-init-tools has not been reimplemented.
The options -p, -s and -f are outdated and now ignored. Long option names for that params aren't valid anymore.
You can check the source code
When running:
sudo /sbin/ldconfig
the following error appears:
/sbin/ldconfig: /usr/local/lib/ is not a symbolic link
When I run the file command, the below appears:
file /usr/local/lib/
/usr/local/lib/: directory
Inside /usr/local/lib/ there are three libraries that I use. I'll call them here as lib1, lib2 and lib3.
Now, when I do an ldd on my binary it results:
lib1.so => not found
lib2.so => not found
lib3.so => /usr/local/lib/lib3.so (0x00216000)
But all of them are in the same folder as /usr/local/lib/{lib1,lib2,lib3}.so.
Every time I run ldconfig, the same error appears:
/usr/local/lib/ is not a symbolic link
I thought /usr/local/lib should be declared twice in /etc/ld.conf.d/*.conf, but not:
sudo egrep '\/usr\/local' /etc/ld.so.conf.d/*
projectA.conf.old:/usr/local/projectA/lib
local.conf:/usr/local/lib
ld.so.conf only includes /etc/ld.so.conf.d/*.conf, so this *.old isn't processed, and it refers to /usr/local/projectA/lib.
After a time trying I deleted all lib1 and lib2 (at some point I tested it on binary's folder), the same error occurs.
I ran into this issue with the Oracle 11R2 client. Not sure if the Oracle installer did this or someone did it here before I arrived. It was not 64-bit vs 32-bit, all was 64-bit.
The error was that libexpat.so.1 was not a symbolic link.
It turned out that there were two identical files, libexpat.so.1.5.2 and libexpat.so.1. Removing the offending file and making it a symlink to the 1.5.2 version caused the error to go away.
Makes sense that you'd want the well-known name to be a symlink to the current version. If you do this, it's less likely that you'll end up with a stale library.
I simply ran the command below:
export LD_LIBRARY_PATH=/usr/lib/
Now it is working fine.
Solved, at least at the point of the question.
I searched in the web before asking, and there were no conclusive solution, the reason why this error is: lib1.so and lib2.so are not OK, very probably where not compiled for a 64 bit PC, but for a 32 bits machine otherwise lib3.so is a 64 bits lib. At least that is my hypothesis.
VERY unfortunately ldconfig doesn't give a clean error message informing that it could not load the library, it only pumps:
ldconfig: /folder_where_the_wicked_lib_is/ is not a symbolic link
I solved this when I removed the libs not found by ldd over the binary. Now it's easier that I know where lies the problem.
My ld version:
GNU ld version 2.20.51, and I don't know if a most recent version has a better message for its users.
Thanks.
You need to include the path of the libraries inside /etc/ld.so.conf, and rerun ldconfig to upate the list
Other possibility is to include in the env variable LD_LIBRARY_PATH the path to your library, and rerun the executable.
check the symbolic links if they point to a valid library ...
You can add the path directly in /etc/ld.so.conf, without include...
run ldconfig -p to see whether your library is well included in the cache.
I have also faced the same issue,
The solution for it is :
the file for which you are getting the error is probably a duplicated file of the actual file with another version. So just the removal of a particular file on which errors are thrown can resolve the issue.
simple run in shell : sudo apt-get install --reinstall libexpat1
got same problem with libxcb - solved in this way - very fast :)
I am compiling a message passing program using openmpi with mpicxx on a Linux desktop. My makefile does the following:
mpicxx -c readinp.cpp
mpicxx -o exp_fit driver.cpp readinp.o
at which point i get the following error:
/usr/lib64/gcc/x86_64-suse-linux/4.5/../../../../x86_64-suse-linux/bin/ld: cannot find -lnuma
My questions are:
what is -lnuma? what is using it? how should i go about linking to it?
Thanks Jonathan Dursi!
On Ubuntu, the package name is libnuma-dev.
apt-get install libnuma-dev
The build script can't find the numa library - NUMA (Non Uniform Memory Access). The -l option tells the linker to link the library, but your system ether doesn't have the right one installed or your search path for the linker is incomplete/wrong.
Try querying your package-manager (apt or rpm) for a package libnuma.
OpenMPI, and I think mpich2, uses libnuma (`a simple programming interface to the NUMA (Non Uniform Memory Access) policy supported by the Linux kernel') for memory affinity -- to ensure that the memory for a particular MPI task stays close to the core that the task is running on, as vs. being kept in cache on another socket entirely. This is important for performance on multicore nodes.
You may need to use YaST to install libnuma-devel if your linker can't find the library.
I got the same error working on a remote server, which had the NUMA library installed. In particular, the file /usr/lib64/libnuma.so.1 existed. It appears that the linker only looked for the file under the name libnuma.so. Creating the symlink
ln -s /usr/lib64/libnuma.so.1 /usr/lib64/libnuma.so
as described here might have worked, but in my case I did not have permission to create files in /usr/lib64. I got around this by creating the symlink in some other location of which I have write permission:
ln -s /usr/lib64/libnuma.so.1 /some/path/libnuma.so
and then add this path to the compilation flags. In your case this would be
mpicxx -L/some/path -o exp_fit driver.cpp readinp.o
In my case of a larger build process (compiling fftw), I added the path to the LDFLAGS environment variable,
export LDFLAGS="${LDFLAGS} -L/some/path"
which fixed the issue.