Estou tentando construir binutils
na plataforma A , que será executada na plataforma A e terá como alvo a plataforma B .
Eu tenho a fonte de binutils
in /home/cedric/source/binutils-2.29/
, e realizo as 2 compilações a seguir:
cd /home/cedric/source/
mkdir default/ && cd default/
mkdir build/ install/ & cd build/
../../binutils-2.29/configure --prefix=/home/cedric/source/default/install/
make
make install
e
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
make install
Acontece que há mais 2 diretórios em default/install
do que em lfs/install
, ou seja lib
, que contém bibliotecas estáticas e bfd
, que contém alguns cabeçalhos.opcodes
include
minha confusão
Por que essas bibliotecas e cabeçalhos estáticos são instalados (para que eles se destinam, já que binutils
ferramentas como ld
e as
etc. já foram construídas)? E por que eles desaparecem ao construir para outra plataforma?
A pesquisa que fiz ainda não eliminou minha confusão:
binutils-2.29/configure --help
e README
em binutils-2.29/
, binutils-2.29/binutils/
ebinutils-2.29/bfd/
FWIW, encontrei o seguinte na ajuda do configure, que tem algo a ver com o diretório que ele pode criar e seu valor padrão:
Installation directories:
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
[PREFIX]
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]
A resposta curta é que você espera
lib
que seja construído (ou melhor, instalado) se houver uma biblioteca para instalar einclude
se houver cabeçalhos para instalar. Geralmente os dois andam juntos (pelo menos para bibliotecas C e C++).No
binutils
caso ', as bibliotecas e os cabeçalhos associados sãolibbfd
elibopcodes
, como você mencionou.libbfd
é uma biblioteca usada para manipular arquivos objeto em uma variedade de formatos,libopcodes
é uma biblioteca usada para mapear opcodes para instruções.libbfd
é instalado por padrão para compilação no mesmo host, mas não para compilação cruzada, e é por isso que você está vendo um comportamento diferente em seus cenários. Você pode ver o padrão condicional nobfd/acinclude.m4
código-fonte. Ambas as bibliotecas devem ser construídas em todos os casos.Você só precisa
libbfd
se quiser construir o GDB. Se você deseja instalá-lo em um cenário de compilação cruzada, pode./configure
fazer isso com a--enable-install-libbfd
opção; quando você fizer isso, as bibliotecas e os arquivos de cabeçalho serão instalados no diretório específico do host e do destino apropriado (libbfd
é construído para o host, mas contém código específico do destino).