Referência não definida g++ [RESOLVIDO]

wellington659
(usa Ubuntu)

Enviado em 10/04/2021 - 14:19h

Boa tarde.

Estou enfrentando um problema que não entendo bem. É o seguinte, eu tenho um computador com manjaro kde e outro com linux mint, eu preciso compilar uma biblioteca c++ para uso em um projeto pessoal, pra ser mais específico é a biblioteca paho-mqtt-cpp.

No Manjaro KDE eu segui os passos de instalação do github deles (https://github.com/eclipse/paho.mqtt.cpp) e precisei adicionar esse diretório "/usr/local/lib" ao arquivo "/etc/ld.so.conf" e depois dar 'sudo ldconfig' para funcionar. E funcionou perfeitamente a biblioteca no manjaro.

Depois disso, eu fui fazer a mesma coisa no Linux Mint recém formatado. Segui todos os passos (os mesmos que segui no manjaro) do github, porém quando eu tento compilar meus códigos com a biblioteca MQTT gera erros de referência não definida para todas as classes da biblioteca (Erro ta na foto).

Já tentei reinstalar a biblioteca, instalei a versão mais recente do g++ (10.2.0), já tentei copiar a pasta '/usr/local' do manjaro para o linux mint, porém não deu certo. Meu erro é o mesmo desse link (https://github.com/eclipse/paho.mqtt.cpp/issues/136), executei o script que colocaram como resposta e também não funciona.

Eu compilo meus códigos assim: g++ -lpaho-mqttpp3 -lpaho-mqtt3as publish.cpp network.cpp

Só funciona no Manjaro.

Se alguém puder me ajudar, agradeço. Até.

paulo1205
(usa Ubuntu)

Enviado em 10/04/2021 - 22:22h

Se você está com a biblioteca instalado aem /usr/local/lib, tem de ter certeza que esse diretório aparece listado no(s) arquivo(s) de configuração do ld.so/ldcondig, que costumam ser o /etc/ld.so.conf e um ou mais arquivos dentro do subdiretório /etc/ld.so.conf.d. Se não estiver, coloque num arquivo antes de rodar o ldconfig.

echo /usr/local/lib >> /etc/ld.so.conf.d/my_libs.conf

ldconfig 

... Então Jesus afirmou de novo: “(...) eu vim para que tenham vida, e a tenham plenamente.” (João 10:7-10)

wellington659
(usa Ubuntu)

Enviado em 10/04/2021 - 22:43h

Executei esses comandos e não foi.

Aqui estão meus arquivos:

/etc/ld.so.conf

include /etc/ld.so.conf.d/*.conf



/usr/local/lib

 

/etc/ld.so.conf.d/my_libs.conf

/usr/local/lib

 

Meu /usr/local/lib está na imagem.

wellington659
(usa Ubuntu)

Enviado em 11/04/2021 - 18:52h

Resolvi meu problema de uma maneira boba e que eu não entendo. Simplesmente inverti a ordem dos itens na linha de compilação:

de:

g++ -lpaho-mqttpp3 -lpaho-mqtt3as publish.cpp network.cpp

para:

g++ publish.cpp network.cpp -pthread -lpaho-mqttpp3 -lpaho-mqtt3as

O estranho é que o primeiro comando funciona no manjaro, porém no linux mint e ubuntu mate, somente o segundo comando. O -pthread foi necessario também, e no manjaro não '-', mas o importante é compilar.

O tópico já foi resolvido, mas se puderem me explicar o porquê eu agradeço.

paulo1205
(usa Ubuntu)

Enviado em 12/04/2021 - 13:20h

Eu também não sei exatamente o motivo, mas o comando ld, que implementa o linker usado para fazer a ligação final entre nomes de símbolos e seus endereços na hora de gerar o executável, exige que todos os arquivos com código objeto que contêm as implementações sejam especificados depois dos arquivos com código que apenas usa (faz referência a) tais símbolos. É como se a cada arquivo novo que ele fosse examinando, ele mantivesse a lista de símbolos que ainda faltam ser resolvidos, mas já não guardasse mais as referências simbólicas ao que já foi resolvido ou àquilo que já apareceu mas que não foi usado.

Existem até casos em que um mesmo arquivo objeto ou biblioteca tem de ser listado mais de uma vez, em diferentes pontos da invocação do ld, se algum arquivo objeto introduzir um símbolo novo, que seja definido em algum arquivo objeto ou biblioteca que já foi examinada, Por exemplo: imagine que seu programa usa recursos das bibliotecas A e B, e que algumas funções de A usem coisas de B, e algumas funções de B usem coisas de A. Nesse caso, é muito provável que você precise fazer algo como o seguinte.

ld -o seu_executavel [...] seu_programa.o libA.a libB.a libA.a [...]

# Ao passar pelo seu programa, vai faltar resolver os símbolos de A e de B que você usou e que são implementados em  libA.a e libB.a.

# Ao passar por libA.a, vai resolver os símbolos de A que você usou, mas vai faltar resolver os símbolos de B que você usou e os que a própria libA.a usou.

# Ao passar por libB.a, vai resolver os símbolos de B que você e a libA.a usaram, mas vai faltar resolver os símbolos de A que a própria libB.a usou.

# Ao passar novamente por libA.a, vai resolver os símbolos de A que a libB.a usou. 

Quando você chama o linker indiretamente através do gcc, ele costuma ajudar, resolvendo algumas dessas questões relacionadas à ordem dos argumentos contendo código objeto por meio de algumas heurísticas e de definições contidas em arquivos de configuração. Mas, pelo visto, mesmo a heurística do GCC não consegue resolver todos os casos de interdependência, e os arquivos de configuração em diferentes sistemas (e versões) podem não ter os mesmos ajustes.


... Então Jesus afirmou de novo: “(...) eu vim para que tenham vida, e a tenham plenamente.” (João 10:7-10)

wellington659
(usa Ubuntu)

Enviado em 12/04/2021 - 14:37h

Muito obrigado pela ótima explicação. Agora eu entendi. Vlw :)