I'm trying to cross compile the Linux kernel 4.10.8 for arm, but get this error:
CC [M] drivers/vhost/vhost.o
In file included from ./include/uapi/linux/stddef.h:1:0,
from ./include/linux/stddef.h:4,
from ./include/uapi/linux/posix_types.h:4,
from ./include/uapi/linux/types.h:13,
from ./include/linux/types.h:5,
from ./include/uapi/asm-generic/fcntl.h:4,
from ./arch/arm/include/uapi/asm/fcntl.h:9,
from ./include/uapi/linux/fcntl.h:4,
from ./include/linux/fcntl.h:4,
from ./include/linux/eventfd.h:11,
from drivers/vhost/vhost.c:14:
drivers/vhost/vhost.c: In function ‘vhost_vring_ioctl’:
./include/linux/compiler.h:518:38: error: call to ‘__compiletime_assert_1357’ declared with attribute error: BUILD_BUG_ON failed: __alignof__ *vq->avail > VRING_AVAIL_ALIGN_SIZE
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)enter
Any idea how to solve this?
I dont know what this module is used for, so I dont know if I actually need to compile it, but I cant find where in menuconfig to disable this module?
This module (CONFIG_VHOST) usually requires when you need virtualization support. If you don't require it disable it in the make menuconfig.
If you don't need virtualization, you can ignore it and proceed your build.
Related
I'm using Buildroot 2018.02.7 to build a simple Linux system for i386 PC, as a precursor to doing the same thing for an embedded ARM system. I keep running into problems like this one, in building the util-linux module:
CC lib/libcommon_la-path.lo
lib/pager.c:11:17: fatal error: err.h: No such file or directory
#include <err.h>
^
compilation terminated.
Makefile:8596: recipe for target 'lib/libcommon_la-pager.lo' failed
make[3]: *** [lib/libcommon_la-pager.lo] Error 1
When I look in the linux-headers source tree in .../output/build/linux-headers-4.13.8, the file is found. But Buildroot is pointing to a different set of headers, the one built into its GCC:
devuser#3faf730b4a1b:~/pc/buildroot-2018.02.7/output/build/util-linux-2.31.1$ ../../host/bin/i686-buildroot-linux-uclibc-gcc -print-sysroot
/home/devuser/pc/buildroot-2018.02.7/output/host/i686-buildroot-linux-uclibc/sysroot
devuser#3faf730b4a1b:~/pc/buildroot-2018.02.7/output/build/util-linux-2.31.1$
And the two /usr/include subdirectories are significantly different.
Have I missed a configuration setting somewhere in the defconfig file? This is the defconfig:
BR2_x86_core2=y
BR2_SSP_REGULAR=y
BR2_PACKAGE_HOST_LINUX_HEADERS_CUSTOM_4_13=y
BR2_UCLIBC_CONFIG="board/pc/dsa_pc_i386_uclibc.config"
BR2_TOOLCHAIN_BUILDROOT_USE_SSP=y
BR2_TOOLCHAIN_BUILDROOT_CXX=y
BR2_TARGET_GENERIC_GETTY_PORT="tty1"
BR2_ROOTFS_POST_IMAGE_SCRIPT="board/pc/post-image.sh support/scripts/genimage.sh"
BR2_ROOTFS_POST_SCRIPT_ARGS="-c board/pc/genimage-bios.cfg"
BR2_LINUX_KERNEL=y
BR2_LINUX_KERNEL_CUSTOM_VERSION=y
BR2_LINUX_KERNEL_CUSTOM_VERSION_VALUE="4.13.8"
BR2_LINUX_KERNEL_USE_CUSTOM_CONFIG=y
BR2_LINUX_KERNEL_CUSTOM_CONFIG_FILE="board/pc/linux.config"
BR2_LINUX_KERNEL_INSTALL_TARGET=y
BR2_LINUX_KERNEL_EXT_XENOMAI=y
BR2_PACKAGE_BUSYBOX_CONFIG="board/pc/dsa_pc_i386_busybox.config"
BR2_PACKAGE_LINUX_FIRMWARE=y
BR2_PACKAGE_LINUX_FIRMWARE_ATHEROS_9170=y
BR2_PACKAGE_LINUX_FIRMWARE_ATHEROS_9271=y
BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_3160=y
BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_3168=y
BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_5000=y
BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_6000G2A=y
BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_6000G2B=y
BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_7260=y
BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_7265D=y
BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_8000C=y
BR2_PACKAGE_LINUX_FIRMWARE_IWLWIFI_8265=y
BR2_PACKAGE_LINUX_FIRMWARE_RALINK_RT73=y
BR2_PACKAGE_LINUX_FIRMWARE_RALINK_RT2XX=y
BR2_PACKAGE_LINUX_FIRMWARE_RTL_81XX=y
BR2_PACKAGE_LINUX_FIRMWARE_RTL_87XX=y
BR2_PACKAGE_LINUX_FIRMWARE_RTL_88XX=y
BR2_PACKAGE_LINUX_FIRMWARE_RTL_8169=y
BR2_PACKAGE_ACPID=y
BR2_PACKAGE_DBUS=y
BR2_PACKAGE_ZLIB=y
BR2_PACKAGE_LIBFFI=y
BR2_PACKAGE_PCRE=y
BR2_PACKAGE_PCRE_UCP=y
BR2_PACKAGE_READLINE=y
BR2_PACKAGE_WPA_SUPPLICANT=y
BR2_PACKAGE_WPA_SUPPLICANT_DBUS_NEW=y
BR2_PACKAGE_KMOD=y
BR2_PACKAGE_UTIL_LINUX=y
BR2_PACKAGE_UTIL_LINUX_LIBMOUNT=y
BR2_TARGET_ROOTFS_EXT2=y
BR2_TARGET_ROOTFS_EXT2_4=y
BR2_TARGET_ROOTFS_EXT2_SIZE="120M"
# BR2_TARGET_ROOTFS_TAR is not set
BR2_PACKAGE_HOST_GENIMAGE=y
Enable UCLIBC_HAS_BSD_ERR in uClibc.
You have a custom uClibc configuration. That falls squarely in the "you know what you are doing" category, since it allows you to remove features that other packages rely on.
In this case, util-linux relies on the non-Posix err.h include. This is only installed if UCLIBC_HAS_BSD_ERR is enabled in the uClibc configuration.
There is a high risk of running into similar issues with a custom uClibc configuration.
I am trying to play a wav file in a very simple program that looks like this, currently attempting to use nim-csfml:
import csfml_audio
var alarmsong = newMusic("alarm.wav")
alarmsong.play()
but it appears to be relying on the existence of libcsfml.audio, and while my program compiles just fine, when I try to actually run it I get an error
| => ./alarm
could not load: libcsfml-audio.so
(I have a libcsfml-audio.dylib instead, being that I used the OSX shared libraries for csfml/sfml)
Is there some other way to play a .wav file in Nim?
Edit 1:
After the PR made by #def-, I now get a different, slightly more comforting error, which is probably due to some poor understanding of how nim deals with shared libraries:
| => ./alarm
could not load: libcsfml-audio.dylib
I added path = "/usr/local/lib" to my nim.cfg file, but it didn't seem to be affect anything. I also exported $LD_LIBRARY_PATH="/usr/local/lib" (/usr/local/bin is where libcsfml-audio.dylib is.), and tried compilation through
nim c alarm.nim --clib:/usr/local/lib/libcsfml-audio.dylib
Thanks for the help!
This program would just exit immediately; you need to keep it alive while the sound plays. Append this to the program:
import csfml_system
while alarmsong.status == SoundStatus.Playing:
sleep 100.milliseconds
For nim-csfml to work you'll need SFML 2.1 and CSFML 2.1. Also, it seems that nim-csfml is actually broken for Mac OS X, so I've made a pull request with a fix: https://github.com/BlaXpirit/nim-csfml/pull/4
Other modules that could play sound are sdl_mixer, sdl2/audio and allegro5.
As an OSX-only alternative without using any libraries, by calling the afplay binary:
import osproc
discard execProcess("afplay", ["file.wav"])
Edit1:
When Nim reports "could not load: libcsfml-audio.dynlib" that could also mean that one of the dependencies of that library are missing or in a wrong version. Especially SFML 2.2 doesn't work with CSFML 2.1. Make sure libsfml-audio.dynlib is in your LD_LIBRARY_PATH as well. If that doesn't work either, you could try to compile and run a regular C CSFML example like this one: https://gist.github.com/def-/fee8bb041719337c8812
Compile it with clang -o mainpage -lcsfml-graphics -lcsfml-audio -lGL -lGLEW mainpage.c to see the errors/warnings about missing libraries.
I have a simple Kernel module:
void GPIO_LED(void) {
printk(" GPIO: set PC8: '0');
at91_set_gpio_value(AT91_PIN_PC8, 1);
}
//
int init_module(void) {
GPIO_LED();
return 0;
}
MODULE_LICENSE("GPL");
When using it with mdev device management. everything works just fine. But using it with a udev device management, while executing insmod
insmod /usr/modules/measurement_gpio.ko
the following message appeared:
insmod: can't insert '/usr/modules/measurement_gpio.ko': invalid module format
Another test showed that when using a device table instead of mdev/udev leads to the same Error. Every setting stayed the same (especially the kernel version) but the device management changes during this Test, so actually the module should be fine.
How can that be and how to solve it?
[Edit:] after making the kernel be able for load modules for multiple versions i receive the following message, which confuses me even more:
measurement_gpio: version magic '2.6.39 mod_unload modversions ARMv5 ' should be '2.6.39 mod_unload ARMv5
[Edit2:]
The way I build my module is:
with Buildroot I'm generating an Image, on the way a Linux
2.6.39 is installed.
Afterwards I'm compiling the kernelmodule with the path to the Linux 2.6.39, that buildroot has downloaded.
When the module is created I'm putting it into a fs-overlay
directory, so it will be included into the image on next build.
I hit another "make" on buildroot and i got everything together and a bootable Image.
I change nothing, that's why it confuses me even more
I keep getting compilation error for a kernel module:
XXX: In function 'yyy':
ZZZ:125: error: implicit declaration of function '__arch__swab32'
PowerPC, 2.6.30.x, Kamikaze toolchain. According to this the identifier went away after 2.6.28. What should I use instead?
You should be using the generic __swab32 from linux/swab.h (which also exists on earlier kernel versions).
I m using gdb on a aix shared lib running on aix 5.3?
When i try to run gdb for this file
i get a error message saying ""Architecture of file not recognized"
Don't know how to get this fixed.
Does anybody know why i get this message ""Architecture of file not recognized"?.
gdb runs fine on other executables compiled by xlc.
Is there some option that i might have used while compiling , which is not compatible with GDB.some processor specific option.
I compiled the shared lib w xlc v9.0 for aix.
Thanks.
You don't run GDB on a shared library, you run it on an executable.
If the executable loads your shared library, GDB will know about it.
void
set_gdbarch_from_file (bfd *abfd)
{
struct gdbarch_info info;
struct gdbarch *gdbarch;
gdbarch_info_init (&info);
info.abfd = abfd;
info.target_desc = target_current_description ();
gdbarch = gdbarch_find_by_info (info);
if (gdbarch == NULL)
error (_("Architecture of file not recognized."));
deprecated_current_gdbarch_select_hack (gdbarch);
}
This is the actual GDB code in question (gdb/arch-utils.c:530-544).
The information passed to the gdbarch pointer seems to be invalid. This is caused by gdb_find_by_info returning a NULL pointer and that is caused by find_arch_by_info (gdb/gdbarch.c:3656) returning a NULL pointer.
It basically means what it says: GDB could not identify the architecture of the file. This seems to be a common problem for xlc, even on recent gdb versions.
XLC and gdb are, as far i remember and understand, not very good when it comes down to compatability terms (AIX support is minimal), you might try using the Gnu C Compiler .You might look at the GDB sources for VERY specific information (that i can't really give you).
Here is a link to gcc-AIX specifics.