OSX, ghci, dylib, какой правильный путь?

Мне нужно создать некоторый код C, а затем ссылаться на этот код C через FFI. Я хотел бы использовать привязку изнутри ghci на osx.Одно из моих ограничений состоит в том, что я не могу просто передать исходники C в ghc в файле .cabal. Это связано с ограничением ghc / cabal, которое может быть исправлено в следующем выпуске ghc (но я хочу, чтобы мой код работал сейчас и в более старых выпусках). Подробнее см. В этой ошибке .

Суть этой ошибки в том, что код C должен быть скомпилирован с некоторыми модулями Objective-C, и ghc неверно интерпретирует их как скрипты компоновщика. Я много чего пробовал, и единственное, что сработало, - это создание файлов самостоятельно с помощью make-файла. На самом деле, это не должно быть проблемой, потому что это должно быть так же, как если бы я решил использовать внешнюю библиотеку C, которую я не создавал сам. Ради этой проблемы, давайте представим, что это отдельная библиотека C, которую я могу легко перестроить с другими параметрами.

Если я построю библиотеку C как .a, тогда ghci пожалуется, что не может открыть .dylib. Мой первый вопрос: зачем ghci нужен .dylib и действительно ли он его использует?

Когда я создаю dylib, я получаю segfault при загрузке кода в ghci .

Имейте в виду. , эта привязка уже работает на других платформах, как Linux, так и Windows, и эта привязка отлично работает в osx, когда я компилирую вместо использования ghci. Эта проблема характерна для комбинации osx / ghci.

В приведенной выше трассировке я использую gdb, но он вылетает независимо от того, использую ли я gdb. Я отследил его до строк, вызывающих сбой:

void _glfwClearWindowHints( void )
{
    memset( &_glfwLibrary.hints, 0, sizeof( _glfwLibrary.hints ) );
}

Причина сбоя в том, что строка memset, ну на самом деле проблема в том, что при запуске внутри ghci запись в структуру подсказок _glfwLibrary является доступом к памяти нарушение. Структура подсказок - это просто набор целых чисел. Он очень плоский и простой, и поэтому я думаю, что проблема заключается либо в том, как я связываю вещи, либо в том, как ghci загружает код.

Вот фрагменты моего make-файла, который я использую для создания dylib и .a:

GCCFLAGS  := $(shell ghc --info | ghc -e "fmap read getContents >>=   \
             putStrLn . unwords . read . Data.Maybe.fromJust . lookup \
             \"Gcc Linker flags\"")
FRAMEWORK := -framework Cocoa -framework OpenGL
GLFW_FLAG := $(GCCFLAGS) -O2 -fno-common -Iglfw/include -Iglfw/lib    \
             -Iglfw/lib/cocoa $(CFLAGS)

all: $(BUILD_DIR)/static/libglfw.a $(BUILD_DIR)/dynamic/libglfw.dylib

$(BUILD_DIR)/dynamic/libglfw.dylib: $(OBJS)
  $(CC) -dynamiclib -Wl,-single_module -compatibility_version 1       \
        -current_version 1                                            \
        $(GLFW_FLAG) -o $@ $(OBJS) $(GLFW_SRC) $(FRAMEWORK)

$(BUILD_DIR)/static/libglfw.a: $(OBJS)
  ar -rcs $@ $(OBJS)

Большинство флагов взяты прямо из файла Makefile GLFW, поэтому я думаю, что они должны быть правильными для этой библиотеки.

Первая строка выглядит немного странно, но это решение, которое я использовал для этого проблема .

Сведения о платформе:

22
задан Community 23 May 2017 в 12:07
поделиться