7.11. Параметры, относящиеся к конкретной фазе

7.11.1. Замена программы для одной или нескольких фаз

Можно указать, что для одной из фаз системы компиляции будет использоваться другая программа вместо той, что ghc подключил в нее. Например, можно попробовать другой ассемблер. Следующие параметры позволяют изменить внешнюю программу, используемую для данной фазы компиляции:

-pgmL ⟨cmd⟩

Использовать ⟨cmd⟩ как обработчик предварительной обработки.

-pgmP ⟨cmd⟩

Использовать ⟨cmd⟩ как препроцессор C (только с -cpp).

-pgmc ⟨cmd⟩

Использовать ⟨cmd⟩ как компилятор C.

-pgmlo ⟨cmd⟩

Использовать ⟨cmd⟩ как оптимизатор LLVM.

-pgmlc ⟨cmd⟩

Использовать ⟨cmd⟩ как компилятор LLVM.

-pgms ⟨cmd⟩

Использовать ⟨cmd⟩ как разделитель.

-pgma ⟨cmd⟩

Использовать ⟨cmd⟩ как ассемблер.

-pgml ⟨cmd⟩

Использовать ⟨cmd⟩ как компоновщик.

-pgmlm ⟨cmd⟩

Использовать ⟨cmd⟩ как компоновщик при слиянии объектных файлов (например, при генерации объединённых объектов для загрузки в GHCi).

-pgmdll ⟨cmd⟩

Использовать ⟨cmd⟩ как генератор DLL.

-pgmF ⟨cmd⟩

Использовать ⟨cmd⟩ как препроцессор (только с -F).

-pgmwindres ⟨cmd⟩

Использовать ⟨cmd⟩ для встраивания манифестов в Windows. Обычно это программа windres, поставляемая с установкой GHC. См. -fno-embed-manifest в Параметры, влияющие на компоновку.

-pgmlibtool ⟨cmd⟩

Использовать ⟨cmd⟩ как команду libtool (только при использовании -staticlib).

-pgmi ⟨cmd⟩

Использовать ⟨cmd⟩ как внешнюю команду интерпретатора (см. Запуск интерпретатора в отдельном процессе). По умолчанию: ghc-iserv-prof если включен -prof, ghc-iserv-dyn если включен -dynamic или ghc-iserv в противном случае.

7.11.2. Принудительное применение параметров к конкретной фазе

Параметры можно принудительно передать конкретной фазе компиляции, используя следующие флаги:

-optL ⟨option⟩

Передать ⟨option⟩ обработчику предварительной обработки.

-optP ⟨option⟩

Передать ⟨option⟩ в CPP (имеет смысл только если -cpp также включен).

-optF ⟨option⟩

Передать ⟨option⟩ пользовательскому препроцессору (см. Параметры, влияющие на препроцессор Haskell).

-optc ⟨option⟩

Передать ⟨option⟩ компилятору C.

-optcxx ⟨option⟩

Передать ⟨option⟩ компилятору C++.

-optlo ⟨option⟩

Передать ⟨option⟩ оптимизатору LLVM.

-optlc ⟨option⟩

Передать ⟨option⟩ компилятору LLVM.

-opta ⟨option⟩

Передать ⟨option⟩ ассемблеру.

-optl ⟨option⟩

Передать ⟨option⟩ компоновщику.

-optlm ⟨option⟩

Передать ⟨option⟩ компоновщику при слиянии объектных файлов. В случае стандартного компоновщика в стиле ld этот параметр, как правило, должен включать флаг -r.

-optdll ⟨option⟩

Передать ⟨option⟩ генератору DLL.

-optwindres ⟨option⟩

Передать ⟨option⟩ в windres при встраивании манифестов в Windows. См. -fno-embed-manifest в Параметры, влияющие на компоновку.

-opti ⟨option⟩

Передать ⟨option⟩ дочернему процессу интерпретатора (см. Запуск интерпретатора в отдельном процессе). Частое использование — передача параметров RTS, например, -opti+RTS -opti-A64m, или включение подробности -opti-v, чтобы увидеть сообщения, обменивающиеся между GHC и интерпретатором.

Например, чтобы принудительно передать параметр -Ewurble ассемблеру, сообщите драйверу -opta-Ewurble (дефис перед E обязателен).

GHC — это сама программа Haskell, поэтому если нужно передать параметры непосредственно в систему выполнения GHC, можно заключить их в +RTS ... -RTS (см. Запуск скомпилированной программы).

7.11.3. Параметры, влияющие на препроцессор C

CPP

Since

6.8.1

Языковая расширение CPP включает препроцессор C. Это можно преобразовать в командную строку, добавив перед ней -X; Например:

$ ghc -XCPP foo.hs

Языковое расширение CPP также можно включить с помощью директивы LANGUAGE; Например:

{-# LANGUAGE CPP #-}

-cpp

Препроцессор C cpp выполняется над вашим кодом Haskell, если задан параметр -cpp или расширение -XCPP. Если вы не строите большую систему с существенными дозами условной компиляции, вам это не нужно.

-D⟨symbol⟩[=⟨value⟩]

Определяет макрос ⟨symbol⟩ стандартным образом. Если значение не указано, оно принимается как 1. Например, -DUSE_MYLIB эквивалентно -DUSE_MYLIB=1.

Примечание

-D⟨symbol⟩[=⟨value⟩] не влияет на -D макросы, передаваемые компилятору C при компиляции неописанного сборки! В этом случае используйте обходной путь -optc-Dfoo… (см. Принудительное применение параметров к конкретной фазе).

-U⟨symbol⟩

Отменяет определение макроса ⟨symbol⟩ стандартным образом.

-I⟨dir⟩

Указывает директорию, в которой искать #include файлы, как и в C.

Драйвер GHC определяет несколько макросов при обработке исходного кода Haskell (.hs или .lhs файлы).

7.11.3.1. Стандартные макросы CPP

Ниже приведены символы, определенные GHC. Для проверки, какие символы определены вашей локальной установкой GHC, полезен следующий трюк:

$ ghc -E -optP-dM -cpp foo.hs
$ cat foo.hspp

(вам нужен файл foo.hs, но он фактически не используется).

__GLASGOW_HASKELL__

Для версии x.y.z GHC, значение __GLASGOW_HASKELL__ — целое число ⟨xyy⟩ (если ⟨y⟩ — однозначное число, добавляется ведущий ноль; например, для версии 6.2 GHC, __GLASGOW_HASKELL__==602). Дополнительная информация в Политика нумерации версий GHC.

Надеюсь, __GLASGOW_HASKELL__ будет не определено во всех остальных реализациях, поддерживающих предобработку в стиле C.

Примечание

Сопоставимые символы для других систем: __HUGS__ для Hugs, __NHC__ для nhc98 и __HBC__ для hbc.

Примечание. Этот макрос устанавливается при предобработке как исходного кода Haskell, так и исходного кода C, включая код C, сгенерированный из модуля Haskell (т.е. .hs, .lhs, .c и .hc файлы).

__GLASGOW_HASKELL_PATCHLEVEL1__; __GLASGOW_HASKELL_PATCHLEVEL2__

Эти макросы доступны начиная с GHC 7.10.1.

Для трёхчастных номеров версий GHC x.y.z, значение __GLASGOW_HASKELL_PATCHLEVEL1__ — целое число ⟨z⟩.

Для четырёхчастных номеров версий GHC x.y.z.z', значение __GLASGOW_HASKELL_PATCHLEVEL1__ — целое число ⟨z⟩, а значение __GLASGOW_HASKELL_PATCHLEVEL2__ устанавливается в целое число ⟨z’⟩.

Эти макросы предоставляются для достижения большей точности, чем у __GLASGOW_HASKELL__. Как правило, это не требуется, так как большинство API, как ожидается, остаются стабильными между выпусками с исправлениями, но иногда для исправления ошибок необходимы внутренние изменения API. Условные компиляции на уровне исправления могут быть полезны для обхода ошибок в более старых версиях.

Подсказка

Эти макросы устанавливаются при предобработке как исходного кода Haskell, так и исходного кода C, включая код C, сгенерированный из модуля Haskell (т.е. .hs, .lhs, .c и .hc файлы).

MIN_VERSION_GLASGOW_HASKELL(x,y,z,z')

Этот макрос доступен начиная с GHC 7.10.1.

Этот макрос предоставляется для удобства написания условных компиляций, проверяющих, используемая версия GHC — версия x.y.z.z' или более поздняя.

Если требуется совместимость с компиляторами Haskell (включая GHC до версии 7.10.1), которые не определяют MIN_VERSION_GLASGOW_HASKELL, необходимо убедиться в наличии макроса MIN_VERSION_GLASGOW_HASKELL перед его вызовом, например:

#if defined(MIN_VERSION_GLASGOW_HASKELL)
#if MIN_VERSION_GLASGOW_HASKELL(7,10,2,0)
/* code that applies only to GHC 7.10.2 or later */
#endif
#endif

Подсказка

Этот макрос устанавливается при предобработке как исходного кода Haskell, так и исходного кода C, включая код C, сгенерированный из модуля Haskell (т.е. .hs, .lhs, .c и .hc файлы).

__GLASGOW_HASKELL_TH__

Устанавливается в 1, если компилятор поддерживает Template Haskell, и в 0, если нет. Последний случай — для компилятора стадии 1 во время загрузки или на архитектурах, где интерпретатор недоступен.

__GLASGOW_HASKELL_LLVM__

Определяется только при указании -fllvm. Когда GHC использует версию x.y.z LLVM, значение __GLASGOW_HASKELL_LLVM__ — целое число ⟨xyy⟩ (если ⟨y⟩ — однозначное число, добавляется ведущий ноль; например, при использовании версии 3.7 LLVM, __GLASGOW_HASKELL_LLVM__==307).

__PARALLEL_HASKELL__

Определяется только при использовании -parallel! Этот символ определён при предобработке Haskell (входной файл) и предобработке C (выходной файл GHC).

os_HOST_OS=1

Этот define позволяет условную компиляцию на основе операционной системы, где ⟨os⟩ — имя текущей операционной системы (например, linux, mingw32 для Windows, solaris, и т.д.).

arch_HOST_ARCH=1

Этот define позволяет условную компиляцию на основе архитектуры хоста, где ⟨arch⟩ — имя текущей архитектуры (например, i386, x86_64, powerpc, sparc, и т.д.).

VERSION_pkgname

Этот макрос доступен начиная с GHC 8.0. Определяется для каждого экспонируемого пакета. Этот макрос расширяется до строки, записывающей версию pkgname, которая экспонируется для импорта модуля. Его поведение идентично макросам VERSION_pkgname определённых Cabal.

MIN_VERSION_pkgname(x,y,z)

Этот макрос доступен начиная с GHC 8.0. Определяется для каждого экспонируемого пакета. Этот макрос предоставляется для удобства написания условных компиляций, проверяющих, что версия пакета — x.y.z или более поздняя. Его поведение идентично макросам MIN_VERSION_pkgname определённых Cabal.

7.11.3.2. CPP и разрывы строк

Небольшое предупреждение: -cpp не дружелюбен к «разрывам строк». Другими словами, такие строки:

strmod = "\
\ p \
\ "

не работают с -cpp; /usr/bin/cpp опускает пары обратная косая черта-новая строка.

Однако, похоже, что если вы добавите пробел в конце строки, то cpp (по крайней мере, GNU cpp и, возможно, другие cpps) оставляет пары обратная косая черта-пробел в покое, и разрыв строки работает как ожидается.

7.11.4. Параметры, влияющие на предобработчик Haskell

-F

Пользовательский предобработчик запускается над вашим файлом исходного кода Haskell только если указан параметр -F.

Запуск пользовательского предобработчика во время компиляции в некоторых случаях уместен и полезен. Параметр -F позволяет запустить предобработчик как часть общей системы компиляции GHC, что имеет преимущество перед отдельным запуском предобработчика Haskell — он работает в режиме интерпретации и вы можете продолжать пользоваться преимуществами проверки перекомпиляции GHC.

Предобработчик запускается непосредственно перед тем, как собственно компилятор Haskell обработает входные данные Haskell, но после удаления размеченных данных и (возможно) обработки входных данных Haskell с помощью предобработчика C.

Используйте -pgmF ⟨cmd⟩ для выбора программы, которая будет использоваться в качестве предобработчика. При вызове предобработчик ⟨cmd⟩ получает как минимум три аргумента командной строки: первый аргумент — имя исходного файла, второй — имя файла, содержащего входные данные, а третий — имя файла, в который ⟨cmd⟩ должен записать свой вывод.

Дополнительные аргументы предобработчика можно передать с помощью параметра -optF ⟨option⟩. Они передаются ⟨cmd⟩ в командной строке после трёх стандартных аргументов ввода и вывода.

Пример предобработчика — преобразование файлов исходного кода в ожидаемый GHC формат кодировки, например, создайте скрипт convert.sh содержащий строки:

#!/bin/sh
( echo "{-# LINE 1 \"$2\" #-}" ; iconv -f l1 -t utf-8 $2 ) > $3

и передайте -F -pgmF convert.sh в GHC. Параметр -f l1 сообщает iconv преобразовать ваш файл Latin-1, предоставленный в аргументе $2, в UTF-8 кодировку. Результат перенаправляется в аргумент $3. Параметр echo "{-# LINE 1 \"$2\" #-}" просто гарантирует, что ваши позиции ошибок будут отображены как в исходном файле.

7.11.5. Параметры, влияющие на генерацию кода

-fasm

Используйте собственный генератор кода GHC генератор кода для нативных систем вместо компиляции через LLVM. -fasm — значение по умолчанию.

-fllvm

Компилировать через LLVM вместо использования генератора кода для нативных систем. Это, как правило, займёт немного больше времени, чем генератор кода для нативных систем. Полученный код, как правило, имеет ту же скорость или быстрее, чем два других генератора кода. Для компиляции через LLVM исполняемые файлы opt и llc LLVM должны находиться в PATH.

Примечание

Обратите внимание, что эта версия GHC ожидает LLVM версии 9 серии.

-fno-code

Пропустить генерацию кода (и все последующие этапы) полностью. Это полезно, если вас интересует только проверка типов кода.

-fwrite-interface

Всегда создавать файлы интерфейса. GHC обычно автоматически создаёт файлы интерфейса, но этот флаг полезен с -fno-code, который обычно подавляет генерацию файлов интерфейса. Это полезно, если вы хотите проверять типы несколько раз с GHC без компиляции зависимостей.

-fobject-code

Генерировать объектный код. Это значение по умолчанию вне GHCi и может использоваться в GHCi для генерации объектного кода вместо байткода.

-fbyte-code

Генерировать байткод вместо объектного кода. Это значение по умолчанию в GHCi. Байткод в настоящее время можно использовать только в интерактивном интерпретаторе, а не сохранять на диск. Этот параметр полезен только для обратного действия -fobject-code.

-fPIC

Генерировать позиционно-независимый код (код, который можно поместить в общие библиотеки). В настоящее время это работает в Linux x86 и x86-64. В Windows позиционно-независимый код никогда не используется, поэтому флаг является бесполезным на этой платформе.

-fexternal-dynamic-refs

При генерации кода предполагать, что сущности, импортированные из другого модуля, могут быть динамически связаны. Этот флаг автоматически включён параметром -dynamic.

-fPIE

Генерирует код таким образом, чтобы он мог быть связан в позиционно-независимый исполняемый файл. В настоящее время это работает в Linux x86 и x86-64. В Windows позиционно-независимый код никогда не используется, поэтому флаг является бесполезным на этой платформе. Для связывания конечного исполняемого файла используйте -pie.

-dynamic

Создаёт код для динамической компоновки. Это может значительно уменьшить размер кода, но может замедлить межмодульные вызовы нелинейных функций. Может возникнуть ряд проблем при объединении -shared с этим флагом, связанных с компоновкой RTS в Linux. См. #10352.

Обратите внимание, что использование этого параметра при компоновке приводит к тому, что GHC связывается с динамическими библиотеками.

-dynamic-too

Генерирует как динамические, так и статические объектные файлы в одной загрузке GHC. Этот параметр функционально эквивалентен запуску GHC дважды, второй раз добавляя -dynamic -osuf dyn_o -hisuf dyn_hi.

Несмотря на то, что он эквивалентен запуску GHC дважды, использование -dynamic-too более эффективно, потому что предыдущие этапы компилятора до генерации кода выполняются только один раз.

При использовании -dynamic-too, параметры -dyno, -dynosuf, и -dynhisuf соответствуют -o, -osuf, и -hisuf соответственно, но применяются к динамической компиляции.

7.11.6. Параметры, влияющие на компоновку

GHC должен связать ваш код с различными библиотеками, возможно, включая: предоставленные пользователем, предоставленные GHC и системные (-lm библиотека математических функций, например).

-l ⟨lib⟩

Подключает библиотеку ⟨lib⟩. В системах Unix это будет файл, называемый liblib.a или liblib.so , расположенный где-то в пути к каталогам библиотек.

Из-за печального состояния большинства линковщиков UNIX порядок таких параметров важен. Если библиотека ⟨foo⟩ использует библиотеку ⟨bar⟩, то, как правило, -l ⟨foo⟩ должна следовать перед -l ⟨bar⟩ в командной строке.

Есть ещё одна проблема, которую следует учитывать при использовании внешних библиотек: если библиотека содержит функцию main(), то это вызовет конфликт связывания с собственной функцией GHC main() (например, libf2c и libl имеют свои собственные main()).

Вы можете использовать внешнюю главную функцию, если инициализируете RTS вручную и передадите -no-hs-main. См. также Использование собственной main().

-c

Пропускает этап компоновки. Этот параметр можно использовать с --make, чтобы избежать автоматической компоновки, которая происходит, если программа содержит модуль Main.

-package ⟨name⟩

Если вы используете Haskell «пакет» (см. Пакеты), не забудьте добавить соответствующий -package параметр при компоновке программы: это вызовет связывание необходимых библиотек с программой. Если забыть -package параметр, вероятно, появятся многостраничные ошибки компоновки.

-framework ⟨name⟩

Только для Darwin/OS X/iOS, подключает фреймворк ⟨name⟩. Этот параметр соответствует параметру -framework для Apple’s Linker. Обратите внимание, что фреймворки и пакеты — это разные вещи; фреймворки не содержат никакого Haskell-кода. Скорее, они являются способом Apple упаковывать динамические библиотеки. Для связывания с Apple’s «Carbon» API, например, используется -framework Carbon.

-staticlib

Связывает все переданные файлы в статическую библиотеку, подходящую для компоновки. Для управления именем используйте параметр -o ⟨file⟩ как обычно. По умолчанию имя равно liba.a.

-L ⟨dir⟩

Где находятся пользовательские библиотеки… Добавьте каталог ⟨dir⟩ в путь к каталогам библиотек.

-framework-path ⟨dir⟩

Только для Darwin/OS X/iOS, добавляет каталог ⟨dir⟩ в путь к каталогам фреймворков. Этот параметр соответствует параметру -F для Apple’s Linker (-F уже имеет другое значение для GHC).

-split-sections

Размещает каждую сгенерированную функцию или элемент данных в отдельную секцию в выходном файле, если целевой объект поддерживает произвольные секции. Имя функции или имя элемента данных определяет имя секции в выходном файле.

При компоновке линковщик может автоматически удалить все неиспользуемые секции и тем самым создать более компактные исполняемые файлы.

-static

Указывает линковщику избегать динамических Haskell-библиотек, если это возможно. Это значение по умолчанию.

-dynamic

Этот флаг указывает GHC связываться с динамическими Haskell-библиотеками. Этот флаг влияет только на выбор зависимых библиотек, а не на форму текущей цели (см. -shared). См. Использование динамических библиотек о том, как их создать.

Обратите внимание, что этот параметр также влияет на генерацию кода (см. выше).

-shared

Вместо создания исполняемого файла, GHC производит динамическую библиотеку с этим флагом линковщика. В зависимости от целевой операционной системы это может быть ELF DSO, DLL Windows или Mac OS dylib. GHC скрывает детали операционной системы под этим единообразным флагом.

Флаги -dynamic и -static управляют тем, связывается ли полученный динамический объект статически или динамически с Haskell-пакетными библиотеками, заданными как параметр -package ⟨pkg⟩. Библиотеки, не относящиеся к Haskell, связываются так, как обычно связывал бы gcc в вашей системе, например, в большинстве систем ELF линковщик использует динамические библиотеки, если они найдены.

Объектные файлы, связанные с динамическими объектами, должны быть скомпилированы с -fPIC, см. Параметры, влияющие на генерацию кода.

При создании динамических объектов для пакетов Haskell, динамический объект должен иметь правильное имя, чтобы GHC распознал динамический объект при связывании с этим пакетом. См. изменение имени динамического объекта.

-dynload

Этот флаг выбирает один из нескольких режимов поиска динамических библиотек во время выполнения. См. Поиск динамических библиотек во время выполнения для описания каждого режима.

-main-is ⟨thing⟩

В Haskell по умолчанию программа должна иметь функцию main в модуле Main. При тестировании часто удобно изменить функцию, которая является «главной», и флаг -main-is позволяет это сделать. Значение ⟨thing⟩ может быть одним из:

• Идентификатор в нижнем регистре foo. GHC предполагает, что основная функция — Main.foo.
• Имя модуля A. GHC предполагает, что основная функция — A.main.
• Квалифицированное имя A.foo. GHC предполагает, что основная функция — A.foo.

Строго говоря, -main-is не является флагом стадии компоновки; он не оказывает никакого влияния на этап компоновки. Флаг должен быть указан при компиляции модуля, содержащего указанную основную функцию (например, модуль A в двух последних пунктах выше). Он не имеет эффекта для других модулей и поэтому может быть безопасно предоставлен для ghc --make. Однако, если все модули в остальном обновлены, вам может потребоваться принудительно перекомпилировать как модуль, где новый «main» находится, так и модуль, где «main» функция использовалась ранее; ghc недостаточно умён, чтобы понять, что нужно перекомпилировать оба. Вы можете принудительно перекомпилировать, удалив объектный файл или используя флаг -fforce-recomp.

-no-hs-main

В случае, если вы хотите включить скомпилированный код ghc в качестве части другой программы (не Haskell), RTS не будет предоставлять своё определение main() во время линковки, вам придётся сделать это самостоятельно. Чтобы сообщить об этом компилятору при линковке, используйте -no-hs-main. Также см. Использование собственной функции main().

Обратите внимание, что поскольку команда, передаваемая линковщику, довольно сложная, вам, вероятно, следует использовать ghc для окончательной линковки вашего приложения «смешанного языка». Однако это не обязательно, просто попробуйте выполнить линковку один раз с -v, чтобы увидеть, какие параметры драйвер передаёт линковщику.

Флаг -no-hs-main также может быть использован, чтобы убедить компилятор выполнить шаг линковки в режиме --make, когда нет модуля Haskell Main (обычно компилятор не пытается выполнить линковку, если нет модуля Main).

Флаги -rtsopts[=⟨none|some|all|ignore|ignoreAll⟩] и -with-rtsopts=⟨opts⟩ не имеют эффекта, когда используются с -no-hs-main, потому что они реализуются путём изменения определения main , генерируемого GHC. См. Использование собственной функции main() для того, как получить эффект -rtsopts[=⟨none|some|all|ignore|ignoreAll⟩] и -with-rtsopts=⟨opts⟩ при использовании собственной функции main.

-debug

Скомпилируйте программу с отладочной версией системного времени выполнения. Отладочная система времени выполнения включает множество утверждений и проверок на корректность, а также предоставляет дополнительные параметры для вывода отладочной информации во время выполнения (запустите программу с +RTS -? , чтобы увидеть список).

-threaded

Скомпилируйте программу с «потоковой» версией системного времени выполнения. Потоковая система времени выполнения так называется потому, что она управляет несколькими потоками ОС, в отличие от стандартной системы времени выполнения, которая является чисто однопотоковой.

Обратите внимание, что вам не нужно -threaded для использования конкурентности; однопотоковая система времени выполнения поддерживает конкурентность между потоками Haskell без проблем.

Потоковая система времени выполнения обеспечивает следующие преимущества:

• Она позволяет использовать опцию RTS -N ⟨x⟩, которая позволяет потокам выполняться параллельно на многопроцессорном или многоядерном компьютере. См. Использование параллелизма SMP.
• Если поток делает вызов внешней функции (и вызов не помечен unsafe), то другие потоки Haskell в программе продолжат выполняться, пока вызов внешней функции не завершится. Кроме того, потоковые функции Haskell могут вызываться из нескольких потоков ОС одновременно. См. Многопоточность и FFI.

-eventlog

Скомпилируйте программу с «событийной» версией системного времени выполнения. Программа, скомпилированная таким образом, может генерировать трассировку событий (например, старт/стоп потока) в двоичный файл program.eventlog, который затем может быть интерпретирован различными инструментами. См. Отслеживание для получения дополнительной информации.

-eventlog может использоваться с -threaded. Она подразумевается -debug.

-rtsopts[=⟨none|some|all|ignore|ignoreAll⟩]

По умолчанию

some

Этот параметр влияет на обработку параметров управления RTS, заданных либо в командной строке, либо через переменную среды GHCRTS. Существует три варианта:

-rtsopts=none

Отключить всю обработку опций RTS. Если +RTS появляется где-либо в командной строке, программа завершит работу с сообщением об ошибке. Если переменная среды GHCRTS установлена, программа выведет предупреждение, GHCRTS будет проигнорировано, и программа выполнится в обычном режиме.

-rtsopts=ignore

Отключает всю обработку опций RTS. В отличие от none это обращается со всеми флагами RTS, появляющимися в командной строке, так же, как с обычными аргументами. (Передаёт их вашей программе в качестве аргументов). GHCRTS параметры будут обработаны нормально.

-rtsopts=ignoreAll

То же, что ignore , но также игнорирует GHCRTS.

-rtsopts=some

[Это значение по умолчанию] Включить только «безопасные» параметры RTS: (В настоящее время только -? и --info.) Любые другие параметры RTS в командной строке или в переменной среды GHCRTS приведут к аварийному завершению программы с сообщением об ошибке.

-rtsopts=all or just -rtsopts

Включить всю обработку параметров RTS, как в командной строке, так и через переменную среды GHCRTS.

В GHC 6.12.3 и более ранних версиях по умолчанию обрабатывались все параметры RTS. Однако, поскольку параметры RTS могут использоваться для записи данных логов в произвольные файлы в контексте безопасности запущенной программы, существует потенциальная проблема безопасности. По этой причине GHC 7.0.1 и более поздние версии по умолчанию используют -rtsopts=some.

Обратите внимание, что -rtsopts не имеет эффекта, когда используется с -no-hs-main; см. Использование собственной функции main() для получения подробностей.

-rtsopts не влияет на параметры RTS, переданные через -with-rtsopts; они используются независимо от -rtsopts.

-with-rtsopts=⟨opts⟩

Этот параметр позволяет установить параметры RTS по умолчанию во время линковки. Например, -with-rtsopts="-H128m" устанавливает размер кучи по умолчанию в 128 МБ. Это всегда будет размер кучи по умолчанию для этой программы, если пользователь не переопределит его. (В зависимости от настроек параметра -rtsopts пользователь может не иметь возможности изменять параметры RTS во время выполнения, в этом случае -with-rtsopts будет единственным способом их настройки.)

Используйте флаг времени выполнения --info для исполняемого файла, чтобы увидеть параметры, установленные с -with-rtsopts.

Обратите внимание, что -with-rtsopts не имеет эффекта, когда используется с -no-hs-main; см. Использование собственной функции main() для получения подробностей.

-no-rtsopts-suggestions

Этот параметр отключает предложения RTS о линковке с -rtsopts[=⟨none|some|all|ignore|ignoreAll⟩], когда они недоступны. Эти предложения были бы бесполезны, если пользователи установили программы Haskell через свои менеджеры пакетов. При включенном этом параметре эти предложения не будут появляться. Рекомендуется для распространения библиотек для сборки с помощью либо -rtsopts , либо -no-rtsopts-suggestions.

-fno-gen-manifest

В Windows GHC обычно генерирует файл манифеста при линковке двоичного файла. Файл манифеста размещается в файле prog.exe.manifest` , где ⟨prog.exe⟩ — имя исполняемого файла. Файл манифеста в настоящее время служит только для одной цели: он отключает «обнаружение установщика» в Windows Vista, которое пытается повысить привилегии для исполняемых файлов с определёнными именами (например, содержащими «установить», «установка» или «патч»). Без файла манифеста для отключения обнаружения установщика попытка запуска исполняемого файла, который Windows считает установщиком, вернёт код ошибки доступа к ресурсу вызывающей программе. В зависимости от вызывающей программы, результатом может быть диалоговое окно, спрашивающее пользователя об увеличении привилегий, или просто ошибка «Доступ запрещён».

Обнаружение установщика также может быть отключено глобально для системы с помощью панели управления безопасностью, но GHC по умолчанию генерирует исполняемые файлы, не зависящие от того, отключил ли пользователь обнаружение установщиков.

Флаг -fno-gen-manifest отключает генерацию файла манифеста. Одна из причин сделать это — если у вас есть свой собственный файл манифеста.

В будущем GHC может использовать файл манифеста для других целей, например, для указания местоположения зависимых DLL.

-fno-gen-manifest также подразумевает -fno-embed-manifest, см. ниже.

-fno-embed-manifest

Файл манифеста, который GHC генерирует при компоновке бинарника на Windows, по умолчанию также встраивается в сам исполняемый файл. Это означает, что бинарник можно распространять, не предоставляя файл манифеста. Встраивание выполняется с помощью запуска windres; чтобы увидеть, что именно GHC делает для встраивания манифеста, используйте флаг -v. Установка GHC поставляется со своей копией windres по этой причине.

См. также -pgmwindres ⟨cmd⟩ (Замена программы для одной или нескольких фаз) и -optwindres ⟨option⟩ (Принудительное применение опций к конкретной фазе).

-fno-shared-implib

DLL на Windows обычно связываются путем ссылки на соответствующую .lib или .dll.a — так называемую библиотеку импорта. GHC обычно генерирует такой файл для каждой DLL, которую вы создаёте, компилируя в режиме -shared. Однако иногда вам не хочется платить за место на диске, создавая эту библиотеку импорта, которая может быть существенной — она может потребовать столько же места, сколько и сам код, так как DLL Haskell обычно экспортируют много символов.

Пока вы довольны возможностью связываться с DLL только с помощью GetProcAddress и друзей, вы можете использовать флаг -fno-shared-implib для отключения создания библиотеки импорта полностью.

-dylib-install-name ⟨path⟩

В Darwin/OS X динамические библиотеки в момент построения маркируются «именем установки», которое является конечным путём установки файла библиотеки. Любые библиотеки или исполняемые файлы, которые впоследствии ссылаются на неё, получат этот путь как место расположения для поиска во время выполнения. По умолчанию, ghc устанавливает имя установки в место, где библиотека построена. Эта опция позволяет переопределить её указанным путём к файлу. (Она передаёт -install_name линковщику Apple.) Игнорируется на других платформах.

-rdynamic

Это указывает линковщику добавить все символы, а не только используемые, в таблицу динамических символов. В настоящее время только Linux и Windows/MinGW32. Это эквивалентно использованию -optl -rdynamic в Linux и -optl -export-all-symbols в Windows.

-fwhole-archive-hs-libs

При компоновке исполняемого бинарника этот флаг вставляет -Wl,--whole-archive перед любыми -l флагами для библиотек Haskell, а -Wl,--no-whole-archive после них (в OS X флаг -Wl,-all_load, нет эквивалента для -Wl,--no-whole-archive). Этот флаг также отключает использование -Wl,--gc-sections (-Wl,-dead_strip в OS X).

Это для специализированных приложений, которые могут потребовать символы, определённые в этих библиотеках Haskell во время выполнения, даже если они не ссылаются на них никаким другим кодом, связанным в исполняемый файл. Если вы используете -fwhole-archive-hs-libs, вы, вероятно, также захотите -rdynamic.

-pie

Since

8.2.2

Это указывает линковщику создать исполняемый файл независимый от позиции. Этот флаг действителен только при создании исполняемых файлов, и весь объектный код, который связывается, должен быть создан с помощью -fPIE.

Исполняемые файлы, независимые от позиции, требуются некоторыми платформами, так как они позволяют реализовать рандомизацию расположения адресного пространства (ASLR) — распространённую меру безопасности. Они также могут быть полезными, так как их можно динамически загрузить и использовать как общие библиотеки другими исполняемыми файлами.

Исполняемые файлы, независимые от позиции, должны быть динамически связанными (например, построены с помощью -dynamic и только загружаться в другие динамически связанные исполняемые файлы, чтобы убедиться, что только один libHSrts присутствует, если загружен в адресное пространство другого процесса Haskell.

Кроме того, возможно, вам нужно использовать флаг -rdynamic, чтобы убедиться, что символы не удаляются из ваших PIE объектов.

-keep-cafs

Since

8.8.1

Отключает обычное поведение RTS по сбору мусора CAFs (постоянные прикладные формы, другими словами, выражения верхнего уровня). Эта опция полезна для специализированных приложений, которые выполняют динамическую привязку во время выполнения, где код, динамически привязанный в будущем, может потребовать значения CAF, который в противном случае был бы собран мусором.