Trying to compile a Linux image for LPC3250 ARM using Buildroot.
Stock settings, it compiles fine.
I'm getting this error when I try to add alsa-lib and alsa-utils:
configure: error: in `/home/user/projects/buildroot/output/build/alsa-lib-1.0.26 ':
configure: error: C preprocessor "/home/user/projects/buildroot/output/host/usr/ bin/arm-buildroot-linux-uclibcgnueabi-cpp" fails sanity check
See `config.log' for more details
Excerpt of alsa-lib's config.log. It kinda sucks because half the error messages have been cut off for some reason:
/home/user/projects/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/features.h:219:5: error: #error It appears you have defined _FILE_OF$
In file included from /home/user/projects/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdio.h:72,
from conftest.c:12:
/home/user/projects/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/bits/uClibc_stdio.h:61:2: error: #error Sorry... uClibc was built wi$
In file included from conftest.c:12:
/home/user/projects/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdio.h:83: error: expected '=', ',', ';', 'asm' or '__attribute__' $
In file included from conftest.c:12:
/home/user/projects/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdio.h:721: error: expected declaration specifiers or '...' before $
/home/user/projects/buildroot/output/host/usr/arm-buildroot-linux-uclibcgnueabi/sysroot/usr/include/stdio.h:723: error: expected ';', ',' or ')' before '*' token
Similar question here says something about "unsetting" CPP and CPPFlags.
Not sure where I would do this or check for it within the Buildroot environment. I'm not sure if this is even the same issue. I'm guessing its not related since in that other question it's talking about compiling GCC, which I'm not doing.
My #1 hunch right now is that I have to edit the configure file for lib-alsa. I'm just not sure what edits to make.
Edit: Did some aggressive Googling and came up with what I think is the full version of one of my errors: ...features.h:329:2: #error It appears you have defined _FILE_OFFSET_BITS=64. Unfortunately, uClibc was built without large file support enabled.
Checked my uClibc config file and UCLIBC_HAS_LFS=y is present. ???
The root of the issue here is Buildroot is using the uClibc config file located at: output/toolchain/uClibc-0.9.33.2/.config
rather than toolchain/uClibc/uClibc-0.9.33.config as specified in the Buildroot configuration menu.
I ran make uclibc-menuconfig (which defaults to saving the configuration in .config) and selected General Library Settings->Large File Support and everything compiled just fine.
Well, output/toolchain/uClibc-0.9.33.2/.config is generated from toolchain/uClibc/uClibc-0.9.33.config when Buildroot configures and builds uClibc. So it doesn't make any sense to use output/toolchain/uClibc-0.9.33.2/.config as the uClibc configuration. You should leave the default of toolchain/uClibc/uClibc-0.9.33.config.
Regarding Large File Support, normally all the packages have a proper dependency on it. So if a package needs large file support, the package cannot be selected until you enable large file support in Buildroot. If it is not the case, then it is a bug, and the Buildroot community would be interested in having a bug report about this (which details the Buildroot version being, the Buildroot configuration file being used, and the build error that you get).
Now, if Large File support is indeed needed, you should enable it at the Buildroot level rather than at the uClibc level. If you enable it only at the uClibc level, then Buildroot will not now about this, and will not show you all the packages that have a dependency on large file support.
So, what you should do is enable the BR2_TOOLCHAIN_BUILDROOT_LARGEFILE configuration option in Buildroot, and then do a complete rebuild: make clean all.
Related
If you have an answer for this, or further information, I'd welcome it. I'm following advice from here, to offer some unsolicited help by posting this question then an answer I've already found for it.
I have a bare-metal ARM board for which I'm building a cross-toolchain, from sources for GNU binutils, gcc and gdb, and for SourceWare's Newlib. I got those four working and cross-built a DoNothing.c into an ELF file - but I couldn't disassemble it with this:
$ arm-none-eabi-objdump -S DoNothing.elf
The error was:
$ arm-none-eabi-objdump: error while loading shared libraries: libdebuginfod.so.1: cannot open shared object file: No such file or directory
I'll follow up with a solution.
The error was correct - my system didn't have libdebuginfod.so.1 installed - but I have another cross-binutils, installed from binary for a different target, and its objdump -S works fine on the same host. Why would one build of objdump complain about missing that shared library, when clearly not all builds of objdump need it?
First I tried rebuilding cross binutils, specifying --without-debuginfod as a configure option. No change, which seems odd: surely that should build tools that not only don't use debuginfod but which don't depend on it in any way. (If someone can answer that, or point out what I've misunderstood, it may help people.)
Next I figured debuginfod was inescapable (for my cross-tools built from source at least), so I'd install it to get rid of the error. It's a component of the elfutils package, but installing the latest elfutils available for my Ubuntu 20.04 system didn't bring libdebuginfod.so.1 with it.
I found a later one, for Arch Linux, whose package contents suggested it would - but its package format doesn't match Ubuntu's and installing it was going to involve a lot of work. Instead I opted to build it from the Arch Linux source package. However, running ./configure on that gave a couple of infuriatingly similar errors:
configure: checking libdebuginfod dependencies, --disable-libdebuginfod or --enable-libdebuginfo=dummy to skip
...
configure: error: dependencies not found, use --disable-libdebuginfod to disable or --enable-libdebuginfod=dummy to build a (bootstrap) dummy library.
No combination of those suggestions would allow configure for elfutils-0.182 to run to completion.
The problem of course was my own lack of understanding. The solution came from the Linux From Scratch project: what worked was to issue configure with both of the suggested options, like this:
$ ./configure --prefix=/usr \
--disable-debuginfod \
--enable-libdebuginfod=dummy \
--libdir=/lib
That gave a clean configure; make worked first time, as did make check and then sudo make install which of course installed libdebuginfod.so.1 as required. I then had an arm-none-eabi-objdump which disassembles cross-compiled ELF files without complaining.
I am following this site to compile OpenCV for ARM.
It could not find my compiler so i hardcoded it into cmake file
find_program(CMAKE_C_COMPILER NAMES arm-linux-gnueabi-gcc-4.7)
find_program(CMAKE_CXX_COMPILER NAMES arm-linux-gnueabi-g++-4.7)
set(ARM_LINUX_SYSROOT /usr/arm-linux-gnueabi CACHE PATH "ARM cross compilation system root")
It compiles to aproximately 50% and then throws the following error:
Linking CXX shared library ../../lib/libopencv_viz.so
/usr/lib/libvtkCharts.so.5.8.0: file not recognized: File format not recognized
collect2: error: ld returned 1 exit status
I am not every experienced in cross compilation (or straight compilation for the matter). How do i fix this?
I think it is a mismatch between libopencv_viz and libvtkCharts. Some of your 3rdparty libs are built for another platform. These libraries themselves must be recompiled from source to match the details (ABI, dynamic system library dependencies, etc) of the system on which they are intended to be used.
Compiling OpenCV 2.4.10 worked for me. I did not have any preferred version. If you want to compile v3.0 see #Kornel's answer, that suggests to leave viz library out of compilation.
Use this command to checkout v2.4.10
git checkout 2.4.10
I am trying to use libnl 3 (http://www.infradead.org/~tgr/libnl/) under Ubuntu to use netlink in order to get some information from the IPv6 Neighbour Cache.
I am including a bunch of headers for this lib, but gcc already fails for the first one:
#include <libnl3/netlink/netlink.h>
There is no "main header", like libnl.h.
>$ gcc netlink_test.c
In file included from netlink_test.c:11:0:
/usr/include/libnl3/netlink/netlink.h:24:36: fatal error: netlink/netlink-compat.h: No such file or directory
compilation terminated.
The file netlink.h includes "netlink/netlink-compat.h". Unfortunately, there is no "/usr/include/netlink/" folder. There is only "/usr/include/libnl3/netlink/"
Including "netlink/netlink.h" thus gives me:
netlink_test.c:10:29: fatal error: netlink/netlink.h: No such file or directory
compilation terminated.
I have installed the following packages under Ubuntu 12.04:
libnl-3-200
libnl-3-200-dbg
libnl-3-dev
libnl-3-doc
libnl-genl-3-200
libnl-genl-3-200-dev
libnl-route-3-200
libnl-route-3-200-dev
Am I missing here something or is this genuinely broken?
OK, so the package is not broken, I am ;)
A short while ago, they introduced a mechanism to enable users to install different versions of this library.
Now you can configure it using "pkg-config" or just pass the precise directory to the compiler with "-I /usr/include/libnl3/".
And it works.
I have the following warning during link:
/usr/bin/ld: warning: libxxx.so.6, needed by /a/b/c/libyyy.so, not found (try using -rpath or -rpath-link)
Setting environment variable LD_LIBRARY_PATH=path_to_libxxx.so.6 silence the warning (adding -Lpath_to_libxxx.so.6 doesn't help).
I have a separate compilation server, where the resulting binary is only compile.
The binary is executed on other server and there the libxxx.so.6 is seen by the binary (checked with ldd executable).
Is there're other way to get rid of the warning at compilation time (I have it several times and it's very annoying)?
You need to add the dynamic library equivalent of -L:
-Wl,-rpath-link,/path/to/lib
This will cause the linker to look for shared libraries in non-standard places, but only for the purpose of verifying the link is correct.
If you want the program to find the library at that location at run-time, then there's a similar option to do that:
-Wl,-rpath,/path/to/lib
But, if your program runs fine without this then you don't need it.
Make sure the paths to the needed libraries are known to the runtime linker. This is done by adding a file in /etc/ld.so.conf.d/ with the needed path. For example, /etc/ld.so.conf.d/foo with the following contents:
/usr/local/lib/foo/
If you have a very old Linux version, /etc/ld.so.conf.d/ might not be supported, in which case you might have to add the paths directly into the /etc/ld.so.conf file.
After you've done that, you need to update the linker's database by executing the "ldconfig" command.
I know this is old, but here's a better fix:
The root cause:
The problem actually happens when LD invoked by GCC starts resolving
library dependencies. Both GCC and LD are aware of the sysroot
containing libraries, however LD may be missing one critical
component: the /etc/ld.so.conf file. Here’s an exampleld.so.conf file
from a Raspberry PI system:
include /etc/ld.so.conf.d/*.conf
The /etc/ld.so.conf.d directory contains the following files:
00-vmcs.conf:
/opt/vc/lib
arm-linux-gnueabihf.conf:
/lib/arm-linux-gnueabihf /usr/lib/arm-linux-gnueabihf
libc.conf:
/usr/local/lib
The universal solution
The problem can be easily solved by copying the LD configuration files
to a location where the cross-toolchain’s LD can find them. There’s
one pitfall however: if your cross-toolchain was built with MinGW
(most are), it probably did not have access to the glob() function so
it won’t be able to parse a wildcard-enabled include statement
like *.conf. The workaround here is to just manually combine the
contents of all .conf files from /etc/ld.so.conf.d and paste them
into /etc/ld.so.conf
*/opt/vc/lib
/lib/arm-linux-gnueabihf
/usr/lib/arm-linux-gnueabihf
/usr/local/lib*
Once you create the ld.so.conf file in the correct folder, your
toolchain will be able to resolve all shared library references
automatically and you won’t see that error message again!
The only way to silence these warning using command line options would be the -L flag which curiously does not work for you (maybe you can post more details on this). Since the warning is generated by ld we could try to use -Wl,option to disable a linker warning but from the documentation of GNU ld however there is no option for (de)activating this warnings.
So this leaves us with writing a wrapper script filtering out this warning or compile a custom version of ld.
Good afternoon,
I am having difficulties with libxml2.
I tried to build the Perl module XML-LibXML which is part of our standard runtime environment. However, this time the installation on a RHEL5 box failed, because the build process complained about missing libxml2:
$> perl Makefile.PL LIB=/foo/lib/perl PREFIX=/foo INSTALLDIRS=site
enable native perl UTF8
running xml2-config...ok (2.7.6)
looking for -lxml2... no
looking for -llibxml2... no
libxml2 not found
However, the file was available. Starting the build with
perl Makefile.PL LIB=/usr/inform/target/lib/perl PREFIX=/usr/inform/target INSTALLDIRS=site
led to more evidence of the real problem:
[...]
Can't load 'blib/arch/auto/Conftest/Conftest.so' for module Conftest: /usr/inform/target/lib/libxml2.so.2: cannot restore segment prot after reloc: Permission denied at /usr/lib/perl5/5.8.8/i386-linux-thread-multi/DynaLoader.pm line 230.
at test.pl line 2
[...]
After some investigations I found that the problem appears to be that libxml2.so is created with text relocation:
[tess91#INF-AW] lib$ eu-findtextrel libxml2.so.2.7.6
the file containing the function 'get_crc_table' is not compiled with -fpic/-fPIC
the file containing the function 'crc32' is not compiled with -fpic/-fPIC
the file containing the function 'gzerror' is not compiled with -fpic/-fPIC
[...]
Ans since we have SElinux active on the target machine, linking against libxml.2 failed!
Is there any possibility to create libxml2 properly, or do I have to ask the admin to twist SElinux to allow relocations?
I really can't believe I am the olny one having this problem on Linux with SElinux active. What am I missing?
Any help apprecitated!
Regards,
Stefan
The simplest way is to have your administrator yum install libxml2-devel or even yum install perl-XML-LibXML. Otherwise, see if you can add -fPIC to the CFLAGS in the Makefile.PL.
I assume you are on 32-bit x86, any other architecture wouldn't work without -fPIC.
I just found a possible explanation:
During the build of libxml2 the compiler flag -fPIC is indeed used, so the code is created position independant, BUT:
When creating the shared library, the static libz is linked against it. Is that the source of my problem? That including a static lib in a shared executable taints the library by introducing non-relocatable code?
The fact that the symbols eu-findtextrel should already have pointed me in that direction, since crc32, get_crc_table, etc. look like encryption centered code...