When I run make binutils/readelf I get the following error:
In file included from readelf.c:43:0:
sysdep.h:23:25: fatal error: alloca-conf.h: No such file or directory
#include "alloca-conf.h"
What dependency am I missing? How do I just build and compile readelf without making the rest of binutils?
What has actually happened is that you do not have a Makefile or at least not one defining binutils/readelf target. But since there is a binutils/readelf.c file, make still ran and tried to compile and link binutils/readelf using its implicit pattern rules... and failed because this source file cannot be built without corresponding configuration.
This is just to add a bit more detail. Long story short, run ./configure and make as suggested in the comments and collect your resulting readelf. Much easier then trying to isolate a solitary item build out of autotools based project. You add -I to CFLAGS to find alloca-conf.h, you'll just run into another problem like that.
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 understand that this has come up a lot, but I've looked through all the other answers and none of them are relevant to me.
I am trying to compile the neuroimaging software FSL from source (I have to, it's not supported on my Linux Distro). I've followed all the instructions listed here, and it's about 80% compiled. There are a few modules that have not been successful, however, and they all seem to trace back to a problem trying to compile CiftiLib-master.
Per the instructions, whenever I try to run the 'make' command, it returns:
Makefile:34: warning: overriding recipe for target 'clean'
/home/thosvarley/Desktop/fslbuild/fsl/config/common/rules.mk:32: warning: ignoring old recipe for target 'clean'
gcc -c -Wall -ansi -pedantic -Wno-long-long -m64 -g -O3 -fexpensive-optimizations -m64 -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include/boost -g -DCIFTILIB_USE_XMLPP -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include/libxml2 -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include/libxml++-2.6 -I/home/thosvarley/Desktop/fslbuild/fsl/extras/lib/libxml++-2.6/include -I/home/thosvarley/Desktop/fslbuild/fsl/extras/include/boost -I./Common -I./Nifti -I./Cifti -I. -I/include -I/home/thosvarley/Desktop/fslbuild/fsl/include -o Common/XmlAdapter.o Common/XmlAdapter.cxx
In file included from Common/XmlAdapter.cxx:28:0:
Common/XmlAdapter.h:56:10: fatal error: libxml++/libxml++.h: No such file or directory
#include "libxml++/libxml++.h"
^~~~~~~~~~~~~~~~~~~~~
compilation terminated.
make: *** [Makefile:19: Common/XmlAdapter.o] Error 1
As I am not trying to compile one foo.c file, but rather, make a program a lot of the advice I've seen doesn't seem like it would apply to me. I've already installed all of the various libxml packages that get suggested in other posts (libxml2, libxslt1, etc).
I cannot make heads or tails of the error message: I'm not familiar with compiling C programs at all (this is my first serious foray into building from source). Apologies in advance if the answer is obvious and I just don't recognize it.
I'm on Antergos Linux (Arch kernel), which I think may be where the problem is coming from as all the other people who have asked after this seem to be on Debian or Ubuntu.
I have been attempting to solve the same problem. It seems that libxml++ is bundled with FSL by default, and the bundled version fails to compile.
Solution #1: Install and use an older compiler (e.g. GCC 4.8), since the project's configurations are made to fit those old compilers
I cannot vouch for this solution, as I haven't tried it myself (because apparently, I like to make life difficult for myself), but it's probably your best bet.
Solution #2: Fix the problems manually
NOTE: This is not a comprehensive solution, but it might point you in the correct direction.
Your first problem is most likely that the compiler you're using by default uses a more recent C++ standard than the project is written to be compiled with. This causes the implicit conversion of input streams and output streams to booleans to fail. You might be able to solve it by messing around with compiler flags in the makefile configurations, but it's probably easier to just fix the problematic parts of the code. The relevant lines (FSL 5.0.11) are:
- extras/src/libxml++-2.34.0/libxml++/io/istreamparserinputbuffer.cc (line 42)
return _input;
SHOULD BE
return static_cast<bool>(_input);
- extras/src/libxml++-2.34.0/libxml++/io/ostreamoutputbuffer.cc (line 32)
return _output;
SHOULD BE
return static_cast<bool>(_output);
- extras/src/libxml++-2.34.0/libxml++/io/ostreamoutputbuffer.cc (line 39)
return _output;
SHOULD BE
return static_cast<bool>(_output);
Depending on the version you're trying to install, the actual line numbers may be different, but they're probably in the same general area.
The next problem is that the include paths are not defined for INC_XML++, INC_XML++CONF and INC_XML2 in the generic makefile configuration. This is most likely the one your system defaults to, as there are no configurations for GCC versions > 4.8. Edit the config/generic/externallibs.mk file by adding the following lines (where exactly you add it is not important):
# XML++
LIB_XML++ = ${FSLEXTLIB}
INC_XML++ = ${FSLEXTINC}/libxml++-2.6
INC_XML++CONF = ${FSLEXTLIB}/libxml++-2.6/include
INC_XML2 = ${FSLEXTINC}/libxml2
(I addeed the LIB_XML++ for good measure, because the lib path was defined by other variables in the file, but I'm not 100% sure it's necessary.)
Again, this is what fixed it on my system. Depending on the version of the source code you downloaded, it might be different for you, but at least this is a starting point.
After fixing these errors, the CiftiLib-master target should compile. HOWEVER, if your system is anything like mine, this is far from the only error in the build process. Looking at the build.log file and searching for error: should give you a pretty good idea of which projects result in which errors, and what might be needed to fix them. The problems are likely to be similar in nature to the CiftiLib ones.
Final tip: If your libgd project fails to compile, look at the error: message. It probably complains about some undeclared identifiers (IMG_FMT_I420, PLANE_Y, PLANE_U, PLANE_V). If you prefix these identifiers with VPX_, it should work. The reason this fails is because of an update to the library that removes the definitions of the deprecated identifiers, forcing users to use the newer prefixed ones.
This is as far as I've come. I'm assuming you're not still troubled with this a year later, but I'm leaving this here for posterity.
I am looking to edit and recompile the hcitool.c of bluez version 5.31. I installed the bluez 5.31 by following the procedure from the answer of this:
Bluetooth Low Energy in C - using Bluez to create a GATT server
In my trial, I duplicated the hcitool.c file and named it as myhcitool.c inside the tools folder and I use the command
gcc -o myhcitool.o myhcitool.c.
This gives me an error
myhcitool.c:43:27: fatal error: lib/bluetooth.h: No such file or directory
#include "lib/bluetooth.h"
^
compilation terminated.
I tried copying the myhcitool.c outside the tools folder and compile it there. That gave me a bunch of errors something like this:
/tmp/ccj1QmZK.o: In function `dev_info':
myhcitool.c:(.text+0x293): undefined reference to `ba2str'
/tmp/ccj1QmZK.o: In function `conn_list':
myhcitool.c:(.text+0x501): undefined reference to `ba2str'
myhcitool.c:(.text+0x50f): undefined reference to `hci_lmtostr'
myhcitool.c:(.text+0x586): undefined reference to `bt_free'
/tmp/ccj1QmZK.o: In function `cmd_dev':
I also tried editing the hcitool.c itself by modifying a simple printf in there and then redo the 'make' and 'make install' commands for the whole bluez. After that, when I tried running the hcitool, the modification that I did has no effect.
The compilation errors clearly state that you are missing files and directories and that there are undefined references to types (since you are missing the files). You are copying a file outside of its directory and trying to compile it. This won't work as the includes (and more) required for it to compile correctly are missing.
If you want to edit hcitool directly you should download the Bluez source, unpack it, cd into it and ./configure it. The makefile will be generated and you can use make to build the executables. If you make change to the hcitool.c file you should make sure you recompile it and are running it inside the directory as ./hcitool and not as general hcitool as this runs the executable installed to your system, rather than the one you edited.
If you want to build it outside of the Bluez directory as a sort of standalone, you will have to copy all the files and folders defined in the #include <x> statements that are needed and make a separate makefile for those, since copying the existing one will probably not work.
If you want to add a new file to the Bluez source, make sure you also make the correct Makefile edits so that it is included during compilation.
I'd like to add that hcitool has not been maintained for a long time and is on its way to being phased out of Bluez, so maybe you should take a different approach altogether!
I'm trying to compile fbsplash under Tiny Core Linux using autotools. In the middle of compilation it crashed saying "LD: attempted static link to dynamic object /usr/local/lib/libpng16.so"
I've got rid of that, commenting out option "-all-static" in the Makefile. Now it crashes after
/bin/bash: O2: not found
/bin/bash: w: not found
/bin/bash: DTARGET_KERNEL: not found
All of these options have dashes before them. It looks like:
fbcondecor_helper_CFLAGS = -O2 -w \...
fbcondecor_helper_CPPFLAGS = $(AM_CPPFLAGS) -DTARGET_KERNEL
But somehow my shell interprets them as commands without dashes.
What's wrong?
First, you are not using the autotools. You are using a configure script that was generated using the autotools. (If indeed you are running autoconf, or autoreconf, that is a different issue and there is (much) more room for error on your part.) In either case, you should never hand edit the generated Makefile. (So short answer to "What's wrong?" is, "you edited the Makefile".) Instead, add --disable-static when you run configure.
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.