I'm trying to create a libxerces package for OpenWrt. Following the instructions from this site http://wiki.openwrt.org/doc/devel/packages, I created a folder called libxerces-c inside the packages directory and a simple Makefile to have the package listed on make menuconfig, but it's not happening.
The Makefile is defined as the following:
#
# Copyright (C) 2006-2013 OpenWrt.org
#
# This is free software, licensed under the GNU General Public License v2.
# See /LICENSE for more information.
#
include $(TOPDIR)/rules.mk
# Name and release number of this package
PKG_NAME:=xerces-c
PKG_VERSION:=3.1.1
PKG_RELEASE:=1
PKG_BUILD_DIR:=$(BUILD_DIR)/$(PKG_NAME)-$(PKG_VERSION)
PKG_SOURCE:=$(PKG_NAME)-$(PKG_VERSION).tar.gz
PKG_SOURCE_URL:=http://apache.mirror.pop-sc.rnp.br/apache//xerces/c/3/sources/
PKG_CAT:=zcat
include $(INCLUDE_DIR)/package.mk
# Specify package information for this program.
# The variables defined here should be self explanatory.
define Package/libxerces
SECTION:=libs
CATEGORY:=Libraries
TITLE:=Validating XML parser written in a portable subset of C++.
URL:=http://xerces.apache.org/
endef
define Package/libxerces/description
Xerces-C++ is a validating XML parser written in a portable subset of
C++. Xerces-C++ makes it easy to give your application the ability
to read and write XML data. A shared library is provided for parsing,
generating, manipulating, and validating XML documents. Xerces-C++ is
faithful to the XML 1.0 recommendation and associated standards (DOM
1.0, DOM 2.0, SAX 1.0, SAX 2.0, Namespaces, XML Schema Part 1 and
Part 2). It also provides experimental implementations of XML 1.1
and DOM Level 3.0. The parser provides high performance, modularity,
and scalability.
endef
CONFIGURE_ARGS+= --host=mips-openwrt-linux
define Build/Configure
$(call Build/Configure/Default)
endef
define Build/Compile
$(call Build/Compile/Default)
endef
define Package/libxerces/install
endef
$(eval $(call BuildPackage,libxerces))
I already tried to execute the install script
./scripts/feeds install libxerces-c
But nothing happened. I still can't see the package after executing make menuconfig.
You need to
add the feed with the package to your feeds.conf.default or create a feeds.conf
then ./scripts/feeds update -a (update all feeds... you could just set the feed's name instead of using -a)
then ./scripts/feeds install foobar
[...]
... You obviously called install on libxerces-c while your package is called libxerces?
Probably you are not still searching for it but here is the answer.
For your package to appear in the menuconfig TUI you need to add the following
option to you Makefile inside the define Package clause:
MENU:1
Thus this part of your Makefile will look like:
define Package/libxerces
SECTION:=libs
CATEGORY:=Libraries
TITLE:=Validating XML parser written in a portable subset of C++.
URL:=http://xerces.apache.org/
endef
can you do a make menuconfig, and see if any error message about your package 'libxerces' is shown. My setup for custom packages is something like:
mkdir package/custom
mkdir package/custom/
ln -s /path/to/package/libxerces/ package/custom/
If your makefile is correct, then Libraries->libxerces should appear in menuconfig, if not an error message should be printed on make/make menuconfig. You will be able to do make package/libxerces/compile etc. also. Note: your package name is libxerces not libxerces-c.
Related
I have an autotools project which successfully builds and tests an app (https://github.com/goglecm/AutoBrightnessCam). The app is installed in the bin directory (preceded by any prefix the user specifies). That's pretty straightforward. I now need to make a systemd service to start it at boot time. I've created the service file and ran it manually and it works fine.
The last bit is to tell configure.ac and Makefile.am to patch a *.service.in file with the correct path for the app (just like config.h is created from config.h.in).
Will using AC_CONFIG_HEADERS be appropriate to patch *.service.in into *.service? Is there another macro used for "non-headers" perhaps?
Also, how do I specify that the service file should land (i.e. installed) in /etc/systemd/system?
Is there perhaps a better way of starting this app at boot time without systemd?
How do I specify that the service file should land (i.e. installed) in /etc/systemd/system?
According to Systemd's daemon man page:
<BEGINQUOTE>
Installing systemd Service Files
At the build installation time (e.g. make install during package build), packages are recommended to install their systemd unit files in the directory returned by pkg-config systemd --variable=systemdsystemunitdir (for system services) or pkg-config systemd --variable=systemduserunitdir (for user services). This will make the services available in the system on explicit request but not activate them automatically during boot. Optionally, during package installation (e.g. rpm -i by the administrator), symlinks should be created in the systemd configuration directories via the enable command of the systemctl(1) tool to activate them automatically on boot.
Packages using autoconf(1) are recommended to use a configure script excerpt like the following to determine the unit installation path during source configuration:
PKG_PROG_PKG_CONFIG
AC_ARG_WITH([systemdsystemunitdir],
[AS_HELP_STRING([--with-systemdsystemunitdir=DIR], [Directory for systemd service files])],,
[with_systemdsystemunitdir=auto])
AS_IF([test "x$with_systemdsystemunitdir" = "xyes" -o "x$with_systemdsystemunitdir" = "xauto"], [
def_systemdsystemunitdir=$($PKG_CONFIG --variable=systemdsystemunitdir systemd)
AS_IF([test "x$def_systemdsystemunitdir" = "x"],
[AS_IF([test "x$with_systemdsystemunitdir" = "xyes"],
[AC_MSG_ERROR([systemd support requested but pkg-config unable to query systemd package])])
with_systemdsystemunitdir=no],
[with_systemdsystemunitdir="$def_systemdsystemunitdir"])])
AS_IF([test "x$with_systemdsystemunitdir" != "xno"],
[AC_SUBST([systemdsystemunitdir], [$with_systemdsystemunitdir])])
AM_CONDITIONAL([HAVE_SYSTEMD], [test "x$with_systemdsystemunitdir" != "xno"])
This snippet allows automatic installation of the unit files on systemd machines, and optionally allows their installation even on machines lacking systemd. (Modification of this snippet for the user unit directory is left as an exercise for the reader.)
Additionally, to ensure that make distcheck continues to work, it is recommended to add the following to the top-level Makefile.am file in automake(1)-based projects:
AM_DISTCHECK_CONFIGURE_FLAGS = \
--with-systemdsystemunitdir=$$dc_install_base/$(systemdsystemunitdir)
Finally, unit files should be installed in the system with an automake excerpt like the following:
if HAVE_SYSTEMD
systemdsystemunit_DATA = \
foobar.socket \
foobar.service
endif
...
</ENDQUOTE>
So it appears you should use systemdsystemunitdir and systemduserunitdir. How well Autotools supports it, well...
A quick grep on Fedora 31 using grep systemdsystemunitdir /bin/autoconf and grep -IR systemdsystemunitdir /usr/share shows no Autotools support yet. 7 years and counting...
Is there perhaps a better way of starting this app at boot time without systemd?
Systemd should be OK to start your app. Simply use systemctl(1) to enable and start them as you normally would.
Based on your GitHub and autobrightnesscam.service.in, I would not dick around with Autotools for this. You can waste copious amounts of time working around Autotols short comings (speaking from experience).
My configure.ac script (which is just a shell script) would copy autobrightnesscam.service.in to autobrightnesscam.service, and then use sed to copy-in the correct directories and files. Then, I would copy the updated autobrightnesscam.service to its proper location in AC_CONFIG_COMMANDS_POST. Maybe something like:
SERVICE_FILE=autobrightnesscam.service
SYSTEMD_DIR=`pkg-config systemd --variable=systemdsystemunitdir`
# Use default if SYSTEMD_DIR is empty
if test x"$SYSTEMD_DIR" = "x"; then
SYSTEMD_DIR=/etc/systemd/system
fi
AC_CONFIG_COMMANDS_POST([cp "$SERVICE_FILE" "$SYSTEMD_DIR"])
AC_CONFIG_COMMANDS_POST([systemctl enable "$SYSTEMD_DIR/$SERVICE_FILE"])
AC_CONFIG_COMMANDS_POST([systemctl start "$SERVICE_FILE"])
Will using AC_CONFIG_HEADERS be appropriate to patch *.service.in into *.service? Is there another macro used for "non-headers" perhaps?
No. AC_CONFIG_HEADERS is for setting up configuration headers to support your build. It is rarely used for anything other than building a config.h recording the results of certain tests that Autoconf performs, and it is not as flexible as other options in this area.
If you have additional files that you want Autoconf to build from templates then you should tell Autoconf about them via AC_CONFIG_FILES. Example:
AC_CONFIG_FILES([Makefile AutoBrightnessCam.service])
But if some of the data with which you are filling that template are installation directories then Autoconf is probably not the right place to do this at all, because it makes provision for the installation prefix to be changed by arguments to make. You would at least need to work around that, but the best thing to do is to roll with it instead, and build the .service file under make's control. It's not that hard, and there are several technical advantages, some applying even if there aren't any installation directory substitutions to worry about.
You can do it the same way that configure does, by running the very same template you're already using through sed, with an appropriate script. Something like this would appear in your Makefile.am:
SERVICE_SUBS = \
s,[#]VARIABLE_NAME[#],$(VARIABLE_NAME),g; \
s,[#]OTHER_VARIABLE[#],$(OTHER_VARIABLE),g
AutoBrightnessCam.service: AutoBrightnessCam.service.in
$(SED) -e '$(SERVICE_SUBS)' < $< > $#
Also, how do I specify that the service file should land (i.e.
installed) in /etc/systemd/system?
You use Automake's standard mechanism for specifying custom installation locations. Maybe something like this:
sytemdsysdir = $(sysconfdir)/systemd/system
systemdsys_DATA = AutoBrightnessCam.service
Is there perhaps a better way of
starting this app at boot time without systemd?
On a systemd-based machine, systemd is in control of what starts at boot. If you want the machine to start your application automatically at boot, then I think your options are limited to
Configuring systemd to start it
Configuring something in a chain of programs ultimately started by systemd to start it
Hacking the bootloader or kernel to start it
There is room for diverging opinions here, but I think the first of those is cleanest and most future-proof, and I cannot recommend the last.
How to get CMake to link an executable to an external shared library that is not build within the same CMake project?
Just doing target_link_libraries(GLBall ${CMAKE_BINARY_DIR}/res/mylib.so) gives the error
make[2]: *** No rule to make target `res/mylib.so', needed by `GLBall'. Stop.
make[1]: *** [CMakeFiles/GLBall.dir/all] Error 2
make: *** [all] Error 2
(GLBall is the executable)
after I copied the library into the binary dir bin/res.
I tried using find_library(RESULT mylib.so PATHS ${CMAKE_BINARY_DIR}/res)
Which fails with RESULT-NOTFOUND.
arrowdodger's answer is correct and preferred on many occasions. I would simply like to add an alternative to his answer:
You could add an "imported" library target, instead of a link-directory. Something like:
# Your-external "mylib", add GLOBAL if the imported library is located in directories above the current.
add_library( mylib SHARED IMPORTED )
# You can define two import-locations: one for debug and one for release.
set_target_properties( mylib PROPERTIES IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/res/mylib.so )
And then link as if this library was built by your project:
TARGET_LINK_LIBRARIES(GLBall mylib)
Such an approach would give you a little more flexibility: Take a look at the add_library( IMPORTED) command and the many target-properties related to imported libraries.
I do not know if this will solve your problem with "updated versions of libs".
Set libraries search path first:
link_directories(${CMAKE_BINARY_DIR}/res)
And then just do
target_link_libraries(GLBall mylib)
I assume you want to link to a library called foo, its filename is usually something link foo.dll or libfoo.so.
1. Find the library
You have to find the library. This is a good idea, even if you know the path to your library. CMake will error out if the library vanished or got a new name. This helps to spot error early and to make it clear to the user (may yourself) what causes a problem.
To find a library foo and store the path in FOO_LIB use
find_library(FOO_LIB foo)
CMake will figure out itself how the actual file name is. It checks the usual places like /usr/lib, /usr/lib64 and the paths in PATH.
You already know the location of your library. Add it to the CMAKE_PREFIX_PATH when you call CMake, then CMake will look for your library in the passed paths, too.
Sometimes you need to add hints or path suffixes, see the documentation for details:
https://cmake.org/cmake/help/latest/command/find_library.html
2. Link the library
From 1. you have the full library name in FOO_LIB. You use this to link the library to your target GLBall as in
target_link_libraries(GLBall PRIVATE "${FOO_LIB}")
You should add PRIVATE, PUBLIC, or INTERFACE after the target, cf. the documentation:
https://cmake.org/cmake/help/latest/command/target_link_libraries.html
If you don't add one of these visibility specifiers, it will either behave like PRIVATE or PUBLIC, depending on the CMake version and the policies set.
3. Add includes (This step might be not mandatory.)
If you also want to include header files, use find_path similar to find_library and search for a header file. Then add the include directory with target_include_directories similar to target_link_libraries.
Documentation:
https://cmake.org/cmake/help/latest/command/find_path.html
and
https://cmake.org/cmake/help/latest/command/target_include_directories.html
If available for the external software, you can replace find_library and find_path by find_package.
Let's say you have an executable like:
add_executable(GLBall GLBall.cpp)
If the external library has headers, give the path to its include folder:
target_include_directories(GLBall PUBLIC "/path/to/include")
Add the library directory path:
target_link_directories(GLBall PUBLIC "/path/to/lib/directory")
Finally, link the library name
target_link_libraries(GLBall mylib)
Note that the prefix and extension of the library file are removed:
libmylib.a ➜ mylib
mylib.so ➜ mylib
One more alternative, in the case you are working with the Appstore, need "Entitlements" and as such need to link with an Apple-Framework.
For Entitlements to work (e.g. GameCenter) you need to have a "Link Binary with Libraries"-buildstep and then link with "GameKit.framework". CMake "injects" the libraries on a "low level" into the commandline, hence Xcode doesn't really know about it, and as such you will not get GameKit enabled in the Capabilities screen.
One way to use CMake and have a "Link with Binaries"-buildstep is to generate the xcodeproj with CMake, and then use 'sed' to 'search & replace' and add the GameKit in the way XCode likes it...
The script looks like this (for Xcode 6.3.1).
s#\/\* Begin PBXBuildFile section \*\/#\/\* Begin PBXBuildFile section \*\/\
26B12AA11C10544700A9A2BA \/\* GameKit.framework in Frameworks \*\/ = {isa = PBXBuildFile; fileRef = 26B12AA01C10544700A9A2BA \/\* GameKit.framework xxx\*\/; };#g
s#\/\* Begin PBXFileReference section \*\/#\/\* Begin PBXFileReference section \*\/\
26B12AA01C10544700A9A2BA \/\* GameKit.framework xxx\*\/ = {isa = PBXFileReference; lastKnownFileType = wrapper.framework; name = GameKit.framework; path = System\/Library\/Frameworks\/GameKit.framework; sourceTree = SDKROOT; };#g
s#\/\* End PBXFileReference section \*\/#\/\* End PBXFileReference section \*\/\
\
\/\* Begin PBXFrameworksBuildPhase section \*\/\
26B12A9F1C10543B00A9A2BA \/\* Frameworks \*\/ = {\
isa = PBXFrameworksBuildPhase;\
buildActionMask = 2147483647;\
files = (\
26B12AA11C10544700A9A2BA \/\* GameKit.framework in Frameworks xxx\*\/,\
);\
runOnlyForDeploymentPostprocessing = 0;\
};\
\/\* End PBXFrameworksBuildPhase section \*\/\
#g
s#\/\* CMake PostBuild Rules \*\/,#\/\* CMake PostBuild Rules \*\/,\
26B12A9F1C10543B00A9A2BA \/\* Frameworks xxx\*\/,#g
s#\/\* Products \*\/,#\/\* Products \*\/,\
26B12AA01C10544700A9A2BA \/\* GameKit.framework xxx\*\/,#g
save this to "gamecenter.sed" and then "apply" it like this ( it changes your xcodeproj! )
sed -i.pbxprojbak -f gamecenter.sed myproject.xcodeproj/project.pbxproj
You might have to change the script-commands to fit your need.
Warning: it's likely to break with different Xcode-version as the project-format could change, the (hardcoded) unique number might not really by unique - and generally the solutions by other people are better - so unless you need to Support the Appstore + Entitlements (and automated builds), don't do this.
This is a CMake bug, see http://cmake.org/Bug/view.php?id=14185 and http://gitlab.kitware.com/cmake/cmake/issues/14185
It has been a long time since the question was posted but I am leaving this one just for reference.
I have a blog post describing step-by-step almost what you (or anyone else) were trying to do.
Please check here: https://michae9.wordpress.com/2022/09/01/shared-lib-to-be-used-by-client-programs-with-cmake/
I apologize in advance for my lack of experience with m4sh.
I have a configure.ac file containing the following lines:
AC_INIT([libhelloworld], [2.5])
...
AC_OUTPUT([
Makefile
src/helloworld-${PACKAGE_VERSION}.pc
src/Makefile
])
The reason behind the argument of AC_OUTPUT() is that I would like to avoid to copy and paste the new version of my program in multiple places on every update. Therefore I decided to exploit the PACKAGE_VERSION macro, automatically defined when invoking AC_INIT() at the beginning of configure.ac.
The line src/helloworld-${PACKAGE_VERSION}.pc then correctly expands into src/helloworld-2.5.pc and everything seems to be working fine. However I have a couple of questions.
I use ${PACKAGE_VERSION} as a shell variable, but PACKAGE_VERSION itself is a m4 macro. Can I trust that this will always work? Will it always be defined as such when AC_OUTPUT() is invoked?
Are there other ways of obtaining the value of PACKAGE_VERSION within configure.ac? For example, if instead of configure.ac I were inside Makefile.am I would not use the curly brackets, but the command evaluation syntax instead, as in $(PACKAGE_VERSION). What is the proper correct way of doing what I want within configure.ac?
The documentation for AC_INIT states that PACKAGE_VERSION is an "output variable", meaning when you call AC_INIT, something like this gets executed:
AC_SUBST([PACKAGE_VERSION], [2.5])
This allows the configuration of input files such as Makefile.in (generated from Makefile.am) to rely on #PACKAGE_VERSION# inside those files being replaced by 2.5.
There's nothing wrong with your approach if it works, but you might consider using AS_VAR_SET([hello_version], [AC_PACKAGE_VERSION]) to set the hello_version shell variable and src/helloworld-${hello_version}.pc in Autoconf input. This way, even if Autoconf no longer exposes a PACKAGE_VERSION shell variable in some future release, your code won't break because you'll be relying upon your own hello_version variable.
As an aside, it's a bit irregular to use helloworld-2.5.pc when the helloworld version is 1.0 or greater (i.e. the API is stable). It's common to see helloworld.pc, except then there's the problem of what happens when you release 3.0 and replace the installed 2.x version of helloworld.pc with the 3.0 version: assuming you're using semantic versioning, 3.0 is incompatible with 2.x, and any code relying on something like pkg-config --libs helloworld will break.
You might then consider using helloworld-2.pc instead and when you release 3.0, you'd instead have helloworld-3.pc to avoid users of your library linking the incorrect/incompatible library (and also allowing users the option of moving to the new version at their own pace); one can also apply this idea in Automake for a version-specific header directory:
## SOURCE PATH => INSTALL PATH
## include/hello.h => $(includedir)/helloworld-2/hello.h
helloincludedir = #includedir#/helloworld-#hello_major#
helloinclude_HEADERS = include/hello.h
Autoconf also allows you to specify an output file's inputs, so an output file src/helloworld-${hello_major}.pc in the build directory could be generated from src/helloworld.pc.in in the source directory without you needing to update the src/helloworld.pc.in filename when moving from 2.x to 3.0; this could also be used with AC_INIT if you're OK with macros, allowing you to control the version info in one central location:
m4_define([hello_version_major], [2]) dnl
m4_define([hello_version_minor], [5]) dnl
m4_define([hello_version], [hello_version_major[.]hello_version_minor]) dnl
AC_PREREQ([2.69])
AC_INIT([libhelloworld], [hello_version])
AS_VAR_SET([hello_major], [hello_version_major])
AS_VAR_SET([hello_minor], [hello_version_minor])
# For automake and configuration of pkg-config file
AC_SUBST([hello_major])
AC_SUBST([hello_minor])
AC_SUBST([hello_version])
...
AC_CONFIG_FILES([
Makefile
src/Makefile
src/helloworld-]hello_version_major[.pc:src/helloworld.pc.in
])
AC_OUTPUT
I realize it looks surprisingly more complicated than one might expect, but that's Autoconf for you. Note that I had to use some odd quoting in AC_CONFIG_FILES to make use of the macro. Using
src/helloworld-${hello_major}.pc:src/helloworld.pc.in
instead of the macro resulted in a crippled config.status file being generated in Autoconf 2.69 (try config.status with no arguments, then config.status src/helloworld-2.pc to see the issue); I haven't tested any other versions. I've reported the bug, but the macro works until the next release.
I created my own Frama-C plugin by following the instructions of the Frama-C Development Guide (https://frama-c.com/download/frama-c-plugin-development-guide.pdf).
However, I need to use the Mutex module provided by the Ocaml manual (http://caml.inria.fr/pub/docs/manual-ocaml/libref/Mutex.html) in my .ml files. To use this module, I need a particular command line:
ocamlc -thread unix.cma threads.cma myfiles.ml
(as explained here: OCaml Mutex module cannot be found).
To compile my files I use the Makefile that builds the plugin (Plugin Development Guide page 33). So I'm trying to link these .cma files and the -thread option to this Makefile...and I did not succeed. How can I load this Mutex module?
What I tried:
I looked in the file automatically generated by Frama-C: .Makefile.plugin.generated if there was a variable to call and modify in my Makefile (the same kind as the variable PLUGIN_CMO to call my .ml files) but I did not find such a variable.
I tried with some variables that are defined in the generated .Makefile.plugin.generated this way:
I wrote the following lines in my Makefile:
PLUBIN_EXTRA_BYTE = unix.cma threads.cma
or TARGET_TOP_CMA = unix.cma threads.cma
and for the thread option:
PLUGIN_OFLAGS = -thread
or PLUGIN_LINK_BFLAGS= -thread
or PLUGIN_BFLAGS= -thread
But never was the Mutex module recognized and I don't know exactly if it is a good solution...
Finally, I tested using the Olddynlink module provided by Frama-C (http://arvidj.eu/frama/frama-c-Aluminium-20160501_api/frama-c-api/html/FCDynlink.OldDynlink.html#VALloadfile) with the value loadfile or using the Dynlink module (http://caml.inria.fr/pub/docs/manual-ocaml/libref/Dynlink.html#VALloadfile) and his value loadfile, but it did not work either:
I wrote:
open Dynlink
loadfile "unix.cma";;
loadfile "threads.cma";;
in the .ml file concerned.
But always the same error: Unbound module Mutex.
Section 5.2.3 of the plugin development guide gives the list of variables that can be used to customize the Makefile. Notably, if you want to link against an external library, you can use PLUGIN_EXTRA_BYTE and PLUGIN_EXTRA_OPT, as well as PLUGIN_LINK_BFLAGS and PLUGIN_LINK_OFLAGS to add the -thread option. Here is a Makefile that should work (of course, you need to complete it depending on your actual source files).
ifndef FRAMAC_SHARE
FRAMAC_SHARE:=$(shell frama-c-config -print-share-path)
endif
PLUGIN_NAME:=Test_mutex
PLUGIN_BFLAGS:=-thread
PLUGIN_OFLAGS:=-thread
PLUGIN_EXTRA_BYTE:=$(shell ocamlfind query threads)/threads/threads.cma
PLUGIN_EXTRA_OPT:=$(shell ocamlfind query threads)/threads/threads.cmxa
PLUGIN_LINK_BFLAGS:=-thread
PLUGIN_LINK_OFLAGS:=-thread
PLUGIN_CMO:= # list of modules of the plugin
include $(FRAMAC_SHARE)/Makefile.dynamic
Note that in theory, you should only have to use the PLUGIN_REQUIRES variable, and let ocamlfind take care of everything but threads seems to be a bit peculiar in this respect.
Introduction
I have a do_install task in a BitBake recipe which I've written for a driver where I execute a custom install script. The task fails because the installation script cannot find kernel source header files within <the image rootfs>/usr/src/kernel. This script runs fine on the generated OS.
What's Happening
Here's the relevant part of my recipe:
SRC_URI += "file://${TOPDIR}/example"
DEPENDS += " virtual/kernel linux-libc-headers "
do_install () {
( cd ${TOPDIR}/example/Install ; ./install )
}
Here's a relevant portion of the install script:
if [ ! -d "/usr/src/kernel/include" ]; then
echo ERROR: Linux kernel source include directory not found.
exit 1
fi
cd /usr/src/kernel
make scripts
...
./install_drv pci ${DRV_ARGS}
I checked changing to if [ ! -d "/usr/src/kernel" ], which also failed. install passes different options to install_drv, which I have a relevant portion of below:
cd ${DRV_PATH}/pci
make NO_SYSFS=${ARG_NO_SYSFS} NO_INSTALL=${ARG_NO_INSTALL} ${ARGS_HWINT}
if [ ${ARG_NO_INSTALL} == 0 ]; then
if [ `/sbin/lsmod | grep -ci "uceipci"` -eq 1 ]; then
./unload_pci
fi
./load_pci DEBUG=${ARG_DEBUG}
fi
The make target build: within ${DRV_PATH}/pci is essentially this:
make -C /usr/src/kernel SUBDIRS=${PWD} modules
My Research
I found these comments within linux-libc-headers.inc relevant:
# You're probably looking here thinking you need to create some new copy
# of linux-libc-headers since you have your own custom kernel. To put
# this simply, you DO NOT.
#
# Why? These headers are used to build the libc. If you customise the
# headers you are customising the libc and the libc becomes machine
# specific. Most people do not add custom libc extensions to the kernel
# and have a machine specific libc.
#
# But you have some kernel headers you need for some driver? That is fine
# but get them from STAGING_KERNEL_DIR where the kernel installs itself.
# This will make the package using them machine specific but this is much
# better than having a machine specific C library. This does mean your
# recipe needs a DEPENDS += "virtual/kernel" but again, that is fine and
# makes total sense.
#
# There can also be a case where your kernel extremely old and you want
# an older libc ABI for that old kernel. The headers installed by this
# recipe should still be a standard mainline kernel, not your own custom
# one.
I'm a bit unclear if I can 'get' the headers from the STAGING_KERNEL_DIR properly since I'm not using make.
Within kernel.bbclass provided in the meta/classes directory, there is this variable assigment:
# Define where the kernel headers are installed on the target as well as where
# they are staged.
KERNEL_SRC_PATH = "/usr/src/kernel"
This path is then packaged later within that .bbclass file here:
PACKAGES = "kernel kernel-base kernel-vmlinux kernel-image kernel-dev kernel-modules"
...
FILES_kernel-dev = "/boot/System.map* /boot/Module.symvers* /boot/config* ${KERNEL_SRC_PATH} /lib/modules/${KERNEL_VERSION}/build"
Update (1/21):
A suggestion on the yocto IRC channel was to use the following line:
do_configure[depends] += "virtual/kernel:do_shared_workdir"
which is corroborated by the Yocto Project Reference Manual, which states that in version 1.8, there was the following change:
The kernel build process was changed to place the source in a common shared work area and to place build artifacts separately in the source code tree. In theory, migration paths have been provided for most common usages in kernel recipes but this might not work in all cases. In particular, users need to ensure that ${S} (source files) and ${B} (build artifacts) are used correctly in functions such as do_configure and do_install. For kernel recipes that do not inherit from kernel-yocto or include linux-yocto.inc, you might wish to refer to the linux.inc file in the meta-oe layer for the kinds of changes you need to make. For reference, here is the commit where the linux.inc file in meta-oewas updated.
Recipes that rely on the kernel source code and do not inherit the module classes might need to add explicit dependencies on the do_shared_workdir kernel task, for example:
do_configure[depends] += "virtual/kernel:do_shared_workdir"
But I'm having difficulties applying this to my recipe. From what I understand, I should be able to change the above line to:
do_install[depends] += "virtual/kernel:do_shared_workdir"
Which would mean that the do_install task now must be run after do_shared_workdir task of the virtual/kernel recipe, which means that I should be able to work with the shared workdir (see Question 3 below), but I still have the same missing kernel header issue.
My Questions
I'm using a custom linux kernel (v3.14) from git.kernel.org. which inherits the kernel class. Here are some of my questions:
Shouldn't the package kernel-dev be a part of any recipe which inherits the kernel class? (this section of the variables glossary)
If I add the virtual/kernel to the DEPENDS variable, wouldn't that mean that the kernel-dev would be brought in?
If kernel-dev is part of the dependencies of my recipe, wouldn't I be able to point to the /usr/src/kernel directory from my recipe? According to this reply on the Yocto mailing list, I think I should.
How can I properly reference the kernel source header files, preferably without changing the installation script?
Consider your Environment
Remember that there are different environments within the the build time environment, consisting of:
sysroots
in the case of kernels, a shared work directory
target packages
kernel-dev is a target package, which you'd install into the rootfs of the target system for certain things like kernel symbol maps which are needed by profiling tools like perf/oprofile. It is not present at build time although some of its contents are available in the sysroots or shared workdir.
Point to the Correct Directories
Your do_install runs at build time so this is within the build directory structures of the build system, not the target one. In particular, /usr/src/ won't be correct, it would need to be some path within your build directory. The virtual/kernel do_shared_workdir task populates ${STAGING_DIR_KERNEL} so you would want to change to that directory in your script.
Adding a Task Dependency
The:
do_install[depends] += "virtual/kernel:do_shared_workdir
dependency like looks correct for your use case, assuming nothing in do_configure or do_compile accesses the data there.
Reconsider the module BitBake class
The other answers are correct in the recommendation to look at module.bbclass, since this illustrates how common kernel modules can be built. If you want to use custom functions or make commands, this is fine, you can just override them. If you really don't want to use that class, I would suggest taking inspiration from it though.
Task Dependencies
Adding virtual/kernel to DEPENDS means virtual/kernel:do_populate_sysroot must run before our do_configure task. Since you need a dependency for do_shared_workdir here, a DEPENDS on virtual/kernel is not enough.
Answer to Question 3
The kernel-dev package would be built, however it would then need to be installed into your target image and used at runtime on a real target. You need this at build time so kernel-dev is not appropriate.
Other Suggestions
You'd likely want the kernel-devsrc package for what you're doing, not the kernel-dev package.
I don't think anyone can properly answer that last question here. You are using a non-standard install method: we can't know how to interact with it...
That said, take a look at what meta/classes/module.bbclass does. It sets several related variables for make: KERNEL_SRC=${STAGING_KERNEL_DIR}, KERNEL_PATH=${STAGING_KERNEL_DIR}, O=${STAGING_KERNEL_BUILDDIR}. Maybe your installer supports some of these environment variables and you could set them in your recipe?