Является ли gcc переносимым между всеми 64-битными машинами Linux
Я делаю работу удаленно, подключившись к терминалу Linux с помощью ssh. Компьютер, к которому я подключаюсь, является 64-битным компьютером x86 Linux. Мой компьютер также является 64-битным Ubuntu с процессором x86.
Мне нужно сдать программные назначения, которые компилируются с gcc и выполняются на удаленной машине, иначе они не будут оценены. Профессор отметил, что gcc может по-разному компилировать программы на разных машинах и что C не полностью переносим, как Java.
У меня вопрос: могу ли я написать свои программы в gedit, отладить их с помощью gdb на моем компьютере и загрузить их с помощью scp (если я выполняю работу, подключившись к удаленному терминалу Unix, я могу использовать только nano / pico / vim)? Или мой компьютер будет компилироваться иначе, чем удаленный компьютер? Опять же, они оба являются 64-битными машинами Linux x86.
3 ответа
Проблема, на которую, вероятно, ссылался ваш профессор, заключается в том, что размеры различных типов в Си зависят от платформы. Например, вы сможете хранить гораздо большие числа в long переменных, если они скомпилированы для системы x86-64 Linux, по сравнению с тем, когда они скомпилированы для i386 Linux. Для правильных программ это не проблема, но если у вас есть программа, например, взаимозаменяемо использует int и long, он может нормально работать на i386, но не работать при работе на 64-битных системах.
В отличие от этого, Java использует один и тот же размер для базовых типов на всех платформах, поэтому избегает проблемы переносимости этого класса.
Если ваша система разработки и удаленная система - x86-64 Linux, то вы не должны сталкиваться с какими-либо из этих различий. У вас не должно быть проблем с написанием и отладкой ваших программ локально.
Имея это в виду, если вы оцениваете, основываясь на том, как ваша программа ведет себя в удаленной системе, стоит протестировать готовые программы в удаленной системе.
Если вы отправите двоичный файл (я был бы удивлен, если бы вам пришлось это сделать), он будет работать (поскольку вы упомянули, что архитектура обеих машин одинакова), скорее всего, если нет разницы в установленных библиотеках и вы действительно используете некоторые из них.
Но при условии, что вам просто нужно отправить исходный код, ваш код будет скомпилирован на удаленном сервере. Это означает, что, пока вы не используете какую-то определенную библиотеку, присутствующую в вашей системе, ваши программы будут компилироваться и запускаться на удаленном сервере. Но если вы в конечном итоге используете такую библиотеку, вы можете указать флаги связывания (в вашем Makefile или указать это явно как часть вашего представления).
Как указал @ rhn-grg, если обе машины имеют одинаковую архитектуру процессора, единственное отличие, которое может помешать запуску вашего двоичного файла на другой машине, - это библиотеки, с которыми связан ваш двоичный файл - по умолчанию двоичные файлы связаны так, они загружают библиотеки динамически, что позволяет сохранять бинарные файлы маленькими, а также позволяет более эффективно использовать оперативную память, поскольку библиотека загружается один раз, но может использоваться несколькими процессами.
Однако, в случаях, когда вам необходимо обеспечить «переносимость» двоичного файла, вы можете указать gcc статически связать двоичный файл - т.е. включить все библиотеки, которые он использует, в двоичный файл - это приведет к довольно большому двоичному файлу, но это не будет зависеть от каких-либо внешних библиотек.
У меня никогда не было необходимости делать это, однако теперь, когда вы знаете магические слова (статические ссылки, переносимые двоичные файлы), вы можете найти много предложений в Google, например это :
< blockquote>Обычно, когда вы загружаете tar-архив с исходным кодом, вы делаете стандартную команду "configure; make; make install" для его сборки. Если вам нужен статически связанный двоичный файл, замените простое «make» следующим:
make SHARED=0 CC='gcc -static'
Чтобы узнать, от каких библиотек зависит ваш двоичный файл, вы можете использовать команду ldd: