Как я могу просто использовать чистый Mingw G CC после установки MSYS (2)?

Question

Итак, я читал в Интернете, но я все еще очень растерялся. Я понимаю, что в мире Linux -on- Windows есть разные инструменты: Msys, Msys2, Cygwin, Mingw и Mingw-64.

Вот что я знаю, и, пожалуйста, поправьте меня если я не прав:

1. Mingw стремится быть просто портом программ G CC для Windows. Он создает собственные Windows двоичные файлы и все.

2. Mingw-64 - это более свежая и лучше поддерживаемая версия Mingw, которая также поддерживает Windows 64 бит.

3. Cygwin, включая Mingw (?) Для поддержки G CC на Windows, обеспечивает уровень совместимости POSIX через DLL, с которой все программы связаны по умолчанию.

4. MSYS - это ветвь Cygwin, но она отбрасывает некоторые усилия по совместимости с POSIX. Вместо этого он в основном направлен на создание собственной программы Windows. Но они все равно будут зависеть от наличия библиотеки MSYS.

5. MSYS2 - это более свежая и активная версия менее активного MSYS.

Это все правда? Если это так, вот что я хочу проверить:

По сути, я думаю, что все, что мне нужно для моей разработки, это Mingw, чтобы использовать G CC для создания собственных Windows приложений. Мне не нужен слой POSIX, и я не хочу, чтобы моя программа зависела от каких-либо библиотек DLL, кроме тех, которые в любом случае присутствуют в Windows системах. Насколько я понимаю, это то, что предлагает Mingw.

Однако каким-то образом мне удалось установить MSYS (или MSYS2? Я больше не уверен) в моей системе. Учебник, которому я следовал ранее, предложил сделать это.

Поскольку кажется, что MSYS (2) включает в себя Mingw под C:\msys64\mingw64, я просто использую двоичные файлы Mingw непосредственно из CMD Windows, не проходя через MSYS 2) оболочка программы. Например, я просто добавил C:\msys64\mingw64\bin в PATH и запускаю gcc из CMD Windows напрямую для компиляции моего проекта.

1. Это правильный способ использовать Mingw? Или я должен столкнуться с проблемами?

2. Создает ли этот подход чистые Windows собственные двоичные файлы, которые никогда не должны зависеть ни от какой DLL-библиотеки, связанной с MSYS (2)?

3. Правда ли, что функциональность и зависимости, связанные с MSYS (2), вступают в действие только в том случае, если я запускаю программы Mingw (например, G CC) через программу оболочки msys2.exe ? И поэтому, если я хочу избежать каких-либо вещей, связанных с MSYS (2) или Cygwin, и просто использовать чистый Mingw G CC, будет ли правильным подход просто запустить G CC непосредственно в каталоге Mingw, как описано ранее?

Обновление: Сейчас я проверил с помощью Dependency Walker, и при запуске C:\msys64\mingw64\bin\gcc из оболочки MSYS2 все еще создается .exe без особых зависимостей (что хорошо) , Так что же это за msys-2.0.dll, о котором говорят документы MSYS2? И как использование MSYS2 для компиляции C отличается от использования Mingw?

Answer 1

Вы в основном правы в том, что это за проекты. MSYS2 предоставляет среду для программ POSIX, таких как Bash, GNU Make и других утилит, но также предоставляет менеджер пакетов с именем pacman, который можно использовать для установки множества других вещей. Фактически, вы можете использовать pacman для установки цепочки инструментов mingw-w64.

MSYS2 на самом деле предоставляет две цепочки инструментов mingw-w64: вы получаете выбор из 3268-битной цепочки инструментов i686, которая делает нативные Windows двоичные файлы который может работать на любом Windows компьютере или на x86_64 (64-разрядном) наборе инструментов, который создает собственные Windows двоичные файлы, которые работают только на 64-разрядном Windows. Вы можете установить их оба одновременно.

Вы говорите: «Мне не нужен слой POSIX», но может оказаться полезным иметь возможность писать Bash сценарии или использовать предоставленные программы POSIX. MSYS2, как GNU Make при сборке вашего собственного Windows программного обеспечения. Это особенно полезно, если вы когда-нибудь захотите собрать свое программное обеспечение на Linux или macOS: можно написать простой скрипт Makefile или shell, который работает на этих платформах, а также на MSYS2.

1. Да, это допустимо использовать двоичные файлы из C:\msys64\mingw64\bin напрямую, если хотите.
2. Да, цепочка инструментов mingw-w64 создает собственные Windows двоичные файлы независимо от того, из какой оболочки вы запускаете их.
3. Нет. Запускаете ли вы MSYS2 через msys2.exe, mingw32.exe или mingw64.exe, вы получаете оболочку Bash с различными утилитами Linux, такими как ls, grep, make и tar. Оболочка и эти утилиты используют эмуляцию POSIX, предоставляемую msys-2.0.dll. Основное различие между этими пусковыми установками MSYS2 заключается в том, что добавляется к вашей переменной PATH, поэтому вы можете запустить echo $PATH и env в каждой из этих сред и сравнить результаты.

Answer 2

Я бы настоятельно рекомендовал использовать MSYS2 вместо MSYS и mingw.org. Притворись, что последние два даже не существуют. Будучи в активной разработке, новые проекты лучше во всех отношениях.

Диспетчер пакетов MSYS2 может предоставлять наборы инструментов для следующих целевых систем:

• Автономный Win32 (i686)
• Автономная Win64 (x86_64)
• MSYS2 i686
• MSYS2 x86_64

Первые два случая могут быть вызваны из любой понравившейся вам оболочки. Вам может потребоваться настроить пути, если вы не используете сценарий запуска, предоставляемый MSYS2. Они производят собственные Windows исполняемые файлы. При использовании по умолчанию переключателей на G CC будут некоторые зависимости, такие как libgcc_s*.dll. Выполнение сборки stati c с -static приведет к созданию исполняемого файла без каких-либо зависимостей, кроме Windows DLL.

В последних двух случаях двоичный файл будет зависеть от DLL MSYS2 и других вещей, но это обеспечивает поддержку ряда функциональных возможностей POSIX.

[~ MSYS]$ ls /usr/include
_ansi.h            cursesp.h      glob.h         net           strings.h
_newlib_version.h  cursesw.h      gnumake.h      netdb.h       symcat.h
_syslist.h         cursslk.h      grp.h          netinet       sys
a.out.h            cygwin         icmp.h         newlib.h      sysexits.h
acl                devctl.h       ieeefp.h       nl_types.h    syslog.h
aio.h              diagnostics.h  ifaddrs.h      panel.h       tar.h
alloca.h           dirent.h       inttypes.h     paths.h       term.h
alpm.h             dis-asm.h      io.h           plugin-api.h  term_entry.h
alpm_list.h        dlfcn.h        langinfo.h     poll.h        termcap.h
ansidecl.h         elf.h          lastlog.h      process.h     termio.h
ar.h               endian.h       libfdt.h       pthread.h     termios.h
argz.h             envlock.h      libfdt_env.h   pty.h         tgmath.h
arpa               envz.h         libgen.h       pwd.h         threads.h
asm                err.h          limits.h       reent.h       tic.h
assert.h           errno.h        locale.h       regdef.h      time.h
attr               error.h        machine        regex.h       tzfile.h
bfd.h              eti.h          magic.h        resolv.h      ucontext.h
bfd_stdint.h       etip.h         malloc.h       sched.h       unctrl.h
bfdlink.h          fastmath.h     mapi.h         search.h      unistd.h
bits               fcntl.h        math.h         semaphore.h   utime.h
byteswap.h         fdt.h          memory.h       setjmp.h      utmp.h
complex.h          features.h     menu.h         signal.h      utmpx.h
cpio.h             fenv.h         mntent.h       spawn.h       w32api
ctf.h              FlexLexer.h    monetary.h     ssp           wait.h
ctf-api.h          fnmatch.h      mqueue.h       stdatomic.h   wchar.h
ctype.h            form.h         nc_tparm.h     stdint.h      wctype.h
curses.h           fts.h          ncurses        stdio.h       winpty
cursesapp.h        ftw.h          ncurses.h      stdio_ext.h   wordexp.h
cursesf.h          gawkapi.h      ncurses_dll.h  stdlib.h      xlocale.h
cursesm.h          getopt.h       ncursesw       string.h
[~ MSYS]$
[~ MSYS]$
[~ MSYS]$ ls /usr/include/sys
_default_fcntl.h  acl.h          fcntl.h     mman.h    quota.h     signal.h      stdio.h      termio.h    ttychars.h  utsname.h
_intsup.h         cdefs.h        features.h  mount.h   random.h    signalfd.h    strace.h     termios.h   types.h     vfs.h
_pthreadtypes.h   config.h       file.h      msg.h     reent.h     smallprint.h  string.h     time.h      ucontext.h  wait.h
_sigset.h         custom_file.h  iconvnls.h  mtio.h    resource.h  socket.h      sysinfo.h    timeb.h     uio.h       xattr.h
_stdint.h         cygwin.h       ioctl.h     param.h   sched.h     soundcard.h   syslimits.h  timerfd.h   un.h
_timespec.h       dir.h          ipc.h       poll.h    select.h    stat.h        syslog.h     times.h     unistd.h
_timeval.h        dirent.h       kd.h        procfs.h  sem.h       statfs.h      sysmacros.h  timespec.h  utime.h
_types.h          errno.h        lock.h      queue.h   shm.h       statvfs.h     sysproto.h   tree.h      utmp.h

Cygwin - конкурирующий продукт, также обеспечивающий функции POSIX и зависящий от библиотеки Cygwin DLL. Цель MSYS2 - это форк Cygwin.