Many device driver appear as a kmod-<drivername> rpm package in CentOS/RHEL, and there is always a greylist.txt in these package, with some kernel symbol as its contents. Here are an example:
[root#localhost download]# rpm -ql kmod-qed
/etc/depmod.d/qed.conf
/lib/modules/3.10.0-327.36.2.el7.x86_64
/lib/modules/3.10.0-327.36.2.el7.x86_64/extra
/lib/modules/3.10.0-327.36.2.el7.x86_64/extra/qed
/lib/modules/3.10.0-327.36.2.el7.x86_64/extra/qed/qed.ko
/usr/share/doc/kmod-qed/greylist.txt
[root#localhost download]# cat /usr/share/doc/kmod-qed/greylist.txt
bitmap_clear
bitmap_set
__fentry__
ioremap_wc
pci_enable_msi_range
pci_enable_msix_range
pci_ioremap_bar
pci_is_pcie
pci_read_config_byte
pci_read_config_word
pci_save_state
release_firmware
request_firmware
__smp_mb__after_atomic
__stack_chk_fail
synchronize_irq
tasklet_init
__tasklet_schedule
vzalloc
x86_dma_fallback_dev
zlib_inflate
zlib_inflateEnd
zlib_inflateInit2
zlib_inflate_workspacesize
I guess it must have something to do with the kernel ABI whitelist, but what exactly is the purpose of this greylist file? and how was it generated while packaging the kmod rpm.
Thanks.
In the absence of a better answer I can tell you that since it is under /usr/share/doc it should just be documentation and nothing of consequence. I wish I could tell you the purpose and how it was generated. I can only see that it was not generated during packaging. You can see in the Spec file that it is included as a static source. (Grab the SRPM and have a look.)
Related
I am trying to make a .pc file and want to define a flag ldflags and use it something like this
pkg-config package --ldflags
but it's showing unknown option ldflags.
Is there a way to define my own option in pc file.
.pc file has special format, check here:
The file format contains predefined metadata keywords and freeform
variables.
keywords are fixed, e.g. Cflags and most of them correspond to pkg-config tool options e.g. --cflags. But variables:
... can be used by the keyword definitions for flexibility or to store
data not covered by pkg-config
So, it possible to add own, for example I created minimum possible one (Name, Version, Description are mandatory keywords):
$ cat test.pc
Name: test
Version: 1
Description: test
aaa=bbb
$ pkg-config --variable=aaa
bbb
It's possible to list all with --print-variables option (interestingly though that pcfiledir variable is added automatically):
$ pkg-config --print-variables test.pc
aaa
pcfiledir
$ pkg-config --variable=pcfiledir
.
It can even (re)define one variable using another:
$ cat test.pc
Name: test
Version: 1
Description: test
aaa=bbb${ccc}
$ pkg-config test.pc --variable=aaa --define-variable=ccc=xxx
bbbxxx
Wonder about your use case? since contents of this file is just for keeping metadata about dependencies some package has. Maybe you should add instead these flags to Libs or Libs.private keywords?
I am a yocto noob, trying to decipher how the device tree is built from a Xilinx hardware definition (.hdf) file. But my question is more general.
Is there a yocto way to find the source of task?
Given a task name is it possible to find where the tasks source code lives? (presumably in a recipe or class)
As an example, where is the source for the Python task do_create_yaml which is called by recipes in the meta-xilinx-bsp layer that compile the device tree blob?
bitbake -e device-tree
Will dump the python source for do_create_yaml (amongst the rest of it prodigious output) but how can I find where that is coming from?
Device tree is part of Linux Kernel. In Yocto, this is compiled from KERNEL_DEVICETREE variable value either defined as part of Linux Kernel recipe or machine configuration.
For example, for cubieboard7 as defined here,
KERNEL_DEVICETREE = "s700_cb7_linux.dtb"
instructs the compilation to use this dts file for compilation. This is done by yocto by using various classes.
In our example, we inherit kernel.bbclass which in turn inherits kernel-devicetree.bbclass, in this class (copied from kernel-devicetree.bbclass),
do_compile_append() {
for dtbf in ${KERNEL_DEVICETREE}; do
dtb=`normalize_dtb "$dtbf"`
oe_runmake $dtb
done
}
do_install_append() {
for dtbf in ${KERNEL_DEVICETREE}; do
dtb=`normalize_dtb "$dtbf"`
dtb_ext=${dtb##*.}
dtb_base_name=`basename $dtb .$dtb_ext`
dtb_path=`get_real_dtb_path_in_kernel "$dtb"`
install -m 0644 $dtb_path ${D}/${KERNEL_IMAGEDEST}/$dtb_base_name.$dtb_ext
done
}
do_deploy_append() {
for dtbf in ${KERNEL_DEVICETREE}; do
dtb=`normalize_dtb "$dtbf"`
this appends tasks to compile, install and deploy tasks. So defining KERNEL_DEVICETREE enables the automatic build of dtb.
I found that the datastore contains the filename for tasks as a VarFlag,
from a devpyshell
pydevshell> d.getVarFlags("do_create_yaml")
gives
{'filename': '.....yocto/sources/core/../meta-xilinx-tools/classes/xsctyaml.bbclass', 'lineno': '61', 'func': 1, 'task': 1, 'python': '1', 'deps': ['do_prepare_recipe_sysroot']}
So for the example in my question the active definition for the do_create_yaml task is in xsctyaml.bbclass.
EDIT: Solution was "apt-get install libwww-per" from charlesbridge in the comments
EDIT: Attempted to install by both going into the cpan console and running install LWP::Simple as well as perl -MCPAN -e'install "LWP::Simple"' (from here).
The first time I ran CPAN I just let it configure itself with all the defaults. The below is not a description of the dependencies but all of the missing dependencies are included in this warning message, so I figure if I can solve that then I can solve the rest of it.
Original post:
I've been trying to install some missing Perl packages (namely LWP::Simple) but every time I do it spits back a trillion errors and ends with "Missing 17 dependencies". Most (if not all) are listed below at the very start of the install process. I've tried installing individual ones but I get similar dependency errors. Is there some way to fix this?
Checking if your kit is complete...
Warning: the following files are missing in your kit:
eg/hanchors
eg/hdump
eg/hform
eg/hlc
eg/hrefsub
eg/hstrip
eg/htext
eg/htextsub
eg/htitle
hints/solaris.pl
lib/HTML/Entities.pm
lib/HTML/Filter.pm
lib/HTML/HeadParser.pm
lib/HTML/LinkExtor.pm
lib/HTML/PullParser.pm
lib/HTML/TokeParser.pm
t/api_version.t
t/argspec-bad.t
t/argspec.t
t/argspec2.t
t/attr-encoded.t
t/callback.t
t/case-sensitive.t
t/cases.t
t/comment.t
t/crashme.t
t/declaration.t
t/default.t
t/document.t
t/dtext.t
t/entities.t
t/entities2.t
t/filter-methods.t
t/filter.t
t/handler-eof.t
t/handler.t
t/headparser-http.t
t/headparser.t
t/ignore.t
t/largetags.t
t/linkextor-base.t
t/linkextor-rel.t
t/magic.t
t/marked-sect.t
t/msie-compat.t
t/offset.t
t/options.t
t/parsefile.t
t/parser.t
t/plaintext.t
t/pod.t
t/process.t
t/pullparser.t
t/script.t
t/skipped-text.t
t/stack-realloc.t
t/textarea.t
t/threads.t
t/tokeparser.t
t/uentities.t
t/unbroken-text.t
t/unicode-bom.t
t/unicode.t
t/xml-mode.t
Please inform the author.
I have been doing a project that has many classes (including cpp and header files) and one executable cpp that has int main. With ROS, I'm trying to link these with CMakeLists.txt and with the runtime, I'm planning to compile it without having to change the txt every time. Here is my CMakeLists.txt:
cmake_minimum_required(VERSION 2.4.6)
include($ENV{ROS_ROOT}/core/rosbuild/rosbuild.cmake)
rosbuild_init()
set(EXECUTABLE_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/bin)
set(LIBRARY_OUTPUT_PATH ${PROJECT_SOURCE_DIR}/lib)
rosbuild_add_library(${PROJECT_NAME} Im_Basibos.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_HedefeGitme.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Konum.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Robot.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Sonar.cpp)
rosbuild_add_executable(srctest Im_RobotKontrol.cpp)
I dont know how to link the header files, I have to link these:
Im_Basibos.h, Im_Basibos.cpp
Im_HedefeGitme.h, Im_HedefeGitme.cpp
Im_Konum.h, Im_Konum.cpp
Im_Robot.h, Im_Robot.cpp
Im_Sonar.h, Im_Sonar.cpp
and
Im_Robot.cpp that has int main()
Any answer will be much appreciated. Thanks already..
I guess rosbuild_add_library works the same than add_library and is not meant to works the way you're using it. It's meant to create static or shared libraries, not to build object files.
I'm giving you two possible ways to build your executable.
version 1
If you only need to build an executable srctest and no separate library.
What you need to do is to list your source files in some variables, say srctest_SOURCES:
set(srctest_SOURCES Im_Basibos.cpp Im_HedefeGitme.cpp
Im_Konum.cpp Im_Robot.cpp Im_Sonar.cpp
Im_RobotKontrol.cpp)
Then build those sources into an executable:
add_executable(srctest ${srctest_SOURCES})
version 2
Now, if you really want to first build a library, say testlib then link it to your srctest executable, that can be done too:
set(testlib_SOURCES Im_Basibos.cpp Im_HedefeGitme.cpp
Im_Konum.cpp Im_Robot.cpp Im_Sonar.cpp)
add_library(testlib ${srctest_SOURCES})
add_executable(srctest Im_RobotKontrol.cpp)
target_link_libraries(srctest testlib)
Thanks to Guillaume for the methods,
Since I'm working with ROS environment,
the exact commands that did the trick were:
rosbuild_add_library(${PROJECT_NAME} Im_Basibos.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_HedefeGitme.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Konum.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Robot.cpp)
rosbuild_add_library(${PROJECT_NAME} Im_Sonar.cpp)
rosbuild_add_executable(srctest Im_RobotKontrol.cpp)
target_link_libraries(srctest ${PROJECT_NAME})
I'm trying to build a very simple PostgreSQL client in C over Cygwin.
Here's what I've done so far:
I've downloaded the PostgreSQL source code version 9.1.2 (to match the same version that is running on my server)
I've configured and compiled the source code from Cygwin. The compilation seemed to go smoothly.
From what I can tell, the header files are in:
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq, and
/cygdrive/c/workspace/src/postgresql-9.1.2/src/include
The libraries are in:
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
From here, I compiled and linked the client program using the makefile below:
testlibpq: testlibpq.c
gcc -o testlibpq -I /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq -I /cygdrive/c/workspace/src/postgresql-9.1.2/src/include -L /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq testlibpq.c -Bstatic -lpq
The compilation and the linking succeeded without errors or warnings.
However, when I try to run the program, I get the following error:
$ ./testlibpq
/cygdrive/c/Users/dleclair/Dropbox/denis/src/testlibpq/testlibpq.exe: error while loading shared libraries: cygpq.dll: cannot open shared object file: No such file or directory
I haven't figured out how to fix this. Any pointers would be greatly appreciated.
Oh, one more thing, I found the folder that cygpq.dll was sitting in and set my LD_LIBRARY_PATH to point to it but it still gave me the same result.
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
$ ls /cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
bcc32.mak encnames.o fe-connect.o fe-misc.o fe-protocol3.o ip.o libpq-events.c md5.c pgstrcasecmp.c pqsignal.c thread.o
blibpqdll.def exports.txt fe-exec.c fe-print.c fe-secure.c libpq.a libpq-events.h md5.o pgstrcasecmp.o pqsignal.h wchar.c
chklocale.c fe-auth.c fe-exec.o fe-print.o fe-secure.o libpq.rc.in libpq-events.o nls.mk po pqsignal.o wchar.o
chklocale.o fe-auth.h fe-lobj.c fe-protocol2.c inet_net_ntop.c libpqddll.def libpq-fe.h noblock.c pqexpbuffer.c pthread-win32.c win32.c
cygpq.dll fe-auth.o fe-lobj.o fe-protocol2.o inet_net_ntop.o libpq-dist.rc libpq-int.h noblock.o pqexpbuffer.h README win32.h
encnames.c fe-connect.c fe-misc.c fe-protocol3.c ip.c libpqdll.def Makefile pg_service.conf.sample pqexpbuffer.o thread.c win32.mak
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
$ echo $LD_LIBRARY_PATH
/cygdrive/c/workspace/src/postgresql-9.1.2/src/interfaces/libpq
dleclair#dleclair-win7l ~/Dropbox/denis/src/testlibpq
Normally on unix/linux systems after building the source a make install is done which copies the headers to standard locations like /usr/local/include and /usr/local/lib. You may have to do that on cygwin to to get the DLL in the search path.
Or you can just locate the DLL yourself and put it on the search path or in the same folder as your executable.