Компоновщик MinGW C ++ не может найти файл из-за усечения имени файла и / или не может найти определения

Question

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

Я пытаюсь создать модульные тесты для нашего проекта, которые будут работать в среде Windows (исключая аппаратно-зависимые функции). Мы также создаем те же модульные тесты, чтобы они запускались на нашей цели (Renesas PK-S5D9), поэтому с использованием другого компилятора, и это успешно. Обратите внимание, что мы используем gtest, и он включен как источник, а не как библиотека. В этой сборке не задействованы библиотеки, только исходный код.

Scenar ios:

1. Работа велась над веткой. Разработка была обновлена, поэтому разработчик объединился в новую HEAD. После этого несвязанный тест начал не связываться; назовем тест ATest. cpp и источник продукта A.cpp / h. Компоновщик жалуется, что функции, объявленные в Ah и используемые ATest. cpp, не определены, однако сборка A. cpp прошла успешно, .o существует в ожидаемом месте, а .o указан в Команда связывания.
2. Я взял начало ветки и исключил файлы, принесенные слиянием из разработки (один класс и один тест), и получил другую ошибку. В конце предыдущей строки находится файл "./product/adapters/ActionableProvider.o", который выглядит усеченным, когда g ++ пытается получить к нему доступ:

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

Вещи, которые добавляют странностей:

Коммиты, в которых разработчики наблюдали сбой, НЕ терпят неудачу при запуске с использованием того же набора инструментов, но в нашей сборке сервер (немного отличается Windows 10 сборка, а также не имеет тяжелого антивируса, потому что он сегментирован во внутренней сети).

Приветствуются любые мысли, которые приводят к чему-то большему, чтобы попытаться собрать эту тайну вместе !

Answer 1

Был момент прозрения. Это проблема ограничения длины команды. Очевидно, Windows может обрабатывать только 8192 символа в команде, отсюда и сокращенное имя файла. Вот одна ссылка: https://mcuoneclipse.com/2015/03/29/solving-the-8192-character-command-line-limit-on-windows/

Нашим окончательным решением было изменить нашу команду компоновщика в e2studio (eclipse) с:

${COMMAND} ${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}

на:

@$(file >link_cmd.in,${FLAGS} ${OUTPUT_FLAG} ${OUTPUT_PREFIX}${OUTPUT} ${INPUTS}) ${COMMAND} @"link_cmd.in"

Шаги в путешествии включали составление списка возможных решений (если бы мы только могли выяснить, как их реализовать :)):

• сократить пути
• создать библиотеку
• выяснить, как заставить eclipse построить test_desktop в другой оболочке, у которой нет этой проблемы
• выяснить, как получить eclipse, чтобы команда компоновщика использовала файл ( см. параметр @file в https://linux.die.net/man/1/g++)

Мы предпочли последнее решение, но мы реализовали его только потому, что именно так наши модульные тесты с целевыми спецификациями c обошли проблему. Некоторый поиск привел нас к https://www.eclipse.org/forums/index.php/t/369721/, где последнее сообщение было кем-то, указавшим, что они опубликовали обходной путь к ошибке https://bugs.eclipse.org/bugs/show_bug.cgi?id=72965. Большое спасибо Корнелиу Зузу !! После некоторой первоначальной оценки мы поняли, что нам просто нужно выгрузить команду в файл, используя аналогичный механизм (кажется, у Корнелиу Зузу была более сложная проблема, включающая обратные косые черты?). Отсюда и вышеприведенное решение.