arch_vma_name undefined kernel module - memory-management

I am getting following error when i try to insert a module
insmod: error inserting 'memory.ko': -1 Unknown symbol in module
Following happens when i make the module
make -C /lib/modules/2.6.32-279.19.1.el6.x86_64/build SUBDIRS=/work modules
make[1]: Entering directory `/usr/src/kernels/2.6.32-279.19.1.el6.x86_64'
Building modules, stage 2.
MODPOST 1 modules
WARNING: "arch_vma_name" [/work/memory.ko] undefined!
make[1]: Leaving directory `/usr/src/kernels/2.6.32-279.19.1.el6.x86_64'
You can see the reason of the error is arch_vma_name
Here is chunk of code where i used it
const char *name = arch_vma_name(vma);
I have included the header file
#include <linux/mm.h>
I am not able to understand the reason.

Related

ld: arch/x86/entry/syscall_64.o:(.rodata+0xe08): undefined reference to `__x64_sys_pid' make: *** [Makefile:1183: vmlinux] Error 1

I am trying to add a system call to Linux kernel. After executing the command "make -j[nproc]" this error is encountered.
Following are the commands executed:
vim hello/hello.c
in this: SYSCALL_DEFINE1(hello,int, id){...}
Created a Makefile
Added hello/ to kernel/ certs/ mm/ fs/ ipc/ security/ crypto/ block/ hello/ to main Makefile
In include/linux/syscalls.h added- asmlinkage long sys_hello(int id);
In arch/x86/entry/syscalls/syscall_64.tbl added- 442 common hello sys_hello
make menuconfig
In make -j2 I am getting above error

linux kernel compilation: ERROR: "function" [path/to/module/module.ko] undefined

I have a similar problem to this one, only for me it's an error not a warning. I'm building linux-4.8.5 with a patch applied to one module. I get:
ERROR: "intel_soc_pmic_readb" [drivers/gpu/drm/i915/i915.ko] undefined!
ERROR: "intel_soc_pmic_writeb" [drivers/gpu/drm/i915/i915.ko] undefined!
scripts/Makefile.modpost:91: recipe for target '__modpost' failed
make[1]: *** [__modpost] Error 1
Makefile:1201: recipe for target 'modules' failed
make: *** [modules] Error 2
In the other question they say something about KBUILD_EXTRA_SYMBOLS and documentation is supposed to be in Documentation/kbuild/modules.txt. But reading this file, this seems only to apply to modules not included in linux itself?
The functions are defined like
int function(){
do_stuff;
}
EXPORT_SYMBOL(function);
then there is the declaration
int function();
in a .h file in the include folder and it's called like
#include <the_aforementioned_file.h>
//stuff
function();
from a file in the same folder as the definition of the function. There are no other occurrences of the function name in the whole source tree.
And I really just don't see the mistake. Most likely I'm not looking in the right place, I guess.
As explained in a comment by Tsyvarev, this error is caused because the module in question is not being built, it requires the option CONFIG_INTEL_SOC_PMIC.

Rnnlib installation range error

I am installing rnnlib through https://github.com/meierue/RNNLIB
After installing the boost and other and completing other steps I am getting the error- SeqBuffer.hpp:227: error: reference to ‘range’ is ambiguous
Helpers.hpp:298: error: candidates are: template<class T> std::pair<boost::iterators::counting_iterator<Incrementable, boost::iterators::use_default, boost::iterators::use_default>, boost::iterators::counting_iterator<Incrementable, boost::iterators::use_default, boost::iterators::use_default> > range(const T&, const T&)
Makefile:223: recipe for target 'DataExporter.o' failed
make[2]: *** [DataExporter.o] Error 1
make[2]: Leaving directory '/home/adminhp/Himaanshu/RNNLIB-master/src'
Makefile:217: recipe for target 'all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory '/home/adminhp/Himaanshu/RNNLIB-master'
Makefile:155: recipe for target 'all' failed
make: *** [all] Error 2
using namespace strikes again.
Helpers.hpp contains the following damning sequence:
using namespace std;
using namespace boost;
using namespace boost::assign;
using namespace boost::posix_time;
using namespace boost::gregorian;
Frankly, at this point I'd give up. Especially the first two lines are the moral equivalent of carpet bombing. With napalm.¹
UPDATE Created a pull request with the changes required to make the code compile.
To further compound the problem, RNNLIB's range facility is not even in a namespace...
So, the upshot is that range collides with the namespace from boost.
The simplest way to remove the clash is to qualify all the loopy uses of range as ::range...
PS. same comes up with equal later on
¹ Why is "using namespace std" considered bad practice?

geoCouch install: compiling failed

I have trouble with including geoCouch to running couchDB (1.6.1).
I followed the Instruction: https://github.com/couchbase/geocouch/#for-apache-couchdb
In the GeoCouch directory ($HOME/geocouch) I tried to compile:
COUCH_SRC=$HOME/apache-couchdb-1.6.1/src/couchdb make couchdb
and get the message:
/rebar -C rebar_couchdb.config compile
==> vtree (compile)
Compiling /home/ec2-user/geocouch/vtree/src/vtree_cleanup.erl failed:
/home/ec2-user/geocouch/vtree/src/vtree_cleanup.erl:16: can't find include file "couch_db.hrl"
/home/ec2-user/geocouch/vtree/src/vtree_cleanup.erl:41: undefined macro 'LOG_DEBUG/2'
/home/ec2-user/geocouch/vtree/src/vtree_cleanup.erl:18: function cleanup/2 undefined
/home/ec2-user/geocouch/vtree/src/vtree_cleanup.erl:26: spec for undefined function vtree_cleanup:cleanup/2
/home/ec2-user/geocouch/vtree/src/vtree_cleanup.erl:47: function cleanup_multiple/3 is unused
/home/ec2-user/geocouch/vtree/src/vtree_cleanup.erl:54: function cleanup_nodes/2 is unused
/home/ec2-user/geocouch/vtree/src/vtree_cleanup.erl:62: function member_of_nodes/2 is unused
/home/ec2-user/geocouch/vtree/src/vtree_cleanup.erl:75: function partition_nodes/3 is unused
"couch_db.hrl" is located in /home/ec2-user/apache-couchdb-1.6.1/src/couchdb
Does anyone know how to fix that? Help/idea?

Veins file can't find other Veins file - no such file or directory

I want to use TraCIMobility.h from Veins to change some SUMO variables for visualization.
I receive an error, when building my project. TraCIMobility.h can't find BaseMobility.h, which is also part of Veins. Are there some problems inside the Veins project? I built it one more time, but it can't find its own modules. I added Veins to my project with Project->Properties->Project References.
This is the error:
10:12:16 **** Incremental Build of configuration gcc-debug for project CloudBasedCSW ****
make MODE=debug CONFIGNAME=gcc-debug all
cd src && make
make[1]: Entering directory `/c/work/Cloud_Curve_Speed_Warning/trunk/src/CloudBasedCSW/src'
visualization/Visualization.cc
In file included from ./visualization/Visualization.h:19:0,
from visualization/Visualization.cc:16:
C:/Tools/veins/src/veins-3.0/src/modules/mobility/traci /TraCIMobility.h:31:26: fatal error: BaseMobility.h: No such file or directory
make[1]: Leaving directory `/c/work/Cloud_Curve_Speed_Warning/trunk/src/CloudBasedCSW/src'
compilation terminated.
make[1]: *** [../out/gcc-debug/src/visualization/Visualization.o] Error 1
make: *** [all] Error 2
10:12:17 Build Finished (took 726ms)
This is the header, which includes TraCiMobility.h
#ifndef VISUALIZATION_H_
#define VISUALIZATION_H_
#include <omnetpp.h>
#include "modules/mobility/traci/TraCIMobility.h"
class Visualization: public cSimpleModule{
public:
Visualization();
virtual ~Visualization();
void initialize();
void handleMessage(cMessage *msg);
void setIce(std::string laneId);
void removeIce(std::string laneId);
};
#endif /* VISUALIZATION_H_ */
You didn't say which Veins version you are using, so I am assuming the newest, Veins 4a2. Here, you will need to specify the include path like so
#include "veins/modules/mobility/traci/TraCIMobility.h"
To clarify: the --meta:auto-include-path option to opp_makemake will always generate a -I include path that includes all of the missing components to make the include work (that is, writing as little as #include "traci/TraCIMobility.h" would yield a compiler flag of -I..../veins/src/veins/modules/mobility), but without adding a -I include path to the root of Veins, none of the includes within work. By specifying the full path to the file (relative to the source root of Veins), you are forcing opp_makemake to generate a -I include path of -I..../veins/src, which is what is needed to build Veins.

Resources