Ответ 1
Во-первых, все перечисленные вами переменные: CC, CFLAGS, CXX, CXXFLAGS, LDFLAGS, LD_LIBRARY_PATH, происходят из семейства ОС Unix. Эти переменные не имеют ничего общего с GCC, поэтому вы не видите их в руководствах.
Единственная значимая переменная (которая также не имеет прямого соединения с GCC) среди них - LD_LIBRARY_PATH. Вероятно, вы найдете эту переменную, которая будет определена из коробки на любой современной Unix-подобной ОС. Ниже приведена справочная руководство LD.SO(8) из руководства по программированию Linux, в котором упоминается LD_LIBRARY_PATH и его назначение. Вот еще один экстракт:
Переменная среды
LD_LIBRARY_PATHсодержит список каталогов, разделенных двоеточиями, которые ищутся динамическим компоновщиком при поиске общей библиотеки для загрузки.Поиск каталогов осуществляется в том порядке, в котором они указаны.
Если не указано, компоновщик использует значение по умолчанию, которое равно
/lib:/usr/lib:/usr/local/lib.
Как вы можете видеть, LD_LIBRARY_PATH - это не что иное, как переменная среды, специфичная для ОС, для правильной загрузки разделяемых библиотек. В этой ситуации Windows имеет аналогичную переменную среды: PATH. Windows будет сканировать каталоги, перечисленные в нем, при поиске библиотеки динамических ссылок (DLL, аналог SO на Linux).
Что касается остальных переменных (CC, CFLAGS, CXX, CXXFLAGS, LDFLAGS), вы часто их видите из-за исторических причин. Начиная с эпохи Unix, программные проекты были построены с использованием Make (прокрутите вниз и посмотрите примеры типичных makefile s) - один из новаторских инструментов сборки. Эти переменные были настолько широко использованы в makefile s, что в конечном итоге они стали своего рода соглашением (см. Неявные правила, например). Вот почему вы даже можете видеть, что они определены из коробки, например, Linux, и, скорее всего, указывая на GCC (поскольку это считается родной инструментальной цепочкой для Linux).
В заключение, дело в следующем: не царапайте голову над CC, CFLAGS, CXX, CXXFLAGS, LDFLAGS и друзьями, так как они просто взрыв из прошлого. ;)
BONUS
Использование простого старого Make непосредственно для создания сложного программного обеспечения сегодня быстро становится утомительным и подверженным ошибкам. В результате многие сложные генераторы системы сборки, такие как GNU Automake или CMake. Короче говоря, их цель - предоставить (возможно) более читаемый, простой в обслуживании и высокоуровневый синтаксис для определения произвольно сложной системы сборки для произвольного программного проекта, который будет построен. Как правило, перед фактическим построением проекта необходимо создать собственную систему сборки (которая также может быть представлена простым старым makefile s, например, по причинам мобильности, но не обязательно) из этого определения высокого уровня, используя соответствующий набор инструментов. Наконец, нужно построить проект с помощью инструмента (ов), соответствующего сгенерированной (нативной) системе сборки (например, Make в случае простого старого makefile s, но необязательно).
Поскольку вы задаете эти вопросы, я подозреваю, что вы собираетесь погрузиться в разработку собственного ПО с помощью C или С++. Если это так, я настоятельно рекомендую вам выбрать современную систему сборки (CMake будет моей личной рекомендацией), в первую очередь, поиграть с ней и хорошо изучить ее.