LNK1210 в Visual Studio 2008

Question

Я получаю следующую ошибку при связывании проекта Chromium:

Linking...
LINK.EXE.SUPALINK_ORIG : ..\build\Debug\chrome.dll not found or not built by the last incremental link; performing full link
   Creating library ..\build\Debug\lib\chrome_dll.lib and object ..\build\Debug\lib\chrome_dll.exp
LINK.EXE.SUPALINK_ORIG : fatal error LNK1210: exceeded internal ILK size limit; link with /INCREMENTAL:NO

Есть похожий вопрос для VS2005. Как-то это странно, так как компоновщик уже делает полную ссылку. При настройке /INCREMENTAL:NO он успешно связан, но добавочное связывание отключено.

Есть ли способ увеличить предел размера ILK, чтобы включить инкрементное связывание?

Answer 1

Согласно источнику Microsoft, существуют жесткие ограничения на размер ILK, но он в некоторой степени зависит от версии VS и среды ОС:

• VS2005 имеет ограничение файла ILK 256 МБ
• VS2008 имеет ограничение на размер файла ILK 256 МБ на стандартной ОС Win32, или
  • ограничение 384 МБ при работе на ОС Win32 с /3GB использованная опция, или
  • ограничение в 768 МБ, если вы работаете в ОС Win64

Источник: эта запись инцидента MS Connect, в которой также упоминаются некоторые недостатки использования /3GBчто вы можете принять во внимание.

Поскольку вы работаете в операционной системе Win64 (согласно вашему комментарию), я думаю, что вы, вероятно, получаете наибольший лимит размера файла ILK. /3GB Эта опция применима только к 32-битным операционным системам - при работе под WoW64 32-битные приложения с поддержкой больших адресов получают 4 ГБ адресного пространства - нет необходимости /3GB вариант.

Но подождите - у меня есть идея (возможно, заумная идея). Я не знаю, сработает ли это на самом деле для решения проблемы инкрементного соединения, с которой вы сталкиваетесь, и даже если это сработает, это все же может не стоить того, потому что это, вероятно, много проблем, особенно в плане обслуживания:

Возможно, вы захотите узнать, может ли использование встроенного компоновщика x64 обойти эту проблему - если вы установите опцию компилятора x64, VS установит несколько наборов инструментов компилятора / компоновки для различных комбинаций целевой платформы x86/x64 и хост-платформы x86/x64. Что касается компилятора, для генерации кода x86 существует только компилятор Win32, но для генерации кода x64 есть как компилятор Win64, так и Win32 'кросс-компилятор' toolchain. Однако для компоновщика представляется, что любой из компоновщиков (Win32 или Win64 - "перекрестная" версия компоновщика является просто копией версии Win32) может генерировать цель x86 или x64.

Меня не слишком удивит, если нативный компоновщик Win64 может обрабатывать файлы ILK большего размера, чем нативный компоновщик Win32, поэтому, возможно, стоит проверить, использует ли ваш текущий процесс сборки инструменты Win32 (или "кросс") Win32.

Если вы ориентируетесь на x64, убедитесь, что ваш процесс сборки использует встроенные инструменты x64 в VC\bin\amd64 вместо перекрестных инструментов в VC\bin\x86_amd64, Если для сборки вы используете обычный проект VS IDE C++, вам, возможно, придется переключиться на проект makefile, чтобы использовать собственные инструменты x64.

Если вы ориентируетесь на x86, все может быть немного сложнее - на этапе компиляции сборки необходимо использовать инструменты x86 в VC\bin, но тогда для этапа компоновки вам нужно использовать собственный компоновщик x64 в VC\bin\amd64, Укажите /machine:x86 и убедитесь, что у вас установлен путь поиска lib для поиска библиотек x86 вместо библиотек x64. Это работает - по крайней мере, для небольшой тестовой программы. Но, как я уже сказал, я не знаю, поможет ли это на самом деле решить проблему с инкрементной связью, с которой вы столкнулись, или это будет стоить проблем, даже если это произойдет.