LD_PRELOAD не работает с моей программой

Для тестирования LD_PRELOAD я написал свой собственный getpid, который печатает что-то перед вызовом исходного getpid с помощью dlsym. Код приведен ниже.

#define _GNU_SOURCE

#include <unistd.h>
#include <stdio.h>
#include <dlfcn.h>

typedef pid_t (*getpidType)(void);

pid_t getpid(void)
{
    printf("Hello, getpid!\n");
    getpidType f = (getpidType)dlsym(RTLD_NEXT, "getpid");
    return f();
}

Однако, когда я использую такой getpid в своей программе и запускаю ее с помощью LD_PRELOAD, набрав LD_PRELOAD=./prelib.so ./prog, я получаю следующую ошибку.

./prog: symbol lookup error: ./prelib.so: undefined symbol: dlsym

Но если я делаю LD_PRELOAD=./prelib.so bash -c 'echo $$', такой ошибки нет. Любая идея, что здесь происходит.


person pythonic    schedule 22.05.2012    source источник
comment
Вы связываетесь с -ldl?   -  person Nikolai Fetissov    schedule 22.05.2012
comment
Вы export это сделали? т.е. export LD_PRELOAD потом. Это переменная среды, поэтому в какой-то момент ее нужно экспортировать именно так.   -  person FatalError    schedule 22.05.2012
comment
Ссылка на что, моя программа или компиляция библиотеки для LD_PRELOADed?   -  person pythonic    schedule 22.05.2012
comment
FatalError: я думаю, вам нужно экспортировать для LD_LIBRARY_PATH, а не для LD_PRELOAD.   -  person pythonic    schedule 22.05.2012
comment
@FatalError — вызов LD_PRELOAD=./prelib.so ./prog эквивалентен экспорту LD_PRELOAD перед вызовом ./prog   -  person Michał Kosmulski    schedule 22.05.2012
comment
Включите LD_DEBUG и посмотрите, что он вам скажет. Похоже, что в первую очередь не удается найти dlsym, для которого, согласно @NikolaiNFetissov, требуется -ldl. Я не могу объяснить, почему это работает с bash, если вы пропустили это.   -  person bmargulies    schedule 22.05.2012
comment
@bmargulies: Вероятно, потому что bash использует libdl. Вы можете увидеть это, запустив ldd /bin/bash   -  person Hasturkun    schedule 22.05.2012
comment
Действительно, пока основная программа связывает libdl, она уже загружена в глобальное пространство символов, и .so не нужно явно зависеть от нее. Но чтобы работать во всех случаях, .so не требует явного включения.   -  person R.. GitHub STOP HELPING ICE    schedule 22.05.2012


Ответы (1)


Связывание его с libdl.so.2 с помощью -ldl в make-файле решило проблему.

person pythonic    schedule 22.05.2012