ti-enxame.com

Como carregar bibliotecas extras para GDB?

Estou tentando depurar um programa CUDA, mas quando estou iniciando gdb assim:

$ gdb -i=mi <program name>
$ r <program arguments>

Estou entendendo:

/home/wvxvw/Projects/cuda/exercise-1-udacity/cs344/HW2/hw: 
error while loading shared libraries: libcudart.so.5.0: 
cannot open shared object file: No such file or directory

Process gdb-inferior killed

(formatado para facilitar a leitura)

(Estou executando o gdb usando M-xgdb) Se isso importa, então as bibliotecas CUDA estão no .bashrc

export PATH="/usr/local/cuda/bin:$PATH"
export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/usr/local/cuda/lib64"
13
user797257

erro ao carregar bibliotecas compartilhadas: libcudart.so.5.0

Este erro não tem nada a ver com GDB: seu executável, quando executado de dentro do GDB, não consegue encontrar a biblioteca de que precisa.

export LD_LIBRARY_PATH = "$ LD_LIBRARY_PATH:/usr/local/cuda/lib64"

GDB executa seu programa em um novo $Shell, então isso deveria ter funcionado. Eu me pergunto se há alguma interação com o emacs.

Em qualquer caso, este:

(gdb) set env LD_LIBRARY_PATH /usr/local/cuda/lib64
(gdb) run

deve resolver este problema.

Atualizar:

como mencionei antes, o caminho ld está definido corretamente

Não, é não é. Se fosse, você não teria problema.

Agora, eu não sei por que não está configurado corretamente. Se você realmente deseja descobrir, comece executando o GDB fora do emacs (para excluir possíveis interações do emacs).

Se o problema ainda estiver presente, gdb show env, Shell env, adicionando echo "Here" para o seu ~/.basrc, etc. deve ajudá-lo a descobrir onde as coisas não estão funcionando conforme o esperado.

21
Employed Russian

Eu também tive esse problema. Uma maneira de ver isso é que mesmo se a variável LD_LIBRARY_PATH estiver correta quando você inserir show env no gdb, pode não estar correto quando você realmente executa o programa porque o gdb executa $Shell -c <program> para executar o programa. Tente isso como um teste, execute $Shell na linha de comando e depois echo $LD_LIBRARY_PATH. Está correto? Se não, provavelmente você precisará adicioná-lo ao seu rc (.tcshrc no meu caso).

2
Tim

Tive um problema semelhante ao tentar executar o gdb no Windows 7. Eu uso o MobaXterm para acessar uma caixa de ferramentas do Linux. Instalei o gdb separadamente de http://www.gnu.org/software/gdb/ . Comecei a trabalhar certificando-me de que o gdb poderia encontrar os arquivos .dll corretos, conforme mencionado por Employed Russian. Se você tiver o MobaXterm instalado, os arquivos .dll devem aparecer no seu diretório inicial em MobaXterm/slash/bin.

o gdb no entanto não reconheceu o LD_LIBRARY_PATH variável. Para mim, funcionou quando usei a variável PATH:

    (gdb) set env PATH C:\Users\Joshua\Documents\MobaXterm\slash\bin
    (gdb) run

Eu acho que usar PATH em vez de LD_LIBRARY_PATH pode funcionar para você, desde que você coloque o caminho correto para sua biblioteca.

2
Joshua Brown

o gdb está procurando uma biblioteca, então por que você está preocupado com o caminho de inclusão? Você pode tentar definir a opção gdb "solib-search-path" para apontar para a localização da biblioteca libcudart.so.5.0.

1
anoneironaut