I am trying to build binutils on platform A, which will be run on platform A and targets platform B.

I have the source of binutils in /home/cedric/source/binutils-2.29/, and I perform the following 2 builds:

cd /home/cedric/source/
mkdir default/ && cd default/
mkdir build/ install/ & cd build/
../../binutils-2.29/configure --prefix=/home/cedric/source/default/install/
make install


cd /home/cedric/source/
mkdir lfs/ && cd lfs/
mkdir build/ install/ & cd build/
../../binutils-2.29/configure --prefix=/home/cedric/source/lfs/install/ --target=x86_64-lfs-linux-gnu
make install

It turns out that there are 2 more directories in default/install than in lfs/install, i.e. lib, which contains bfd and opcodes static libraries, and include, which contains some headers.

My Confusion

Why are these static libraries and headers installed (what are they intended for, since binutils tools like ld and as etc. are already built)? And why do they disappear when building for another platform?

Research that I've done yet didn't eliminate my confusion:

binutils-2.29/configure --help and README in binutils-2.29/, binutils-2.29/binutils/, and binutils-2.29/bfd/

FWIW, I found the following in the configure help, which has something to do with directory it may create and their default value:

Installation directories:
  --prefix=PREFIX         install architecture-independent files in PREFIX
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX

By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc.  You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:
  --bindir=DIR            user executables [EPREFIX/bin]
  --sbindir=DIR           system admin executables [EPREFIX/sbin]
  --libexecdir=DIR        program executables [EPREFIX/libexec]
  --sysconfdir=DIR        read-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIR    modifiable architecture-independent data [PREFIX/com]
  --localstatedir=DIR     modifiable single-machine data [PREFIX/var]
  --libdir=DIR            object code libraries [EPREFIX/lib]
  --includedir=DIR        C header files [PREFIX/include]
  --oldincludedir=DIR     C header files for non-gcc [/usr/include]
  --datarootdir=DIR       read-only arch.-independent data root [PREFIX/share]
  --datadir=DIR           read-only architecture-independent data [DATAROOTDIR]
  --infodir=DIR           info documentation [DATAROOTDIR/info]
  --localedir=DIR         locale-dependent data [DATAROOTDIR/locale]
  --mandir=DIR            man documentation [DATAROOTDIR/man]
  --docdir=DIR            documentation root [DATAROOTDIR/doc/PACKAGE]
  --htmldir=DIR           html documentation [DOCDIR]
  --dvidir=DIR            dvi documentation [DOCDIR]
  --pdfdir=DIR            pdf documentation [DOCDIR]
  --psdir=DIR             ps documentation [DOCDIR]

The short answer is that you’d expect lib to be built (or rather, installed) if there’s a library to install, and include if there are headers to install. Usually the two go together (at least for C and C++ libraries).

In binutils’ case, the libraries and associated headers are libbfd and libopcodes, as you mention. libbfd is a library used to manipulate object files in a variety of formats, libopcodes is a library used to map opcodes to instructions. libbfd is installed by default for same-host compilation, but not for cross-compilation, which is why you’re seeing different behaviour in your scenarios. You can see the conditional default in bfd/acinclude.m4 in the source code. Both libraries should be built in all cases.

You only need libbfd if you want to build GDB. If you do want to install it in a cross-compilation scenario, you can tell ./configure to do so with the --enable-install-libbfd option; when you do this, the libraries and header files will be installed in the appropriate host- and target-specific directory (libbfd is built for the host but contains target-specific code).

  • I find this snippet in bfd/acinclude.m4 and understand why libbfd is not build now. But what's the logic behind this conditional installation? Are libraries contained in lib/ meant to be libraries that could be linked on target rather than host? – Cedric Sun Dec 18 '17 at 1:51
  • + thus, if i need these libraries when targeting another platform, a cross-compilation for them using a cross-compiler must be performed explicitly and manually? – Cedric Sun Dec 18 '17 at 2:08
  • See my updated answer; there’s an option you can use to request installation of the files when cross-compiling, there’s no manual build involved. The logic behind the distinction is that libraries contained in lib in the main prefix (/usr or /usr/local) are intended to be used on the host and work generally; when cross-compiling, the libbfd you end up with does run on the host, but is target-specific. – Stephen Kitt Dec 18 '17 at 12:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.