2016-05-26 7 views
10

MSYS2 по умолчанию shell (bash) можно запустить из трех пусковых установок, которые также устанавливают переменную окружения MSYSTEM. Конкретно:MSYS vs. MinGW: переменные внутренней среды

  1. msys2_shell.bat устанавливает его MSYS
  2. mingw64_shell.bat устанавливает его MINGW64 и
  3. mingw32_shell.bat устанавливает его MINGW32.

Помимо строки оболочек, видимые различия:

  • Существует эквивалентная переменная оболочки $MSYSTEM экспортируется;
  • uname выход основан на $MSYSTEM;
  • Когда $MSYSTEM является MINGW*, /mingw*/bin является первым путем в $PATH.

Предполагая, что мы имеем /usr/bin/gcc, /mingw64/bin/gcc, /mingw32/bin/gcc, разумное следствие заданного значения $MSYSTEM является то, что мы будем использовать другой компилятор, генерирующий другой двоичный (POSIX или родную 32/64).

  • Каковы другие существенные различия, определяемые значением $MSYSTEM?
  • Существуют ли какие-либо двоичные файлы, которые используют конкретную переменную?
  • Является ли pacman уязвимым подсистемой?

ответ

9

Из статьи post выдается Ray Donnelly, вкладчиком MinGW-w64. Он просвещает по этому вопросу и является важной преамбулой к моему вопросу.

Существует 3 системы, MSYS2 и 32-разрядные и 64-разрядные собственные системы Windows. Каждая система имеет свой собственный репозиторий программных пакетов в дистрибутиве MSYS2. [...] это важное различие между ними. MSYS2 реализует пространство имен файловой системы POSIX-y FHS, и это очень важно для многих вещей.
[...] 32-разрядные и 64-разрядные системы MinGW-w64 являются родным программным обеспечением для Windows, которые внедрены в/mingw32 и/mingw64 соответственно. Это не то, что мы заменили каждый Linux API на себя; большинство из вышеперечисленных проектов делают это для нас, поскольку они уже предоставляют порты Windows, но да, иногда мы должны это делать. Мы также добавляем специальные исправления для многих программ, чтобы вы могли свободно устанавливать корень (например, C: \ msys64) везде, где хотите. Программное обеспечение MSYS2 не нуждается в этих исправлениях (поскольку локальное расположение Windows является скрытой деталью установки), но программное обеспечение MinGW-w64 часто делает это.
[F] с точки зрения конечного пользователя, есть только 2 системы, MSYS2 и XX-бит родной Windows, и да, некоторые пакеты существуют для обеих этих систем. В частности, MSYS2 существует для запуска инструментов разработки, необходимых для создания собственного программного обеспечения для Windows, поэтому, если для системы сборки необходима версия Python или Perl MSYS2 для правильной работы (поскольку она предполагает FHS или что-то еще), нам необходимо предоставить эти пакеты. Мы никогда не добавляем пакеты MSYS2, не убедившись, что они нужны. Если вы не знаете, что вам нужна версия MSYS2, тогда установите вместо этого соответствующую Native Windows.
Примером того, когда вам понадобится MSYS2 Python, является попытка использования инструментов репо Google. Это связано с тем, что репо использует модуль fcntl Python, и этот модуль существует только в системах POSIX-y. IMHO Python делает плохую работу по абстрагированию ОС здесь, и это фундаментальная вещь, которую должен выполнять язык сценариев, а fcntl (и pyWin32) не должен существовать, но я не являюсь боссом Python.
К счастью, у Pacman есть управление зависимостями и будет устанавливать материал, необходимый для любых пакетов, на которые вы действительно заинтересованы.
GNU Autotools никогда не будет работать хорошо, кроме как через систему FHS, совместимую с оболочкой POSIX, и это, естественно, приводит к другим инструментам, требующим существовать в одной и той же файловой системы имен, таких, как макияж, Perl, m4, бизон, сгибать и т.д. и т.п.

Учитывая Ray Доннелли пост, что составляет систему в первую очередь переменная PATH, потому что, в зависимости от приоритеты каталога Инструменты репо Google будут построены с пакетами MSYS2 или MinGW. Фактически сценарий shell, который переключается между MSYS2 и MinGW-оболочками, экспортирует переменную окружения MSYSTEM с аргументом mingw32|mingw64|msys и источниками /etc/profile. Последнее, в свою очередь, устанавливает PATH на основе значения MSYSTEM. По большому счету для MSYS2 PATH является /usr/local/bin:/usr/bin:/bin, тогда как для MinGW 64 это /mingw64/bin:/usr/local/bin:/usr/bin:/bin, поэтому компиляторы gcc соответственно выполнит версию MSYS2 или MinGW. Есть другие незначительные env. переменные тоже, например, MANPATH, чтобы прочитать правильные руководства, после того, как вызываются правильные двоичные файлы, или PKG_CONFIG_PATH для чтения правильных файлов lib при создании.

Что касается, pacman, это не совсем так, что это не затрагивает, как из комментария @David Grayson. MSYS2 wiki неопределенно подтверждает, что:

Использование msys2 оболочки для запуска Pacman, makepkg, makepkg-MinGW и для создания POSIX-зависимого программного обеспечения, которое вы не собираетесь распространять. Используйте mingw shell для создания собственного программного обеспечения и других задач.

Рэй Доннелли проясняет вещи снова в другом post:

Вообще говоря, вы можете использовать любую оболочку для Pacman, но вы можете столкнуться с некоторыми вопросами, используя MinGW оболочек, где в зависимости от того, что пакеты, которые вы» вы установили в/mingw32 или/mingw64, сценарии пост-установки пакетов (которые являются произвольными сценариями bash) могут закончиться запуском неожиданного варианта программы mingw-w64. Конкретным примером этого будет «sed». Таким образом, запуск pacman из msys2_shell.bat исключает класс потенциальных проблем (хотя мы попытаемся исправить все, что сообщается в любом случае).

Подводя итог:

Каковы другие существенные различия, определяемые $MSYSTEM значения?
Непосредственные существенные отличия связаны со значениями переменных пути, идентифицируемыми @David Grayson.

Существуют ли какие-либо двоичные файлы, которые используют конкретную переменную?
Кажется безопасным сказать, что нет специального бинарного чтения непосредственно $MSYSTEM, но большое количество программного обеспечения использует/читает переменные пути выше, исходя из $MSYSTEM.

Является pacman уязвимым подсистемой?
Да.

2

Вы должны посмотреть в /etc/profile (который исходит от this file on GitHub). Там вы можете увидеть, что MSYSTEM влияет:

  • PATH
  • PKG_CONFIG_PATH
  • ACLOCAL_PATH
  • MANPATH
  • MINGW_MOUNT_POINT

Кроме того, есть pull request, который добавляет /etc/profile/msystem, который будетскрипт, который устанавливает дополнительные переменные на основе MSYSTEM.

+0

Это означает, что во время процесса make 'pkg-config' и' automake' могут искать файлы '.pc' и' .m4' в '/ mingwXX', а не'/usr'. Это также должно повлиять на процесс сборки pacman. Так будет ли выход 'pacman' изменяться в соответствии с' $ MSYSTEM'? – antonio

+0

'pacman' не создает пакеты, он просто устанавливает их. Вы можете запустить 'pacman' просто отлично, независимо от того, какой параметр $ MSYSTEM установлен, и' $ MSYSTEM' не влияет на него, насколько я знаю. –

5

Намерения позади трех вариантов было дать вам возможность двух различных сред разработки:

  1. MinGW: предназначенную для разработки собственных приложений Windows.Это делится на:

    • Mingw32 для производства 32-битных исполняемых файлов, и конечно
    • Mingw64 для производства 64-х битных исполняемых файлов

    Думай об этом, как, где вы будете делать ваше развитие конечных пользователей , Программное обеспечение, которое обычно не запускается внутри самой среды MSYS2.

  2. MSYS: предназначен для создания приложений, которые будут работать в среде posix-y с именами файловой системы FHS. Подумайте об этом как о том, где вы будете делать разработку для инструментов, которые фактически работают внутри Msys2. Или вы можете думать об этом, как если бы вы были Cygwin.

Вы можете получить более подробную информацию по этому вопросу в this thread на SourceForge форуме MSYS2.

+0

Я уже знал об этом, что конкретно не отвечает на мой вопрос. Во всяком случае, ссылка Рей Доннелли. – antonio

Смежные вопросы