res2001

Если это нужно для дистрибуции программы, то делаете свой репозиторий куда кладете предварительно собранные пакеты для поддерживаемых платформ. Репозиторий добавляете в настройки пакетного менеджера ОС и устанавливаете штатными средствами уже из репозитория.

И какое различие между char* и char[]?

char* str1 = "Hello world!";
char str2[] = "Hello world!";
Разница между str1 и str2 в том, что str1 - это lvalue, а str2 - нет.
Т.е. с str1 вы можете, например сделать str1 = str1 + 1; а с str2 нет.

С точки зрения памяти:
В случае str1 в памяти хранится 2 сущности: 1) сама строка "Hello world!" 2) указатель, которому присваивается адрес строки. Поэтому вы можете присвоить другое значение указателю.
В случае str2 указателя в памяти нет, есть только строка. Адрес строки знает компилятор и использует его когда нужно. Но присвоить новое значение этому адресу уже не возможно.
Можно считать, что char str[]; это то же что и char * const str;

Вы подключили x64 библиотеку, а собираете x32 проект, естественно компилятору это не нравится.
Подключите x32 версию библиотеки, или собирайте проект как x64.
На самом деле можно делать обе версии и в каждой задать использование правильной версии библиотеки.

Собрать программу можно и без наличия dll, главное чтоб был lib файл от этой dll и файлы заголовки для статического связывания.
В случае динамического связывания (с помощью LoadLibrary() и GetProcAddress()) не нужен и lib файл.
Какое именно связывание используется у вас - вам виднее.
DLL понадобится на этапе исполнения программы. В случае статического связывания без DLL программа не загрузится с соответствующей ошибкой от ОС. В случае динамического связывания LoadLibrary() вернет ошибку, если dll не доступна.

Обратите внимание на то как объявлена функция:
int sum (int n, int matrix[n][n])
И на то как вы ее вызываете:
sum_of = sum(matrix[][]);
Надеюсь дальше разберетесь сами.

cos(x) * n

Похоже ваши гигабайты успевают скидываться в своп во время паузы, отсюда и тормоза пока ОС достанет их оттуда.
Кэшем на прямую вы никак управлять не можете, можете только косвенно структурировав соответствующим образом код и данные. Увеличить объем кэша вы то же не можете, разве что поставить проц с бОльшим кэшем.
Пока попробуйте добавить памяти в комп, так что бы ваш массив целиком туда влазил (да еще и запас был под другие задачи и ОС).

Кстати, вы не привели объем ОЗУ вашего компа.

Использовать библиотеки для больших/длинных чисел.

Можно. Пишите в Микрософт.

Это проявления буферизированного вывода. Т.е. по факту printf до ввода уже выполнился, но на экране еще не отобразился.
Между printf и scanf вставьте fflush(stdin).

Алгоритм циклического сдвига массива "на месте" описан в "Жемчужинах программирования" Джона Бентли 2-е издание, Addison-Wesley, Питер, 2002, Глава 2, раздел 2.3.
Вот пример реализации. Там же видел реализацию того же алгоритма поприличней (в плане оформления кода), но сходу найти не могу.

Алгоритм сдвига не "на месте" (с выделением памяти под массив результата) простой, реализуется двумя операциями копирования памяти.

Дать компилятору эту библиотеку, иначе не соберется проект.

У вас дочерние процессы висят на system("pause"); и не завершаются самостоятельно.
Просто удалите эту команду в дочках, оставьте только в главном процессе и не надо будет ничего мутить с CTRL_BREAK.

1.Если по тупому, то запускайте софтину, она будет ругаться на отсутствие библиотеки, эту библиотеку ищите в недрах mingw копируете в каталог с исполняемым файлом. Повторяете процедуру до тех пор пока софтина не перестанет ругаться на отсутствие библиотек.

2.Чуть по технологичнее: берете dependency walker открываете им ваш исполняемый файл, смотрите от каких библиотек он зависит (в глубину то же нужно смотреть, а не только первый уровень) ищите и копируете библиотеки аналогично п.1.

3.По умному: прописываете путь mingw/bin в переменной окружения PATH и наслаждаетесь. При этом ничего копировать не придется.
Но если вы задумаете распространять ваш софт другим людям, это не избавит вас от необходимости устранять зависимости, т.е. вы все равно должны будете либо собрать все библиотеки в одном каталоге с исполняемым файлом, либо обязать пользователя устанавливать mingw и прописывать его путь в переменную PATH.

Не зависимо в какой ОС вы работает и какой IDE пользуетесь схема одна и та же:
1. Для того что бы в своих исходниках вы могли использовать вызовы сторонней библиотеки вы должны включить заголовочные файлы библиотеки с помощью директивы #include.
2.Чтоб компилятор смог откомпилировать ваш код вы должны задать ему место расположение заголовочных файлов сторонней библиотеки с помощью опции -I компилятора. В линуксе, если библиотека установлена штатным пакетным менеджером, возможно это не потребуется, т.к. заголовочные файлы будут доступны по стандартным путям поиска заголовочных файлов.
3.Чтоб линковщик смог собрать исполняемый файл вы должны указать ему путь и имя двоичных файлов библиотеки с помощью опции -L и -l. Опять же в линуксе, возможно, путь (-L) указывать не потребуется (см.п.2), только имя библиотеки (-l).
4.Если библиотека установлена не в стандартные каталоги, то загрузчик исполняемых файлов может ее не найти. Чтоб это исправить возможно потребуется запустить утилиту ldconfig или даже добавить каталог библиотеки в конфигурационный файл ldconfig. Как вариант добавить в переменную окружения LD_LIBRARY_PATH путь к библиотечным бинарным файлам перед запуском программы.
В винде ldconfig нет - библиотечные файлы должны быть либо в каталоге где лежит исполняемый файл программы, либо в одном из путей, заданных в переменной окружения PATH.

Когда вы запускаете сборку в IDE, то обычно опции компилятора из пп.1-3 вы должны указывать в свойствах проекта.

Задать дополнительный каталог для поиска библиотеки можно с помощью опции компилятора:
-L <новый путь к библиотекам>