Compilando a lib-epp da Registro.br com validação de dependências e troubleshooting real

Integrar registrador com Registro.br via EPP exige uma cadeia de build estável. Na prática, o erro mais comum não está no código EPP em si, mas na camada de dependências C/C++ (headers, libs e paths de include). Neste artigo documento o fluxo que utilizei para compilar libepp-nicbr com validação real de ambiente e correção de falhas recorrentes.

Contexto técnico

A libepp-nicbr implementa o protocolo EPP para operações como:

• consulta de domínio;
• criação/alteração de objetos;
• interação com extensões específicas do registry.

No meu cenário, a biblioteca era requisito para automatizar provisionamento de domínio em processo interno de operações.

Pré-requisito crítico: Xerces-C compilado e funcional

Antes da lib-epp, valide Xerces-C instalado e linkável. Sem isso, o configure da lib-epp pode passar parcialmente e falhar em make.

Referência: /blog/compilando-biblioteca-xerces-c.html

Checagens rápidas:

ldconfig -p | grep -i xerces
pkg-config --modversion xerces-c || echo "pkg-config sem xerces-c"

Download da lib-epp

cd /usr/local/src
wget -O libepp.tar.gz https://ftp.registro.br/pub/libepp-nicbr/libepp-nicbr-1.20_1.tar.gz
tar -xvf libepp.tar.gz
cd libepp-*

Etapa de configuração

Primeira execução padrão:

./configure

Se o ambiente estiver íntegro, prossiga para compilação. Se houver erro de header não encontrado, não force make; corrija dependências antes.

Compilação, instalação e documentação

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

Após instalar, atualize cache de bibliotecas (quando aplicável):

ldconfig

Falha real mais comum: detecção quebrada do readline

No meu caso, o configure acusou:

checking for /usr/include/readline/readline/readline.h ... no
checking for /usr/include/readline/readline/history.h ... no

Mesmo com readline instalado:

find /usr/include -name readline.h
# /usr/include/readline/readline.h

A causa era diferença de caminho esperado pelo script de build.

Correção aplicada

ln -s /usr/include/readline /usr/include/readline/readline
ln -s /usr/include/readline /usr/include/readline/history

./configure --with-readline-includes=/usr/include/readline

Nova validação esperada:

checking for /usr/include/readline/readline/readline.h ... yes
checking for /usr/include/readline/readline/history.h ... yes

Validação funcional com shepp

A validação final não é apenas “make passou”. Eu testo o cliente shepp para confirmar que a cadeia de linking está íntegra:

shepp

Saída esperada:

Welcome to shepp version 1.25, an EPP shell client!
Type: 'help' for available commands.
shepp:

Se shepp não abre, revise LD_LIBRARY_PATH e ldconfig -p.

Checklist pós-instalação

1. validar binário:

which shepp

1. validar bibliotecas carregadas:

ldd "$(which shepp)"

1. registrar versão compilada para auditoria:

shepp --version || shepp <<<'quit'

1. salvar output de configure e make no change log interno.

Hardening operacional

Em produção, recomendo:

• compilar em staging idêntico ao host final;
• versionar configure flags usadas na entrega;
• evitar sobrescrever libs de sistema sem controle;
• manter rollback com tarball da versão anterior.

Conclusão

Compilar libepp-nicbr é simples quando o ambiente C/C++ está coerente, mas fica instável quando paths de include divergem entre distribuição e script de build. O ponto que resolveu de forma definitiva no meu caso foi tratar a resolução de readline antes do make, validar com shepp e registrar o resultado como procedimento padrão de operação.

Este post está licenciado sob CC BY-NC.