Compilando a biblioteca Xerces-C com validação de toolchain e instalação limpa

A biblioteca Xerces-C é base para várias integrações XML em ambiente corporativo, incluindo stacks que dependem de parsing/validação robusta em C++. Quando a instalação é feita sem checklist, os problemas aparecem depois, na etapa de link de outros projetos. Neste guia, descrevo o processo completo que utilizo para instalar Xerces-C com previsibilidade.

Cenário e objetivo

Objetivo: compilar e instalar xerces-c-3.2.5 em host Linux para uso como pré-requisito da libepp-nicbr e outras aplicações.

Riscos mitigados neste procedimento:

1. compilar sem dependências mínimas;
2. misturar bibliotecas de sistema com bibliotecas manuais sem controle;
3. não validar o runtime após make install.

Dependências mínimas

Debian/Ubuntu

sudo apt update
sudo apt install -y build-essential libssl-dev libreadline-dev libncurses5-dev libcppunit-dev pkg-config doxygen

RHEL/CentOS

yum groupinstall -y "Development Tools"
yum install -y xerces-c-devel openssl-devel readline-devel ncurses-devel cppunit-devel pkgconfig doxygen

Download de fonte confiável

cd /usr/local/src
wget http://archive.apache.org/dist/xerces/c/3/sources/xerces-c-3.2.5.tar.bz2
tar -xjvf xerces-c-3.2.5.tar.bz2
cd xerces-c-3.2.5

Se o ambiente exigir controle rígido, valide checksum do pacote antes de compilar.

Configuração de build

./configure

Durante o configure, eu verifico especialmente:

• compilador C++ detectado;
• caminhos de include/lib coerentes;
• ausência de mensagens not found em libs críticas.

Compilação e instalação

make -j"$(nproc)"
make install
make doc
ldconfig

make doc é opcional para runtime, mas útil para ambiente de engenharia.

Verificações pós-instalação

1. validar se biblioteca foi registrada:

ldconfig -p | grep -i xerces

1. validar path de cabeçalhos:

find /usr/local/include -iname '*xerces*' | head

1. validar pkg-config (se aplicável):

pkg-config --cflags --libs xerces-c || true

Troubleshooting que já enfrentei

configure passa, make falha em linking

Causa comum: bibliotecas duplicadas entre /usr/lib e /usr/local/lib.

Ação: revisar LD_LIBRARY_PATH, ldconfig, e limpar build anterior.

Headers em caminho inesperado

Causa comum: distro com layout diferente do esperado pelo projeto consumidor.

Ação: padronizar include path no projeto dependente em vez de “forçar” cópias manuais de header.

Permissão insuficiente em diretórios de instalação

Sintoma: make install falha com Permission denied.

Ação prática:

sudo make install
sudo ldconfig

Se o processo de build foi executado como usuário comum, mantenha a compilação sem privilégio e eleve somente na instalação.

Fluxo de validação com projeto dependente

Depois de instalar, eu valido com um projeto consumidor real (no meu caso, libepp-nicbr) para confirmar que não ficou apenas “instalado”, mas também consumível em runtime.

cd /usr/local/src/libepp-*
./configure
make -j"$(nproc)"

Se o projeto dependente compila sem erro de header/linking, a instalação do Xerces-C está operacionalmente aprovada.

Boas práticas operacionais

• versionar o procedimento de build junto com o projeto consumidor;
• registrar versão exata (3.2.5) para reprodutibilidade;
• validar em staging antes de aplicar em host crítico;
• manter pacote-fonte e logs do build para auditoria técnica.

Conclusão

Compilar Xerces-C de forma estável é menos sobre executar make e mais sobre controlar dependências, path de bibliotecas e validação pós-instalação. Esse processo evita falhas em cascata quando outras integrações C/C++ entram em cena.

Este post está licenciado sob CC BY-NC.