GCC не связывает библиотеку с нестандартным путем - PullRequest
Новая
       18

GCC не связывает библиотеку с нестандартным путем

2 голосов
/ 14 мая 2009

У меня уже установлены библиотеки C ++ boost на моей машине Fedora10, но я хочу использовать более новую версию, которую я храню в некотором месте в моей домашней папке. Я хочу, чтобы g ++ использовал файлы включения и библиотеки из папки моей домашней папки вместо папки по умолчанию (/usr/include and /usr/lib64).

В этом отношении я также объявил CPLUS\_INCLUDE\_PATH and LIBRARY\_PATH переменные окружения в моем ~/.bashrc файле, как объяснено здесь .

Теперь, когда я бегу, 

g++ -o hello.so -fPIC hello.cpp -shared -lboost_python

Препроцессор использует включаемые файлы из моей домашней папки, переопределяя местоположение по умолчанию (как и должно быть, потому что CPLUS\_INCLUDE\_PATH имеет более высокий приоритет в пути поиска). Но компоновщик, похоже, не следует тому же правилу приоритета. Он всегда использует libboost_python.so из местоположения по умолчанию /usr/lib64 вместо первого поиска LIBRARY\_PATH. Он только ссылается на библиотеку libboost\_python.so в моей домашней папке, когда я явно указываю с помощью переключателя -L. Это действительно неудобно.

1 Ответ

2 голосов
/ 14 мая 2009

Переключатель -L - это стандартный способ указать компилятору, где искать библиотеки. Напишите make-файл, в котором собраны ваши ключи компилятора / компоновщика - вы обнаружите, что стоит потратить свое время. Вы можете сделать что-то вроде: 

MY_LIBPATH += -L$(BOOST_LIB_PATH)
MY_INCPATH += -I$(BOOST_INC_PATH)
hello.so: hello.cpp
    g++ -o $@ -fPIC $(MY_INCPATH) $(MY_LIBPATH) hello.cpp -shared -lboost_python

И затем вы можете управлять этим через среду (конечно, может быть много вариантов того, как структурировать make-файл.)

...