Esse post irá mostrar uma pequena dica para quem deseja começar a testar programas de terceiros de uma forma organizada, de modo a preservar os “originais” do sistema e permitir isolar as versões.
Na maioria dos casos quando testamos um programa pelo código-fonte, utilizamos a forma definida no autoconf, muito tradicional no sistema GNU, onde: descompactamos, verificamos o sistema (configure), compilamos (make) e copiamos para a pasta correspondente na hieraquia de pastas do sistema (make install).
tar zxvf programa.tar.gz cd programa ./configure make make install
Contudo, se estamos trabalhando com versões de desenvolvimento não queremos copiar os binários gerados para o sistema. Pode ser que eu tenha uma versão X do software funcionando e a verão Y que desejo testar quebre a compatibildade com algum outro programa do sistema. Vamos considerar o seguinte exemplo: suponha que você viu no site do projeto binutils que há um novo linker (A new, faster, ELF only linker, still in beta test.) e deseje compilar esta nova versão para testá-la. Utilizando o processo descrito acima você irá sobreescrever a versão distribuida pelos desenvolvedores da sua distribuição e não queremos que isso ocorra, principalmente quando o software está na versão beta do seu desenvolvimento. Vamos pensar outra maneira:
wget http://ftp.gnu.org/gnu/binutils/binutils-2.9.tar.gz tar zxvf binutils-2.9.tar.gz cd binutils-2.9
Se olharmos as opções de ajuda (–help) do script configure vemos que podemos setar o prefixo da instalação:
--prefix=MYDIR install into MYDIR [/usr/local]
Então basta escolher o diretório para colocar os executáveis.
./configure --prefix=../install
Mas ainda há uma maneira, ao meu ver, mais organizada, principalmente se você está desenvolvendo um software. Depois de descompactar o programa, crie dois diretórios: um chamado build que irá conter os arquivos gerados pelo compilador e um install que terá apenas os executáveis.
cd .. mkdir build install
No final teremos os diretórios:
. |-- binutils-2.9 |-- build `-- install
Uma pasta com o código-fonte, outra com os arquivos objeto (resultado da etapa de compilação) e o executáveis.
cd build ../binutils-2.9/configure --prefix=$(cd ../install && pwd)
Depois disso siga normalmente o processo de make e make install lembrando que os executáveis agora ficarão na pasta install/. Essa metodologia é simples e muito útil, principalmente quando estamos trabalhando com algum programa de controle de versão (ex.: git) e desenvolvendo testes em arquiteturas diferentes.
Caso especial: kernel
O Linux não possui um script de configuração (configure) portanto é preciso especificar no ‘make’ no local. Para manter a mesma árvore compilando para diferentes arquiteturas.
alias make-cross= \ "make O=../buildsh ARCH=sh CROSS_COMPILE=sh4-unknown-linux-gnu-" make-cross menuconfig make-cross
Arquivado em: Linux, programação

Gostei do post…. eu costumo usar o –prefix ou até mesmo criar um pacote com nome diferente tipo ‘beta_binutils-versao-arch’
Bom post!