error while loading shared libraries: libfoo.so:
  cannot open shared object file: No such file or directory

Imagine um ambiente de desenvolvimento, onde estamos codificando uma biblioteca. Não queremos instalar esta biblioteca no sistema só para testá-la. Uma alternativa é configurar a variável de ambiente LD_LIBRARY_PATH, apontando para o diretório onde se encontra o binário da biblioteca. Assim o dynamic loader vai procurar pela biblioteca também neste diretório.

$ export LD_LIBRARY_PATH=/home/user/libfoo/

Uma segunda opção seria no momento em que seu programa é “linkado”, passar o caminho da biblioteca para a opção -rpath do linker. Isto coloca o caminho de busca pela biblioteca dentro da estrutura do executável (ELF). A opção -Wl do gcc serve para passar parâmetros para o linker (usando “,” no lugar de espaço) que é chamado automaticamente após a compilação.

$ gcc -shared -Wall -o libfoo.so foo.c

$ gcc -Wall -o test test.c -L/home/user/libfoo/ -lfoo

$ ./test # Erro! Não acha a biblioteca libfoo.so

$ gcc -Wall -Wl,-rpath,/home/user/libfoo/ -o test test.c \
  -L/home/user/libfoo/ -lfoo

$ ./test # Funciona!

Porém, a simples existência do arquivo .pid não garante que o processo esteja em execução. Ele pode ter sido fechado de uma forma inesperada e não o apagou. Então, temos que ler o conteúdo do arquivo .pid e certificar que o processo com aquele número de PID está em execução.

A forma mais fácil de fazer isso é enviando o sinal 0 para o processo. O sinal 0 é especial e não é de fato enviado, caso contrário o processo destinatário poderia ser fechado se não tratasse o sinal, mas o retorno da função indica se um sinal real seria enviado com sucesso. O código a seguir exemplifica como aplicar a técnica em C:

int main(int argc, char **argv)
{
    unsigned int pid;

    if (argc != 2) {
        printf("Uso: %s PID\n", argv[0]);
        return 1;
    }

    pid = (unsigned int) atoi(argv[1]);

    if (!kill(pid, 0))
        printf("%d esta em execucao.\n", pid);
    else
        printf("%d nao esta em execucao.\n", pid);

    return 0;
}

A mesma técnica pode ser aplicada no terminal:

$ kill -0 123
$ echo $? # Imprime 0 se o PID 123 existir, 1 caso contrario

Note que você precisa ter permissão para enviar um sinal para um determinado processo. Para um usuário sem privilégios especiais, a dica só vai funcionar para verificar a existência de processos iniciados pelo próprio usuário.

Para pegar o endereço de uma interface diferente basta colocar o nome dessa interface no lugar de eth0.

É interessante que o comando seja colocado entre parênteses, para não modificar o valor da variável de ambiente LANG da sua sessão de shell atual (que controla o idioma em que os aplicativos são exibidos).

Utilizando o wget:

echo $(wget -qO- http://www.whatismyip.com/automation/n09230945.asp)

Utilizando o lynx (ou o links2):

lynx -dump http://www.whatismyip.com/automation/n09230945.asp

O Linux mantém em memória os dados recentemente carregados do disco, e ali eles ficam enquanto possível. Isso acelera o processo de carregamento destes mesmos dados no futuro, como na execução de programas e leitura de arquivos.

As áreas na memória que carregam esses dados chamam-se caches. Você pode notar os caches em ação quando roda um programa pela segunda vez e ele carrega muito mais rapidamente que na primeira.

Mas às vezes é necessário fazer algum teste onde esse efeito de cache deve ser anulado, por exemplo, medir tempo de carregamento de um programa, ou o tempo necessário para processar algum arquivo. Já vi gente reiniciando a máquina só para poder ter uma medição confiável no tempo de carregamento de um programa.

Para economizar nosso tempo e paciência, e ter um efeito semelhante sem precisar reiniciar a máquina, podemos pedir ao kernel que limpe todos os caches que estiverem em memória. Basta usar uma entrada no /proc, existente nas versões mais recentes do kernel, rodando o comando:

echo 1 > /proc/sys/vm/drop_caches

Se seu programa explode em uma função OpenGL sem nenhum motivo aparente, verifique se a chamada está sendo feita desde a thread onde a OpenGL foi inicializada.

As bibliotecas que vêm com os drivers da NVidia (libGL.so) para X não são muito tolerantes com programas com multi-threading, enquanto a libGL.so da Mesa parece ser mais tolerante a isso. Isso pode levar à confusa situação de o programa rodar sem problemas em alguns sistemas e morrer em outros.

Nos casos em que tive esse problema, o segfault ocorreu na função glViewport(), mas é provável que ocorra com outras funções.

Não existe solucão mágica, mas um workaround — para ao menos testar a hipótese — é mudar o LD_LIBRARY_PATH para apontar ao libGL.so da xorg (se não a tem instalado, tente copiar de outro lugar etc). Verifique se a biblioteca correta está sendo usada com ldd e teste. Já a solucão definitiva é mover as chamadas OpenGL que acessam o mesmo contexto para uma única thread (ou protegê-las com mutexes).