rrdtool 1.4.7 falha na compilação: glib-2.0 / glib.h

2

Eu estou tentando compilar o rrdtool do pacote fonte. Eu não uso pacotes RPM, então não me peça para instalar pacotes;)

Eu compilo todo o software necessário antes do rrdtool de acordo com o link

./ configure do rrdtool está OK.

Mas quando eu faço, recebi o seguinte erro:

      CC     rrdcached-rrd_daemon.o
rrd_daemon.c:108:27: erreur: glib-2.0/glib.h : Aucun fichier ou dossier de ce type
rrd_daemon.c:246: erreur: expected â=â, â,â, â;â, âasmâ or â__attribute__â before â*â token
rrd_daemon.c: In function âadd_response_infoâ:
rrd_daemon.c:540: attention : implicit declaration of function âva_startâ
rrd_daemon.c:540: attention : nested extern declaration of âva_startâ
rrd_daemon.c:546: attention : implicit declaration of function âva_endâ
rrd_daemon.c:546: attention : nested extern declaration of âva_endâ
[...]

glib-2.0 / glib.h existe no meu sistema, em /usr/local/glib-2.34.0/glib/glib.h

Eu configurei a variável env PKG_CONFIG_PATH que contém o caminho do glib. /usr/local/glib-2.34.0/lib/pkgconfig /

Eu vi um tópico sobre isso, mas nada para o meu caso.

Olhando no config.log tudo parece OK!

    
por Hugo 14.03.2013 / 12:05

1 resposta

1

" Aucun fichier ou dossier de ce type " == "Nenhum tal arquivo ou diretório"

PKG_CONFIG_PATH contém caminhos (não padrão) para adicionar, a fim de encontrar arquivos .pc extras, não os próprios pacotes. Se você tiver o arquivo .pc correto nesse diretório, ele deve funcionar.

Verifique a saída de:

pkg-config --cflags --libs glib-2.0

(com e sem definir PKG_CONFIG_PATH )

Ele deve mostrar o caminho de instalação do glib-2.0 para includes & bibliotecas, isso é meu, instalado em /usr/local/ :

-I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include  \
-L/usr/local/lib -lglib-2.0

Se estiver errado, verifique o arquivo .pc .

No entanto , o caminho que você dá para glib.h parece mais com a fonte descompactada, não com uma instalação completa do glib-2.0 . Você já instalou e construiu o glib-2.0? Se você está construindo seguindo o URL de instruções, não parece correto, e você precisa repetir essa etapa.

Não há razão para não fazer um configure / make / install normal de alguns desses pacotes para /usr/local , especialmente glib-2.0 , zlib , libpng , libXML2 - a menos que eles entrem em conflito com algo que você já tenha instalado.

A lógica por trás do documento de construção RRDtool é construir tudo sob /tmp e instalar tudo sob /opt para torná-lo o mais auto-suficiente possível. Embora seja provável que seja um método razoavelmente robusto, existem algumas desvantagens (incluindo o requisito de definir várias variáveis de ambiente mágico).

Atualização: o problema é que o caminho de instalação do glib-2.0 está em conflito com as inclusões usadas no rrdtool. Quando você instalá-lo em /usr/local/glib-2.34.0/ , o .pc é construído para especificar um diretório de inclusão de /usr/local/glib-2.34.0/include/glib-2.0 . Este caminho já contém o subdiretório glib-2.0 so quando o rrdtool tenta incluir <glib-2.0/glib.h> falha. Acredito que este seja um problema rrdtool, ele é mascarado quando o glib-2.0 é instalado em um local "esperado" em /usr ou /usr/local (e, presumivelmente, quando você usa os caminhos de diretriz de compilação exatamente).

Se você instalar em /usr/local , um caminho de inclusão de /usr/local/include fará com que " #include <glib-2.0/glib.h> " funcione corretamente.

Como uma correção, sugiro que você construa e instale todas as dependências em /usr/local (então você só precisa definir PKG_CONFIG_PATH=/usr/local/lib/pkgconfig ) ou seguindo as instruções de compilação rrdtool exatamente, ou você pode definir CFLAGS para onde você instalou o glib-2.0 antes de executar configure , por exemplo:

export CFLAGS="-I/usr/local/glib-2.34.0/include"

(por exemplo, um diretório acima do relatado por pkg-config --cflags glib-2.0 )

Você pode ver melhor o que está acontecendo se a compilação quebrar:

make AM_DEFAULT_VERBOSITY=1

logo após um erro, os comandos usados serão repetidos e impressos desta vez, para que você possa verificar os gcc -I flags.

OK, encontrado um relatório de erros , ele foi corrigido (embora o título " Corrigir compilação com localização simplificada não padronizada "é um pouco enganador). Não houve nova versão estável desde então. FWIW, existem várias perguntas não respondidas na lista de usuários que parecem ser o mesmo problema.

    
por 14.03.2013 / 13:31