Personalizando CFLAGS por pacote no Gentoo

Bruno Lustosa — Tue, 10 Nov 2009 03:06:24 +0000

O Gentoo é uma distribuição Linux famosa por ter todos os seus pacotes compilados do código fonte durante a instalação. Dessa forma, é possível gerar binários otimizados especificamente para a máquina onde vai rodar, especificando as flags que serão passadas para o compilador.
Além disso, também é possível especificar quais features cada pacote terá disponível. Assim, é possível, por exemplo, ter um pacote instalado sem suporte a determinadas coisas que não serão necessárias, evitando-se assim a instalação como dependência de pacotes que não serão usados.
Um problema que tive em uma instalação foi exatamente com as CFLAGS, as tais flags de otimização que são passadas para o compilador. Estava usando flags bem básicas, assim:

CFLAGS="-O2 -fomit-frame-pointer -march=nocona -pipe"

Essas flags especificam uma otimização nível 2 (pode ir de 0 a 3 – o 3 quebra alguns pacotes, por isso é recomendável usar o 2), e especifica também para qual conjunto de instruções os binários serão gerados. No meu caso, estou dizendo que os binários deverão ser compilados para se usar todo o poder do processador nocona (os dual/quad cores da Intel).
Até aí, tudo funcionando bem. Montei um sistema todo com essas flags, e estava tudo muito bem, até que precisei instalar o Bacula, um software para se fazer backups de sistemas completos.
O Bacula, com as CFLAGS padrões estava gerando um binário quebrado. Pesquisando, descobri que o projeto Hardened do Gentoo, que usa uma série de artifícios para gerar executáveis mais seguros e imunes contra ataques como buffer overflow era o responsável, pois por padrão ele passa a flag “FORTIFY_SOURCE” para o compilador, e isso estava quebrando o Bacula.
Uma das formas de se resolver esse problema seria alterando as CFLAGS no /etc/make.conf, adicionando -U_FORTIFY_SOURCE a elas. Porém, o grande problema é que as CFLAGS são válidas globalmente, e dessa forma, todos os pacotes seriam compilados com essa flag extra, matando parte dos recursos do projeto Hardened.
O que eu queria era poder compilar somente o Bacula com essa flag extra. Uma das formas é usar o diretório /etc/portage/env para criar variáveis de ambientes específicas para cada pacote.
Basta seguir os seguintes passos:

1. Pegue o nome completo do pacote, na forma categoria/pacote. No caso do Bacula, o nome completo é app-backup/bacula.
2. Crie o arquivo /etc/portage/env/categoria/pacote, ou no nosso caso, /etc/portage/env/app-backup/bacula. Caso o diretório “env” não exista, crie toda a árvore necessária.
3. Nesse arquivo, você pode especificar as variáveis de ambiente que serão definidas exclusivamente para a compilação do pacote. Assim, podemos definir CFLAGS neste arquivo:
```
CFLAGS="${CFLAGS} -U_FORTIFY_SOURCE"
```

Pronto. Com isso, temos a flag extra -U_FORTIFY_SOURCE adicionada às flags globais, e só serão utilizadas para o pacote em questão.

O limite de 4 (ou 3?) Gb de memória

Bruno Lustosa — Fri, 26 Dec 2008 12:18:10 +0000

Quem tem um computador com 4 Gb ou mais de memória e usa um sistema operacional de 32 bits já deve ter percebido que o computador não consegue enxergar toda a memória, ficando limitado em algo entre 3 e 4 Gb, dependendo do sistema operacional.

O problema

A razão desse “problema” é simples: o sistema operacional é de 32 bits. Se o sistema operacional é de 32 bits, significa que o maior número que ele pode colocar alocar em um registrador (pequena unidade de memória que fica dentro do processador) é um número de 32 bits. Como endereços de memórias são números, o espaço máximo possível de endereçamento tambem tem 32 bits. E fazendo a conta, temos que 2^32 = 4 Gb.

No Windows, o espaço fica limitado em 3 Gb, porque 1 Gb é reservado para o kernel do sistema.
Pronto, já entendemos o porque do problema. Agora, o que fazer para solucioná-lo?

A solução limpa

A primeira solução, e a melhor delas, é migrar para um sistema operacional de 64 bits. Além do ganho no espaço de endereçamento, programas em 64 bits fazem uso melhor do processador.

Considero esta solução como limpa por ser algo nativo. Os programas são compilados em modo 64 bits, e naturalmente já possuem este espaço de endereçamento.

Existem versões 64 bits dos sistemas operacionais mais populares: Linux, Windows (XP/Vista).

Porém, existem casos em que a migração não pode ser feita, e aí existe uma “gambiarra” que pode ser feita pra se aumentar um pouco o espaço de endereçamento.

A solução porca

Praticamente todos os processadores de hoje em dia (Intel do Pentium Pro em diante, e AMD do Athlon em diante) suportam PAE, ou Physical Address Extension (Extensão de endereçamento físico). A idéia é adicionar mais 4 bits no espaço de endereçamento, aumentando para 36 bits, que nos dá: 2^36 = 64 Gb de espaço.

Claro, o PAE depende tambem do sistema operacional. Chamo de gambiarra, porque os programas continuam enxergando no máximo 32 bits (ou seja, os programs continuam limitados a 4 Gb de memória), e quem gerencia o espaço total é o sistema operacional. Cabe a ele decidir quais programas acessam quais espaços de 32 bits. Não é algo nativo.

Além disso, o sistema vai ficar todo um pouco mais lento, devido ao processamento extra que precisa ser feito pelo sistema operacional para gerenciar esses 4 bits extras.

Windows

No mundo Windows, o espaço total suportado pelo sistema operacional depende da versão. O XP enxerga no máximo 4 Gb de memória, mesmo com PAE. Outras versões variam um pouco.

Para se utilizar a memória extra provida pelo PAE, é preciso abrir o arquivo boot.ini, e adicionar o parâmetro /PAE na linha correspondente.

O lado ruim de usar no Windows é que o espaço total não depende somente do PAE, e sim da versão do Windows utilizada. Ou seja, além da restrição dos 64 Gb, o sistema operacional também impõe restrições extras, de modo que dependendo da versão, o sistema continuará sem conseguir enxergar a memória inteira (vide Windows XP e o limite de 4 Gb).

Linux

No Linux, as coisas são um pouco mais tranquilas. Basta habilitar o suporte a PAE no kernel do sistema, e ter todos os módulos também compilados com suporte a PAE. A opção relevante fica na parte “Processor type and features”, em “High Memory Support”.

Ali se escolhe entre desligado, onde o sistema enxerga no máximo 1 Gb de memória, e é a opção recomendada para computadores com 1 Gb ou menos de memória, por ser mais rápida, 4 Gb ou 64 Gb. A opção desejada é a 64 Gb, para utilizar todos os 36 bits disponibilizados, sem nenhuma restrição adicional, como acontece no Windows.

Na prática

Em casa, estou utilizando tanto o Windows XP x64 Edition quanto o Linux (Ubuntu 8.10 – 64 bits) sem maiores problemas. No Windows, consegui driver pra tudo nos sites dos fabricantes (Abit – placa mãe, nVidia – placa de vídeo). No Linux, o Ubuntu cuidou de tudo pra mim, embora possam existir problemas com o driver binário da nVidia (tentei fazer o upgrade para o 9 e não consegui).

No Linux, os únicos programas que tive problema foram os emuladores, que por precisarem de muita velocidade, tem partes que são feitas diretamente em Assembly (pra 32 bits), e por isso nem sempre compilam diretamente em 64 bits. Porém, existe sempre a possibilidade de se executar programas 32 bits, bastando ter as bibliotecas 32 bits que o programa necessita.

No Windows, até agora, não tive problema nenhum.

Ataraxia! » linux