Команда сборки проходит, но бинарник не запускается на целевой системе или получает неверную зависимость. Цена ошибки — отлаживать код, когда причина находится в разрядности toolchain и DLL.
Исходный рецепт `dmd -m64` остаётся отправной точкой. Для воспроизводимости нужно дополнительно зафиксировать версию DMD, linker, PATH и способ проверки PE-заголовка.
Что сохраняем из исходной заметки
Существуют проблемы совместимости с 32-x битными файлами DMD в Windows x64, так как они скомпилированы с использованием DMC фоновых программ, которые могут производить только OMF двоичные файлы. Поэтому для того, чтобы избежать проблем с подключением к внешним скомпилированным библиотекам, гораздо легче придерживаться использования 64-разрядных двоичных файлов. Это можно осуществить использованием Visual Studio компоновщика для DMD, который будет создавать совместимые COFF двоичный файлы. Еще одна проблема в том, что 32-битные DMD двоичные файлы связаны с устаревшими 32-битными библиотека WinAPI, в которых отсутствуют некоторые очень важные функции, в то время как 64-разрядные двоичные файлы должны быть связаны с 64-битными библиотеками, поставляемыми в SDK Windows. Решим эту проблему.
Для начала нужно установить Microsoft Windows SDK for Windows. Найти различные версии можно по ссылке http://www.microsoft.com/en-us/search/result.aspx?q=sdk%20windows. Скачиваем для своей версии Windows. Устанавливаем.
Директория установки Windows SDK в Windows 7 по умолчанию — C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\. Создадим системную переменную VCINSTALLDIR с данным адресом директории.
Далее нам будет предложено выбрать устанавливаемые средства разработки, нам важны только 64-x разрядные библиотеки и компилятор Visual Studio, выберем данные пункты.
Далее создадим ещё одну системную переменную DEV_DIR_WINSDK, в которой будет храниться путь к Windows SDK. В моё случае это C:\Program Files\Microsoft SDKs\Windows\v7.1\.
Теперь необходимо отредактировать файл конфигурации компилятора DMD, он находится по пути dmd2\windows\bin\sc.ini. Файл разбит на разделы, которые отмечены квадратными скобками, на потребуется изменить данные в разделе Environment64:
- Изменим значение параметра LINKCMD на %VCINSTALLDIR%\bin\amd64\link.exe
- Раскомментируем строку WindowsSdkDir= и приравняем к %DEV_DIR_WINSDK%
- Далее необходимо закомментировать (символ «;») строки с параметром LIB, в которых прописаны пути к Wimdows SDK не для вашей платформы.
На этом настройка завершена, попробуем скомпилировать проект (запись блога ), открываем командную строку, пишем:
rdmd -m64 C:\D\projects\test\hello.d
Если всё прошло удачно, будет выведено «Hello, World!». Поздравляю, теперь вы можете компилировать 64-х разрядные приложения на D для Windows.
Основная информация взята с http://wiki.dlang.org/Installing_DMD_on_64-bit_Windows_7_%28COFF-compatible%29
Короткая памятка для современных и старых сборок
Главная мысль остаётся той же: нельзя смешивать 32-битные OMF-библиотеки и 64-битную сборку. В старых установках DMD под Windows это часто упиралось в ручную настройку sc.ini, Windows SDK и Visual Studio linker. В более новых установках официальный установщик DMD обычно делает большую часть этой настройки сам, а для нормальной работы достаточно иметь Visual Studio Build Tools или установленную Visual Studio с C++ tooling.
Для простой 64-битной сборки используем явную архитектуру:
dmd -m64 main.d -of=app.exe
dub build --arch=x86_64Если используется старая 32-битная сборка, смотрим, какой формат объектных файлов нужен проекту. Старый OMF и MS-COFF несовместимы между собой. Для современных библиотек Windows чаще нужен MS-COFF, а для 64-битной сборки это фактически обычный путь.
- Проверьте, что внешние .lib файлы собраны под ту же архитектуру.
- Запускайте сборку из Developer Command Prompt или x64 Native Tools Command Prompt, если компоновщик не находится.
- Если DMD не видит linker, проверьте переменные окружения и секцию Environment64 в sc.ini.
- Если проект собирается через DUB, фиксируйте архитектуру в команде или конфигурации сборки.
Типичная ошибка выглядит так: код компилируется, а линковка падает на внешней библиотеке. В большинстве случаев виноват не D-код, а то, что рядом лежит библиотека другого формата или другой разрядности. Сначала проверяем toolchain и зависимости, и только потом ищем ошибку в исходниках.
Механизм без лишних обещаний
Флаг `-m64` задаёт архитектуру результата, но итог зависит и от установленного компилятора, линкера и библиотек. Наличие DMD в PATH не доказывает, что запускается ожидаемая версия.
64-битный бинарник может не стартовать из-за отсутствующей DLL или несовместимого runtime. Поэтому после сборки проверяем не только размер файла, но и зависимости на чистой машине.
Debug и release могут использовать разные настройки и пути. Их нужно собирать в одинаково описанном окружении и не подменять ручным копированием DLL.
Минимальный воспроизводимый пример
Ниже — маленькая проверка, которую можно запустить или адаптировать в отдельном тестовом окружении. Значения демонстрационные; проектные идентификаторы, пути и версии нужно заменить своими и сохранить рядом с результатом.
@echo off
where dmd
dmd --version
dub --version
dmd -m64 -of=bin\app.exe source\app.d
if errorlevel 1 exit /b 1
dumpbin /headers bin\app.exe | findstr machine
dumpbin /dependents bin\app.exeМатрица диагностики
| Проверка | Ожидаемое значение | Ошибка, которую ловит |
|---|---|---|
| Compiler | Версия DMD зафиксирована | PATH указывает на другой toolchain |
| Target | x64 в PE header | Собран x86-бинарник |
| Runtime | Зависимости найдены | На чистой Windows нет DLL |
| Build mode | debug/release назван явно | Сравниваются разные конфигурации |
Порядок действий
- Очистить PATH от неявных старых версий и вывести `where dmd`.
- Зафиксировать DMD, linker и зависимости проекта.
- Собрать маленький бинарник с `-m64` и проверить код возврата.
- Проверить PE header и список DLL.
- Запустить release на чистой или изолированной Windows-машине.
- Сохранить команду сборки и версии рядом с артефактом.
Ограничения и безопасный следующий шаг
Флаги и поддерживаемые linkers зависят от версии DMD и Windows SDK.
`dumpbin` входит в Visual Studio tools; на другой машине нужен эквивалентный PE-анализатор.
Размер файла не подтверждает разрядность и совместимость.
После проверки должен остаться конкретный артефакт: вывод команды, тест, diff конфигурации или запись результата. Если его нет, формулировку нужно вернуть к симптому и не выдавать гипотезу за исправление.
Что записать в ревью
Короткая запись должна отвечать на четыре вопроса: какой вход использовали, какой результат увидели, какая граница была проверена и какое действие разрешено дальше. Такая форма полезнее длинного вывода «всё работает»: другой инженер сможет повторить проверку и понять, где заканчивается пример.
Если результат зависит от версии Windows, PHP, Bitrix, D или браузера, версию фиксируем рядом с командой. Если проверка не охватывает сеть, production или реальные пользовательские данные, это ограничение пишем прямо. Тогда следующий шаг расширяет evidence, а не расширяет обещание.
Проверяемые источники
- D language: download — показывает поддерживаемые версии компиляторов
- DMD command line — описывает сборку DMD под Windows
- D language: specification — фиксирует правила языка и target-зависимые ограничения