Когда компилировать и связывать общий объект вручную, когда следует использовать -fPIC? - PullRequest
0 голосов
/ 27 февраля 2019

Я пытаюсь написать очень простой модуль с использованием boost-python, пытаюсь скомпилировать его вручную и пытаюсь выяснить, на каких этапах мне нужно указать CLI компилятора для создания позиционно-независимого кода.

Я заметил, что смог получить работающий разделяемый объект loadable-from-python, указав аргумент -fPIC только при связывании (и вообще без его предоставления).

В build.shниже, -fPIC предоставляется только при создании .so, а не при создании промежуточного .o объектного файла:

#!/bin/bash

INCLUDES=" -I /usr/local/Cellar/boost/1.68.0_1/include"
INCLUDES+=" -I $(dirname $(dirname $(which python)))/include/python*"
LINKARGS=" -lpython -lboost_python37"

# compile object
clang++ $INCLUDES -o hello.o -c hello.cpp
# link into shared object
clang++ -shared -fPIC $LINKARGS -o hello.so hello.o

Это создает общий объект, который способен работать:

> python test_hello.py
hello, world

Скрипт build.sh также создает загружаемый общий объект, когда конечный -fPIC отсутствует и последняя строка clang++ -shared $LINKARGS -o hello.so hello.o

Итак, мой вопрос:

  • Когда -fPIC необходимо предоставить вручную?У .o уже есть встроенная независимость позиции или независимая позиция , эффективно выбранная во время соединения ?
  • Есть ли способ избежать или обнаружить "ложные успехи"?

исходный код для разных файлов:

// hello.cpp

char const* greet()
{
  return "hello, world";
}

#include <boost/python.hpp>

BOOST_PYTHON_MODULE(hello)
{
  using namespace boost::python;
  def("greet", greet);
}

и test_hello.py

# test_hello.py

import hello
print (hello.greet())

Сценарий build.sh очень специфичен дляOS X, boost-python3, установленная через homebrew, и Python 3.7 в virtualenv.

...