There is a package, built using autotools (has a Makefile.am) that I need to incorporate onto a OpenWRT build.
From the OpenWRT pages, a specific type of Makefile seems to be needed.
How can I incorporate this package onto OpenWRT? What changes are needed?
Maybe point me to some documentation where this is mentioned? I haven't been able to find anything on the topic!
Thanks!
Related
Good morning,
I need to compile libgcc from scratch without deploying the ARM optimized version which is defined in ieee754-sf.s in the ARM back-end.
Does anyone knows how to configure GCC for excluding ieee754-sf.s ( in libgcc/config/arm ) to compile from scratch libgcc, in particular compiling vanilla floating-point soft-fp emulation which is in libgcc/spft-fp ?
Thanks
I dont know a configure command which does what you want. However if you want to do these modifications, you will need to modify lib1funcs.S to delete the references to the two files. you will need also to modify the t files (t-elf and t-arm at least) . gcc/config/arm/elf.h sould probably be modified too.
You can take a look at microblaze config directory. it shows a minimalist example
I have a Linux kernel for NXP i.MX6. There are some capture kernel modules in /driver/media/platform/mxc/capture.
One of the files called mxc_v4l2_capture.c. I had to change this file for using it with my own new kernel driver.
I created a repository with my driver and the sources for mxc_v4l2_capture. Then I made a new Yocto recipe in my layer recipies-kernel -> kernel-modules->my-kernel-module.bb
Yocto can build these two kernel modules (my-kernel-module.ko and mxc_v4l2_capture.ko).
Okay, now there is a problem because the kernel recipe already builds the mxc_v4l2_capture module. Therefore I want to manipulate the Makefile for the original kernel modules and exclude the make of mxc_v4l2_capture.
I have created the patch but I don't know how to use the patch with Yocto. Where to place it and how can I call it?
Normally I put a patch into a .bbappend file and finish but I don't know the name of the recipe that build the kernel modules.
It would be great if there is a way without manipulating this Makefile.
Is there a way to solve this with my kernel module recipe?
mxc_v4l2_capture.c is in-tree kernel driver. If you want to change the in-tree driver code and compile, it's highly recommended to patch the kernel and compile the kernel with usual recipe.
Having additional bitbake recipe for the in-tree kernel module is not necessary. To patch the kernel and compile, you can use .bbappend or .bb itself. For example,
if you have recipes-kernel/linux/linux-stable_4.19.75.bb in your Yocto BSP layer, you can add the patch to SRC_URI as below.
FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:"
SRC_URI += "file://mxc_v4l2_capture.patch"
Now, you create recipes-kernel/linux/linux-stable-4.19.75/ and copy the mxc_v4l2_capture.patch file inside.
Or if you don't have permission or not possible to modify the Kernel recipe in BSP layer, you can create .bbappend in your custom layer. For the above example, you can create linux-stable_4.19.75.bbappend (specific version) or linux-stable_%.bbappend (any version). Then place the same content as mentioned above.
Yocto supports various patch formats, refer here for more details.
Look at this answer I wrote some days ago. The steps are basically the same. Using
devtool modify virtual/kernel
will create a working copy in build/workspace where you can do the work you want. Commiting those changes to the local branch and running
devtool finish linux-mainline <path-to-your-layer>
will create a .bbappend file with the patches already created and put to the correct location for you.
If you want to learn how to do it manually follow the advice #Parthiban gave.
Userspace package built for and along with root file system image of some embedded Linux-based system here (using Yocto project) apparently uses autotools - one can see Makefile.am's and configure.ac in package's sources. pkg-config or its successor seems to be used too (.pc.in is present), however out-of scope here.
Package in focus here does it this way (by involving autotools) as in the beginning of its development it was apparently the line of lowest resistance to copy and adopt build scripts from similar but already-existing package.
Actually autotools seem to be dispensable when building with Yocto, as Yocto build system meta data do specify target precisely enough for every target. For good reason standard build flow in Yocto is download, unpack, patch, configure, build,... with scan-and-detect-target-environment not included in this chain.
Now I wonder if it was good to streamline package's build process by removing autotools stage. I'm going to conduct it by proceeding in sequence of few steps starting with replacing .am file with real makefile. Question is if it will be sufficient enough to find env. variables defined and used in .am and .ac then transfer them to makefile? Remaining target-device specification should actually come from Yocto build system meta data. Possibly it will work this straightforward if to build package in scope of root file system image build. But how to ensure build environment provides complete target device specification when building only this package bitbake package-name?
Replacing autotools with a bare makefile isn't a trivial operation, as https://nibblestew.blogspot.co.uk/2017/12/a-simple-makefile-is-unicorn.html demonstrates nicely.
If you don't want to use autotools in your packages then alternatives such as Meson are generally faster.
I'm new in writing Linux device driver, and I'm wondering how the kernel Makefile magically knows what to compile. To illustrate what I don't understand, consider the following case:
I did a #include <linux/irq.h> in my driver code and I'm able to find the header file irq.h in the kernel directory KDIR/include/linux. However, this is only the header file, so I thought the irq.c source code must be out there somewhere. Hence, I looked into the KDIR/arch/arm searching for irq.c (since I'm using the ARM architecture). My confusion begins here when I found really many irq.c inside KDIR/arch/arm. To simply list a few, I got:
KDIR/arch/arm/mach-at91/irq.c
KDIR/arch/arm/mach-davinci/irq.c
KDIR/arch/arm/mach-omap1/irq.c
KDIR/arch/arm/mach-orion5x/irq.c
many more...
In my Makefile, I have a line like this:
$(MAKE) -C $(KDIR) M=$(PWD) CROSS_COMPILE=arm-none-linux-gnueabi- ARCH=arm modules
So I understand that the kernel Makefile knows that I'm using the ARM architecture, but under KDIR/arch/arm/, there are so many irq.c with the same name. I'm guessing that the mach-davinci/irq.c is compiled since davinci is the cpu name I'm using. But then, how can the kernel Makefile knows this is the one to compile? Or if I would like to have a look for the irq.c that I'm actually using, which one should I refer to?
I believe there must be a way to know this besides reading the long kernel Makefile. Thanks for any help!
Beyond the ARCH variable, you can also choose the system type (mach) from the configuration menu (there is actually a sub-menu called "System type" when you type make menuconfig for instance). This selection will include and compile all files under linux2.6/arch/$ARCH/mach-$MACH, and in your case this is how only one irq.c gets compiled.
That aside, it is interesting to understand how the kernel chooses which files to compile. The mechanism behind this is called Kconfig, and it is what allows you to precisely configure your kernel using make menuconfig and others, to compile a module from the outside like you are doing, and to select the right files to compile from simple Makefiles. While it is simple to use, its internals are rather complex - but this article, although rather old, explains it rather well:
http://www.linuxjournal.com/article/6568
To make a very long story short, there's a target make config, which you can trace. That one generates .config, that is your main guideline to making dependencies and controlling what will be compiled, what not, what as module and what will be compiled into the kernel.
This guide should give you a basic understanding of building a kernel module (and I assume that's where you want to start with your driver).
I have C project of a library (using CDT). Configurations for both static and dynamic linking for several platforms. Several examples of the library usage is also included in the project. What is the best way to build these examples with the library? If I would like to build both the library and examples (linking the library just built) in one configuration?
I suppose I have to use custom makefile. Do I have to create makefile for the whole project (several of them, one for each platform), or is there any way how to include examples makefile to the automatic one?
Each example has only one source file, so the only things I need to do in my makefile are to determine which compiler is used, add some flags and link with the library which was built (I would include the make examples command as the post-build step).
As I didn't find any solution for this, I use custom makefile for the whole build. I also found a nice advice somewhere: if you want advanced build functions, use advanced build system.