I am trying to use the OV5640 camera driver as a module in yocto. So I took the .c code and made a makefile (based on the example hello-mod)
obj-m += OV5640.o
SRC := $(shell pwd)
all:
$(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules
modules_install:
$(MAKE) -C $(KERNEL_SRC) M=$(SRC) modules_install
clean:
$(MAKE) -C $(KERNEL_SRC) M=$(SRC) clean
I also made a recipe in yocto
DESCRIPTION = "..."
LICENSE = "GPL-2.0"
LIC_FILES_CHKSUM = "\
file:// ${COMMON_LICENSE_DIR}/GPL-2.0;md5=801f80980d171dd6425610833a22dbe6 \
"
inherit module
SRCREV = "${AUTOREV}"
BPV = "0.0.0"
PV = "${BPV}+git${SRCREV}"
SRC_URI = "git://git/my-repo;protocol=ssh;user=git;branch=master \
"
S = "${WORKDIR}/git"
In the git repo I have the .c code of the camera and the Makefile.
But when I try to build, it fails on do_compile and says:
fatal error: v4l2-int-device.h: No such file or directory
When I search on the file in the 'tmp' folder of yocto I find one in:
tmp/work-shared/myboard/kernel-source/drivers/media/platform/mxc/capture/v4l2-int-device.h
The question is, How can I modify the recipe to be able to build the module without changing the source code or the makefile?
Note:
I also tried to add snippet below to the recipe but this gave no succes.
CFLAGS_prepend = " -I${STAGING_KERNEL_DIR}/drivers/media/platform/mxc/capture "
You need to modify your Makefile and add:
ccflags-y += -I$(KERNEL_SRC)/drivers/media/platform/mxc/capture/
You can also try to compile it out of the tree, you need to set the variable KERNEL_SRC, source your environment, and compile it.
Related
I am new to Yocto and cmake. After looking and searching on internet I was able to make my own recipe and was able to successfully compile the code using cmake from Yocto recipe.
But the binary compiled and generated is in the build folder where the code source files reside. How do I copy over the binaries from the build folder to the custom file system path when the image is generated using Yocto.
My .bb file currently looks like this:
#
# This file is the pscode recipe.
#
SUMMARY = "Simple test application"
SECTION = "PETALINUX/apps"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://src/* \
file://include/* \
file://CMakeLists.txt\
"
S = "${WORKDIR}"
do_configure() {
cmake ../
}
inherit pkgconfig cmake
do_install() {
install -d ${D}/home/first
cp -r ${WORKDIR} ${D}/home/first
#install -m 0755 ${S} ${D}/home/first
}
FILES_${PN} += "/home/first"
This runs into error
cp: cannot copy a directory <path-to-the-test-folder-in-temp> into itself, <path-to-the-test-folder-in-temp/image/home/first>
Can I someone please guide me. Thank you in advance.
Like the comments suggested:
SUMMARY = "Simple test application"
SECTION = "PETALINUX/apps"
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
SRC_URI = "file://src/* \
file://include/* \
file://CMakeLists.txt \
"
S = "${WORKDIR}"
inherit pkgconfig cmake
If the CMakeLists.txt uses the install command then bitbake will do the install for you and you won't need to define you own do_install. see cmake-documentation-install for details. Here the example for binaries:
install(TARGETS <your cmake target> DESTINATION bin)
From cmake install documentation:
If a full path (with a leading slash or drive letter) is given it is
used directly. If a relative path is given it is interpreted relative
to the value of the CMAKE_INSTALL_PREFIX variable.
I am using a Yocto recipe to build a cmake project. In the Yocto enviroment, I confirmed that --sysroot=my-app/recipe-sysroot and all dependent libraries have been installed into that location. In my CMakeList.txt, I set link_directories(/usr/lib), but error messages occur while building to indicate the dependent libraries cannot be found.
Does anyone know how to pass the Yocto sysroot environment to cmake?
My recipe,
inherit cmake
DEPENDS = "\
azure-iot-sdk-c \
openssl \
zlib \
curl \
boost \
parson \
gtest \
"
S = "${WORKDIR}/git"
B = "${WORKDIR}/build"
EXTRA_OECMAKE = "\
-DCMAKE_BUILD_TYPE=Debug \
-DBUILD_SAMPLES=ON \
-DBUILD_TESTS=ON \
-DBUILD_TOOLS=ON \
"
FILES_${PN}-staticdev = "${libdir}/*.a"
FILES_${PN} += "${libdir}/*.so"
FILES_SOLIBSDEV = ""
INSANE_SKIP_${PN} += "dev-so rpaths"
And if I set the real path in my CMakeList, it works,
set(LIBRARY_DIR "${CMAKE_CURRENT_LIST_DIR}/../recipe-sysroot/usr/lib")
set(STATIC_LIBRARY ${LIBRARY_DIR}/libiothub_client.a)
But if I set the related path according to sysroot, it does not work,
set(LIBRARY_DIR "/usr/lib")
Don't do:
set(LIBRARY_DIR "${CMAKE_CURRENT_LIST_DIR}/../recipe-sysroot/usr/lib")
It is usually not necessary to have any yocto specific information in your cmake. Instead add
include(GNUInstallDirs)
In your recipe add:
inherit cmake
If your cmake installs the static library and headers correctly e.g.:
install (TARGETS <yourtarget> DESTINATION ${CMAKE_INSTALL_LIBDIR})
file(GLOB HEADERS include/*.h)
install(FILES ${HEADERS} DESTINATION ${CMAKE_INSTALL_INCLUDEDIR})
My above advice should work, if you not install the static library using cmake you have to define an do_install task in your package recipe. For example
do_install() {
install -m 0755 -d ${D}${libdir}
install -m 0755 ${B}/test-staticlibrary.a ${D}/${libdir}
}
If you post your cmake files I can assist you further
I am trying to build a very simple Makefile, that intends to use a homemade library (libf904QC.a) made of Fortran modules. The library is in /usr/local/lib64 whereas the corresponding .mod files are in /usr/local/include/f904QC
Here is the Makefile
# Makefile
NAME=NPManip
FFLAGS= -ffpe-trap=overflow -c -O3
LFLAGS=
PATH2LIB=/usr/local/lib64/
INCLUDEDIR=/usr/local/include/f904QC/
#
LIB=-L$(PATH2LIB) -I$(INCLUDEDIR) -lf904QC.a
OBJS = \
tools_NPManip.o\
NPManip.o
%.o: %.f90
gfortran $(LIB) $(FFLAGS) $*.f90
NPM: $(OBJS)
gfortran $(LFLAGS) $(OBJS) $(LIB) -o $(NAME)
clean:
#if test -e $$HOME/bin/$(NAME); then \
rm $$HOME/bin/$(NAME); \
fi
rm *.o *.mod
mrproper: clean
rm $(NAME)
install:
ln -s $(shell pwd)/$(NAME) $$HOME/bin/.
I get the following error message :
gfortran tools_NPManip.o NPManip.o -L/usr/local/lib64/ -I/usr/local/include/f904QC/ -lf904QC.a -o NPManip
/usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/ld: cannot find -lf904QC.a
collect2: error: ld returned 1 exit status
make: * [NPM] Erreur 1
Where is the mistake? It is not obvious to me since libf904QC.o is actually located in /usr/local/lib64, which is defined by the -L option.
Thnak you for your help
You should specify either the full path to the library /usr/local/lib64/libf904QC.a or alternatively -L/usr/local/lib64 -lf90QC, without the .a in that case. From man ld:
-l namespec
--library=namespec
Add the archive or object file specified by namespec to the list of files to link. This option may be used any number of
times. If namespec is of the form :filename, ld will search the library path for a file called filename, otherwise it
will search the library path for a file called libnamespec.a.
-L searchdir
--library-path=searchdir
Add path searchdir to the list of paths that ld will search for archive libraries and ld control scripts. You may use
this option any number of times. The directories are searched in the order in which they are specified on the command
line. Directories specified on the command line are searched before the default directories. All -L options apply to
all -l options, regardless of the order in which the options appear. -L options do not affect how ld searches for a
linker script unless -T option is specified.
I'm coming from a Objective-C/Xcode background.
I'm used to working with C projects already imported into XCode, but now I want to analyse an existing implementation of an algorithm I'm interested in integrating with my project.
Only that this project is written completely in C and has nothing to do with Objective-C/Xcode etc.
I'm not sure what is the best way to view a purely C project on Mac, so I installed NetBeans for C/C++.
The problem is that when I try to create a New Project on NetBeans and select C/C++ Project with Existing Sources it complains that
no make files or configure scripts were found
in the root directory.. although it clearly has a Makefile.am
I know that the Balsa project is written for linux, but I'm not interested in building the binary I just want to look at the source code in a IDE kinda way (ie I can click on a function call and see where it's implemented etc etc).
So in short my question is why isn't NetBeans recognising my Makefile.am?
and just for reference here is the content of the Makefile.am
#intl dir needed for tarball --disable-nls build.
DISTCHECK_CONFIGURE_FLAGS=--disable-extra-mimeicons --without-gnome --without-html-widget
SUBDIRS = po sounds images doc libbalsa libinit_balsa src
# set tar in case it is not set by automake or make
man_MANS=balsa.1
pixmapdir = $(datadir)/pixmaps
pixmap_DATA = gnome-balsa2.png
desktopdir = $(datadir)/applications
desktop_in_files = balsa.desktop.in balsa-mailto-handler.desktop.in
desktop_DATA = balsa.desktop balsa-mailto-handler.desktop
#INTLTOOL_DESKTOP_RULE#
balsa_extra_dist = \
GNOME_Balsa.server.in \
HACKING \
balsa-mail-style.xml \
balsa-mail.lang \
balsa.1.in \
balsa.spec.in \
bootstrap.sh \
docs/mh-mail-HOWTO \
docs/pine2vcard \
docs/vconvert.awk \
$(desktop_in_files) \
gnome-balsa2.png \
intltool-extract.in \
intltool-merge.in \
intltool-update.in \
mkinstalldirs
if BUILD_WITH_G_D_U
balsa_g_d_u_extra_dist = gnome-doc-utils.make
endif
if !BUILD_WITH_UNIQUE
serverdir = $(libdir)/bonobo/servers
server_in_files = GNOME_Balsa.server
server_DATA = $(server_in_files:.server.in=.server)
$(server_in_files): $(server_in_files).in
sed -e "s|\#bindir\#|$(bindir)|" $< > $#
endif
EXTRA_DIST = \
$(balsa_extra_dist) \
$(balsa_g_d_u_extra_dist)
if BUILD_WITH_GTKSOURCEVIEW2
gtksourceviewdir = $(BALSA_DATA_PREFIX)/gtksourceview-2.0
gtksourceview_DATA = balsa-mail.lang \
balsa-mail-style.xml
endif
DISTCLEANFILES = $(desktop_DATA) $(server_DATA) \
intltool-extract intltool-merge intltool-update \
gnome-doc-utils.make
dist-hook: balsa.spec
cp balsa.spec $(distdir)
#MAINT#RPM: balsa.spec
#MAINT# rm -f *.rpm
#MAINT# $(MAKE) distdir="$(PACKAGE)-#BALSA_VERSION#" dist
#MAINT# cp $(top_srcdir)/rpm-po.patch $(top_builddir)/rpm-po.patch
#MAINT# rpm -ta "./$(PACKAGE)-#BALSA_VERSION#.tar.gz"
#MAINT# rm $(top_builddir)/rpm-po.patch
#MAINT# -test -f "/usr/src/redhat/SRPMS/$(PACKAGE)-#VERSION#-#BALSA_RELEASE#.src.rpm" \
#MAINT# && cp -f "/usr/src/redhat/SRPMS/$(PACKAGE)-#VERSION#-#BALSA_RELEASE#.src.rpm" .
#MAINT# -for ping in /usr/src/redhat/RPMS/* ; do \
#MAINT# if test -d $$ping ; then \
#MAINT# arch=`echo $$ping |sed -e 's,/.*/\([^/][^/]*\),\1,'` ; \
#MAINT# f="$$ping/$(PACKAGE)-#VERSION#-#BALSA_RELEASE#.$$arch.rpm" ; \
#MAINT# test -f $$f && cp -f $$f . ; \
#MAINT# fi ; \
#MAINT# done
#MAINT#snapshot:
#MAINT# $(MAKE) distdir=$(PACKAGE)-`date +"%y%m%d"` dist
#MAINT#balsa-dcheck:
#MAINT# $(MAKE) BALSA_DISTCHECK_HACK=yes distcheck
## to automatically rebuild aclocal.m4 if any of the macros in
## `macros/' change
bzdist: distdir
#test -n "$(AMTAR)" || { echo "AMTAR undefined. Run make bzdist AMTAR=gtar"; false; }
-chmod -R a+r $(distdir)
$(AMTAR) chojf $(distdir).tar.bz2 $(distdir)
-rm -rf $(distdir)
# macros are not used any more by current configure.in, see also
# post by Ildar Mulyukov to balsa-list, 2006.06.27
# ACLOCAL_AMFLAGS = -I macros
UPDATE
I tried this answer.. but I got the following:
autoreconf --install
configure.in:250: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library
glibtoolize: putting auxiliary files in `.'.
glibtoolize: copying file `./ltmain.sh'
glibtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'.
glibtoolize: copying file `m4/libtool.m4'
glibtoolize: copying file `m4/ltoptions.m4'
glibtoolize: copying file `m4/ltsugar.m4'
glibtoolize: copying file `m4/ltversion.m4'
glibtoolize: copying file `m4/lt~obsolete.m4'
glibtoolize: Remember to add `LT_INIT' to configure.in.
glibtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
glibtoolize: `AC_PROG_RANLIB' is rendered obsolete by `LT_INIT'
configure.in:250: warning: macro `AM_GLIB_GNU_GETTEXT' not found in library
configure.in:249: error: possibly undefined macro: AC_PROG_INTLTOOL
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.in:250: error: possibly undefined macro: AM_GLIB_GNU_GETTEXT
configure.in:301: error: possibly undefined macro: AC_MSG_ERROR
autoreconf: /usr/bin/autoconf failed with exit status: 1
I'm looking into using the suggestions in the output..
Interesting. I just tried downloading "balsa" and noticed that they distributed the Makefile.am and configure.in files instead of a ready to run configure script. You could let the package maintainers know they aren't doing anyone any favors by not precompiling their own autotools sources.
Makefile.am is not a real Makefile. It's the thing that generates Makefile.in, which in turn gets translated into a real Makefile by a configure script.
Try the following steps:
Download the sources to balsa again clean. Then from the command prompt type the following:
autoreconf --install
(If you don't have autoreconf, you likely need to install the autotools packages - ughh...)
That should generate the configure script. Then type:
./configure
It complained about some missing GMime dependencies, so I didn't see it actually generate a Makefile. Once you get to the point in which a Makefile is generated, you should be able to point Netbeans to "open project from existing sources".
As per abbood's request...
Netbeans is not very good for C development. One approach would be to build an XCode project around the source base. The maintainers of the project may even accept the XCode project as a contribution.
is there a way to set a output-directory for making kernel-modules inside my makefile?
I want to keep my source-direcory clean from the build-files.
KBUILD_OUTPUT and O= did not work for me and were failing to find the kernel headers when building externally.
My solution is to symlink the source files into the bin directory, and dynamically generate a new MakeFile in the bin directory. This allows all build files to be cleaned up easily since the dynamic Makefile can always just be recreated.
INCLUDE=include
SOURCE=src
TARGET=mymodule
OUTPUT=bin
EXPORT=package
SOURCES=$(wildcard $(SOURCE)/*.c)
# Depends on bin/include bin/*.c and bin/Makefile
all: $(OUTPUT)/$(INCLUDE) $(subst $(SOURCE),$(OUTPUT),$(SOURCES)) $(OUTPUT)/Makefile
make -C /lib/modules/$(shell uname -r)/build M=$(PWD)/$(OUTPUT) modules
# Create a symlink from src to bin
$(OUTPUT)/%: $(SOURCE)/%
ln -s ../$< $#
# Generate a Makefile with the needed obj-m and mymodule-objs set
$(OUTPUT)/Makefile:
echo "obj-m += $(TARGET).o\n$(TARGET)-objs := $(subst $(TARGET).o,, $(subst .c,.o,$(subst $(SOURCE)/,,$(SOURCES))))" > $#
clean:
rm -rf $(OUTPUT)
mkdir $(OUTPUT)
If you are building inside the kernel tree you can use the O variable:
make O=/path/to/mydir
If you are compiling outside the kernel tree (module, or any other kind of program) you need to change your Makefile to output in a different directory. Here a little example of a Makefile rule which output in the MY_DIR directory:
$(MY_DIR)/test: test.c
gcc -o $# $<
and then write:
$ make MY_DIR=/path/to/build/directory
The same here, but I used a workaround that worked for me:
Create a sub-directory with/for every arch name (e.g. "debug_64").
Under "debug_64": create symbolic link of all .c and .h files. Keeping the same structure.
Copy the makefile to "debug_64" and set the right flags for 64 Debug build, e.g.
ccflags-y := -DCRONO_DEBUG_ENABLED
ccflags-y += -I$(src)/../../../lib/include
KBUILD_AFLAGS += -march=x86_64
Remember to set the relative directories paths to one level down, e.g. ../inc will be ../../inc.
Repeat the same for every arch/profile.
Now we have one source code, different folders, and different make files.
By the way, creating profiles inside make files for kernel module build is not an easy job, so, I preferred to create a copy of makefile for every arch.