I'm building a Poky-based embedded Linux distribution for a target which doesn't have a real-time clock. System time is only set by ntpd. Therefore I don't really need an init script which calls hwclock --hctosys during boot, and in fact I'm afraid that this might cause the system time which is set by ntpd to be
overwritten with an incorrect value.
So how do I get rid of the hwclock init script? It turns out that it comes from the busybox recipe. The default recipe for busybox in Poky contains the following lines:
PACKAGES =+ "${PN}-httpd ${PN}-udhcpd ${PN}-udhcpc ${PN}-syslog ${PN}-mdev ${PN}-hwclock"
...
FILES_${PN}-hwclock = "${sysconfdir}/init.d/hwclock.sh"
...
INITSCRIPT_PACKAGES = "${PN}-httpd ${PN}-syslog ${PN}-udhcpd ${PN}-mdev ${PN}-hwclock"
...
INITSCRIPT_NAME_${PN}-hwclock = "hwclock.sh"
I have no idea how to remove all the references to hwclock from within a *.bbappend file. Is there any straightforward solution, or is it not possible from a bbappend and I have to re-write the entire recipe?
You can disable it from its defconfig file by configuring CONFIG_HWCLOCK=n located at openembedded-core/meta/recipes-core/busybox/busybox/defconfig.
If you want to exclude packages from a build and don't want to resort to manipulating working recipes, just so a PACKAGE_EXCLUDE = "<package_name>" in your local.conf
This is an example of mine:
PACKAGE_EXCLUDE = "busybox-syslog busybox-hwclock"
But note that some packages may depend on hwclock. You'll get a bitbake dependency error at worst.
Related
I am trying to enable systemd's libcryptsetup module in order to decrypt a drive at bootup through crypttab. It seems crypttab is not present because the systemd-cryptsetup-generator is missing from the systemd (216) build.
I have tried specifying the "cryptsetup" option in the PACKAGECONFIG?? statement and also specifying --enable-libcryptsetup as argument in the build but the option is disabled by the config script bitbake uses (it appends automatically --disable-cryptsetup after my enable statement)
I suspect this is because configure detected some missing dependency, therefore I tried specifying that the systemd recipe depends on the cryptsetup recipe but I ended in a recipe loop (cryptsetup depends on lvm2 which depends on systemd, so cryptsetup will not be buildable before systemd is built).
Does anyone have any suggestion or encountered a similar issue? Thanks!
Adding "cryptsetup" to PACKAGECONFIG either via a direct change in the recipe, or a bbappend or local.conf, should do the trick. What release of OE are you using, can you paste your changes, and ideally the beginning of the log.do_configure where it shows what the configure options are.
And you'll see --enable --disable if you attempted to enable it directly in EXTRA_OECONF but didn't delete the PACKAGECONFIG[cryptsetup] line which it thinks is disabled (so adds the disabled flag for you).
I have a check for a header file in configure.ac in the source root
AC_CHECK_HEADER(log4c.h,
[],
[AC_MSG_ERROR([Couldn't find or include log4c.h])])
and I'd like to give different feedback on different platform to reflect different most straight forward ways of providing the header:
on Debian it should error with the message Couldn't find or include log4c.h. Install log4c using 'sudo apt-get install liblog4c-dev'
on OpenSUSE it should error with ... Install log4c using 'sudo yum install log4c-devel' (didn't research the package name, but you catch my drift)
on other systems (where I'm too lazy to research the package name) it should error with ... Install log4c by fetching ftp://.../log4c.tar.gz and installing with './configure && make && make install' in the source root
I
checked the AM_CONDITIONAL macro, but I don't get how to use it in configure.ac rather than in Makefile.am (as described in autoconf/automake: conditional compilation based on presence of library?)
found the tip to run esyscmd in stackoverflow.com/questions/4627900/m4-executing-a-shell-command, but adding esyscmd (/bin/echo abc) to configure.ac doesn't print anything when I run autoreconf --install --verbose --force.
Both answers describing the usage of conditional macros without the shell commands for the mentioned OS and links to predefined macros (like AC_CHECK_HEADER_DEBIAN, AC_CHECK_HEADER_SUSE, etc.) are appreciated.
The following configure.ac doesn't work:
AC_INIT([cndrvcups-common], [2.90], [krichter722#aol.de])
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE([foreign -Wall subdir-objects])
AC_PROG_CC
AM_PROG_AR
AM_PROG_CC_C_O
AC_MSG_NOTICE([Hello, world.])
AC_INCLUDES_DEFAULT
AC_CHECK_HEADER(check.h,
[],
[
AS_IF (test "$(lsb_release -cs)" = "vivid", [echo aaaaaa], [echo bbbbbb])
])
LT_INIT # needs to be after AM_PROGS_AR
AC_CONFIG_HEADERS([config.h])
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
because ./configure fails with
checking check.h usability... no
checking check.h presence... no
checking for check.h... no
./configure: line 4433: syntax error near unexpected token `;'
./configure: line 4433: ` if ; then :'
There's also ./configure: line 4427: #include: command not found which happens no matter whether AC_CHECK_HEADER is specified.
Your configure.ac is almost ok. The only problem is space between AS_IF and the parenthesis. No whitespace is allowed between a macro name and the opening parenthesis in m4 scripts. This is correct syntax:
AC_CHECK_HEADER(check.h,
[],
[
AS_IF(test "$(lsb_release -cs)" = "vivid", [echo aaaaaa], [echo bbbbbb])
])
If you are looking for a way to detect different distros look for example at configure.ac of cgmanager.
Update
I noticed one more problem in your configure.ac.
AC_INCLUDES_DEFAULT macro expands to a set of default includes and can't be used here. It is not needed also. It will be used by default in your AC_CHECK_HEADER macro, as you omit last parameter.
This is the cause of line 4427: #include: command not found error you mention.
Update to your comment
First of all, running a system command itself, like lsb_release is not portable. You should first check, for example with AC_CHECK_PROG, for its presence.
Regarding the syntax I would first get the output of the command using backticks: result=`lsb_release -cs` and later test resulting output: test "x$result" = "xvivid". x is needed to avoid problems with empty value in some shells.
At last, I have doubts whether configure script is a proper place for all this distro specific messages. You may consider placing it in the README file.
Avoid those system specific messages.
Print one message which allows people to figure out what package to install on their respective system, but avoid naming the system specific package names and system specific installation tools.
You will never be able to add messages for all systems, so it is better to go the part of the way which you know and let your users go the rest of the way because they know their systems better than you can.
The proper way would be to write a software package outside but called from your configure which, given a header filename, foo.pc filename, library name, etc. figures out how to install that on the respective system. Then let system specific maintainers fix that package, and call it from configure if it is installed, and issue a generic error message otherwise.
A portable shell script local to your software package might do the same job to some extent. You still have to maintain all the system specific parts for all possible systems, though.
Hmm... now that I am thinking about that, the idea appears not that bad. I might add such a script to some of the projects I maintain and see how it turns out in practical use.
I would still try to keep most of that logic outside configure, though.
For some reason the menuconfig menu does not come up when I try launching it from my Yocto installation. I am using the Toradex Yocto 1.6 system as is described here http://developer.toradex.com/software-resources/arm-family/linux/board-support-package/openembedded-%28core%29, with my board set to "apalis-t30". When I run either bitbake virtual/kernal -c menuconfig or bitbake linux-toradex -c menuconfig, it executes fine but finishes (without erros) before actually showing anything. Running devshell also gives the same results.
If I just use the kernel sources on their own as is described here http://developer.toradex.com/software-resources/arm-family/linux/board-support-package/build-u-boot-and-linux-kernel-from-source-code, I can get menuconfig open using make nconfig. From the Yocto scripts it appears as if though the exact same kernel sources are being used. If I try adding adding make nconfig to the do_configure_prepend script in the linux-toradex_git.bb file then the commands get stuck stating that the process (I assume menuconfig) is running and then provides a PID for it, but no window or menu is displayed anywhere and the task does not seem to finish.
PS. I am on Fedora 21 64-bit.
EDIT:
I have now checked the default Yocto image and menuconfig comes up fine there. I am assuming that the Toradex BSP is not entirely compatible enough with Yocto for this to work out of the box. I have spoken to Toradex and they have told me that I should instead fork their kernel, modify it the normal way in my own repo and then tell the script to pull from my modified repo. I guess this could work but its a bit of a hassle and I would like to fix their Yocto system. I am assuming that this cannot be to hard as running make nconfig is usually enough, I just can't figure out how to get that command working with bitbake.
This should work fine with the meta-toradex layer. In the local.conf file, comment out the INHERIT += "rm_work" line:
#INHERIT += "rm_work"
Then do a full build of the kernel:
MACHINE=apalis-t30 bitbake virtual/kernel
Then try menuconfig now that all the sources are in place:
MACHINE=apalis-t30 bitbake -c menuconfig virtual/kernel
If you are using Ubuntu, try to reconfigure system shell to bash instead of dash(that is default for Ubuntu):
$ sudo dpkg-reconfigure dash
press "No" when prompted.
Actually I got the same problem few times. In one case shell reconfigure helped me.
I am trying to build the smallest possible linux image using the Yocto project. I would also like to have package management on the target to be able to add to and update parts of the running system.
I can enable the package management by adding this to my conf/local.conf:
EXTRA_IMAGE_FEATURES = "package-management"
Using rpm, that pulls in the smartpm package manager which is based on python which in turn makes the image to large. So I tried to use ipk packages but that still depends on python.
Does anyone have a good idea how to include package management in Yocto with the least possible overhead?
I can suggest you few things, which may help you to optimize size of rootfs:
Optimize as much as possible linux kernel binary and removed unnecessary packages (filesystem,device driver,networking etc).
$ bitbake -c menuconfig virtual/kernel //configure as per your requirement
$ bitbake -c savedefconfig virtual/kernel //savedefconfig
$ bitbake -f virtual/kernel
Configure Busybox and removed unused things:
$ bitbake -c menuconfig busybox
Remove those Distro features if not in use (and check more also): graphics [x11], sound [alsa], touchscreen [touchscreen], Multimedia. Change apply in conf/local.conf file. Example: DISTRO_FEATURES_remove = "x11 alsa touchscreen bluetooth opengl wayland "
Choose proper system init manager: systemd or sysvinit
Removed Unused Packages from the image. Example PACKAGE_EXCLUDE = "perl5 sqlite3 udev-hwdb bluez3 bluez4"
For small embedded device preferred PACKAGE_CLASSES = "package_ipk" and it is well optimized for small systems.
Looks like this is the best I can do.
PACKAGE_CLASSES = "package_ipk"
Then edit the recipe for opkg-utils to not depend on python. Will of course break the python utils, though.
I am building a Linux system with cross-compiler using ptxdist. It allows me to configure Qt4 for installation and it builds and installs qt-everywhere-opensource-src-4.6.3 Ok. However, the qmake internal settings are screwed up and I don't know how to fix them.
When I run qmake -query I get:
me#ubuntu:~$ qmake -query
QT_INSTALL_PREFIX:/
QT_INSTALL_DATA:/
QT_INSTALL_DOCS://doc
QT_INSTALL_HEADERS://include
QT_INSTALL_LIBS://lib
QT_INSTALL_BINS://bin
QT_INSTALL_PLUGINS://plugins
QT_INSTALL_TRANSLATIONS://translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES://examples
QT_INSTALL_DEMOS://demos
QMAKE_MKSPECS://mkspecs
QMAKE_VERSION:2.01a
QT_VERSION:4.6.3
Through some research, it looks like this can be fixed by simply rebuilding Qt, but it's not fixing this problem. I dug into the build output a bit and it looks like the ./configure command for the Qt build has "-prefix /usr" so I don't know why this isn't being fixed.
I would like to fix these internal values manually if possible because the Qt build takes hours. Does anyone know how to do this?
At configure time these paths are hardcoded in 'src/corelib/global/qconfig.cpp', and end up hardcoded into qmake when it is built. They are also hardcoded into many other files, like all the .la and .pc files, not to mention the Makefile install rules.
The only way to fix this is to figure out why configure keeps screwing up the prefix. configure is a big shell script, so it's easy to see where $QT_INSTALL_PREFIX is assigned from the '-prefix' argument, and then the different checks that are done on it (like running it through 'config.tests/unix/makeabs'). Try putting print statements before/after $QT_INSTALL_PREFIX is changed, and you should be able to find out where the path gets screwed up.
Also, you don't have to wait for the full build to complete to tell if the prefix was set
correctly. After configure runs, take a look in 'src/corelib/global/qconfig.cpp' and see what 'qt_configure_prefix_path_str' is set to.
You can manually set these properties using
qmake -set VARIABLE VALUE
They are stored using QSettings, the Qt built-in persistent applications settings.
see Configuring qmake's Environment
Configure scripts can be fuzzy about slashes. Are you sure that the build prefix is /usr and not /usr/ .