Почему GCC-Windows зависит от cygwin?
Обнаружение функции
Это фрагмент, чтобы определить, реализована ли реализация libstdc++ с препроцессором C:
#include
#if __cplusplus >= 201103L && \
(!defined(__GLIBCXX__) || (__cplusplus >= 201402L) || \
(defined(_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT) || \
defined(_GLIBCXX_REGEX_STATE_LIMIT) || \
(defined(_GLIBCXX_RELEASE) && \
_GLIBCXX_RELEASE > 4)))
#define HAVE_WORKING_REGEX 1
#else
#define HAVE_WORKING_REGEX 0
#endif
Макросы
-
_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMITзадано вbits/regex.tccв4.9.x -
_GLIBCXX_REGEX_STATE_LIMIT, определено вbits/regex_automatron.hв5+ -
_GLIBCXX_RELEASEбыл добавлен к7+в результате этого ответа и является главной версией GCC
Тестирование
Вы можете протестировать его с помощью GCC следующим образом:
cat << EOF | g++ --std=c++11 -x c++ - && ./a.out
#include
#if __cplusplus >= 201103L && \
(!defined(__GLIBCXX__) || (__cplusplus >= 201402L) || \
(defined(_GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT) || \
defined(_GLIBCXX_REGEX_STATE_LIMIT) || \
(defined(_GLIBCXX_RELEASE) && \
_GLIBCXX_RELEASE > 4)))
#define HAVE_WORKING_REGEX 1
#else
#define HAVE_WORKING_REGEX 0
#endif
#include
int main() {
const std::regex regex(".*");
const std::string string = "This should match!";
const auto result = std::regex_search(string, regex);
#if HAVE_WORKING_REGEX
std::cerr << " works, look: " << std::boolalpha << result << std::endl;
#else
std::cerr << " doesn't work, look: " << std::boolalpha << result << std::endl;
#endif
return result ? EXIT_SUCCESS : EXIT_FAILURE;
}
EOF
Результаты
Вот некоторые результаты для разных компиляторов:
$ gcc --version
gcc (GCC) 4.8.5 20150623 (Red Hat 4.8.5-11)
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./a.out
doesn't work, look: false
$ gcc --version
gcc (GCC) 6.2.1 20160830
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./a.out
works, look: true
$ gcc --version
gcc (Debian 4.9.2-10) 4.9.2
Copyright (C) 2014 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./a.out
works, look: true
$ gcc --version
gcc (Ubuntu 6.2.0-5ubuntu12) 6.2.0 20161005
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./a.out
works, look: true
$ gcc --version
gcc (Ubuntu 5.4.0-6ubuntu1~16.04.4) 5.4.0 20160609
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ ./a.out
works, look: true
$ gcc --version
gcc (GCC) 6.2.1 20160830
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ clang --version
clang version 3.9.0 (tags/RELEASE_390/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
$ ./a.out # compiled with 'clang -lstdc++'
works, look: true
Здесь будут Dragons
Это абсолютно неподдерживается и полагается об обнаружении частных макросов, которые разработчики GCC поместили в заголовки bits/regex*. Они могут меняться и уходить в в любое время . Надеюсь, они не будут удалены в текущих версиях 4.9.x, 5.x, 6.x, но они могут исчезнуть в версиях 7.x.
Если разработчики GCC добавили #define _GLIBCXX_HAVE_WORKING_REGEX 1 (или что-то, подсказка hint nudge nudge) в релизе 7.x, который сохранился, этот фрагмент можно было обновить, включив его, а последующие выпуски GCC будут работать со сниппетом выше.
Насколько я знаю , все остальные компиляторы работают __cplusplus >= 201103L, но YMMV.
Очевидно, что это полностью нарушится, если кто-то определит макросы _GLIBCXX_REGEX_DFS_QUANTIFIERS_LIMIT или _GLIBCXX_REGEX_STATE_LIMIT вне заголовков stdc++-v3.
10 ответов
На самом деле предпосылка вопроса является неправильной: MinGW GCC делает НЕ , требуют Cygwin.
Вы будете видеть, что Вам не нужен Cygwin вообще. Это работает исходно в Windows (32-разрядный, по крайней мере). И набор инструментальных средств и произведенные двоичные файлы независимы от Cygwin.
компиляторы MinGW, доступные в Cygwin, отличаются: они основаны на платформе Cygwin, для генерации кода, который не зависит от времени выполнения Cygwin. Сами компиляторы зависят от Cygwin в этом случае. Но поэтому Вы установили их от Cygwin.
Я пытаюсь заставить свои программы в соответствии с Windows вести себя как хороший гражданин Windows, и в соответствии с Linux как хороший гражданин Linux.
Windows не предлагает стандартную библиотеку POSIX, таким образом, cygwin обеспечивает один (cygwin1.dll). gcc пакеты, который идет с cygwin, используют его.
mingw, с другой стороны, не обязательно обеспечивает уровень POSIX. mingw установка, которую я использую, например, даже не имеет pthread библиотеки.
Должен я нуждаться в нем, я должен был бы установить его. Mingw-gcc производит собственный код Win32 (и на самом деле полагается на MSVCRT.DLL).
РЕДАКТИРОВАНИЕ: чтение Вашего редактирования, я больше не уверен, спрашиваете ли Вы, почему самому gcc нужны mingw/cygwin библиотеки или если программы, скомпилированные с gcc на Win, требуют тех библиотек
версия Cygwin GCC требует Cygwin быть установленной для программ, которые это компилирует.
версия MinGW ничего не требует после компиляции кроме рабочей копии Windows.
Вы не можете действительно смешать среду Cygwin и компиляторы MinGW вместе, потому что Cygwin изменяет пути предварительно скомпилированных библиотек.
, Если бы Вы нуждаетесь в оболочке стиля удара, но не хотите использовать Cygwin, я рекомендовал бы MSYS.
Cygwin в отличие от MinGW
, скопированного от , приложения MinGW Wiki
Cygwin принципом не рассматриваются "Собственное заявление Win32", потому что это полагается на CygwinВ® POSIX Emulation DLL илиcygwin1.dllдля функций Posix и не использует функции win32 непосредственно. MinGW, с другой стороны, обеспечивает функции, предоставленные API Win32. При портировании приложений под MinGW функции, не собственные к Win32 такой какfork(),mmap()илиioctl(), должны будут быть повторно реализованы в эквиваленты Win32 для приложения для функционирования правильно.
Большая часть того программного обеспечения, которое компилируется для различных платформ, компилируется... в MinGW. Единственная разница для gcc - то, что это - компилятор сам , что означает, что требуются все заголовки, которые обычно компилируются в с программой, и обычно какой не должен запускать получающуюся программу.
Почему? Потому что при создании GCC 32-битная версия Windows даже не выходила ...
Если быть более точным - она была разработана для ОС UNIX / Posix. Позже он был портирован на Windows.
Windows не является POSIX-совместимой системой. Это даже не обеспечивает очень простой функциональности. Попробуйте найти readdir или stat в компиляторе Windows? И это настолько простой базовый функционал, что вам нужно написать компилятор!
Просто для ясности, скомпилированным программам GCC обычно требуется только один mingw32.dll, чтобы добавить недостающую функциональность, чтобы иметь возможность работать.
Итак ... Вы Спросите, почему GCC требует некоторого слоя POSIX? Потому что ОС Windows не является операционной системой POSIX.
POSIX (интерфейс переносимой операционной системы) "является развивающимся, растущий документ, который создается IEEE и стандартизирован ANSI и ISO. Целью POSIX является переносимость исходного кода приложения »[1].
На практике цель определяется как возможность написать одну исходную реализацию и запустить ее в разных (совместимых с POSIX) системах только с перекомпиляцией.
GCC - это компилятор, способный выполнить это обещание, и поэтому ему нужен уровень кода, который доводит машину до стандартов POSIX.
Это суть ответа на ваш вопрос.
Чтобы понять, что я имею в виду, я предлагаю вам следующее упражнение:
- Напишите программу без специфичных для ОС #ifdef, которая принимает в качестве входных данных от пользователя путь к каталогу и записывает в stdout список его содержимого (один уровень).
Я думаю, вы обнаружите, что очень сложно написать код, который использует только собственный WIN32 API, который компилируется в любой системе UNIX или LINUX.
Будет лишь немного легче написать код, использующий POSIX API - поскольку вы можете использовать любой компьютер с LINUX - и скомпилировать его под Windows (DevStudio2005 теперь имеет удивительное количество POSIX-совместимых заголовков ... возможно, вы сможете приблизиться).
Возьмите программу LINUX сверху и скомпилируйте ее под GCC, работающей под Cygwin или MinGW. Готов поспорить, он компилируется и запускается.
Как GCC совершил это волшебство? Заголовки POSIX и лежащие в их основе реализации, предоставляемые Cygwin или MinGW.
Имеет ли смысл использование GCC Cygwin / MinGW под Windows сейчас?
- POSIX.4: Программирование для реального мира, Билл О. Галлмейстер, O'Reilly & Associates, Inc., стр. 2
Я не разработчик C ++, но у меня есть всегда интересовался компиляторами, и я заинтересован в том, чтобы возиться с некоторые вещи GCC (особенно LLVM)
Обратите внимание, что LLVM и GCC не связаны. LLVM во многом является результатом исследования, проведенного Крисом Латтнером ( http://llvm.org/developers.cgi ) о современной оптимизации. Его работы доступны на http://llvm.org . В настоящее время это в большой степени спонсируется Apple. Интерфейс GCC C / C ++ / Obj-C используется для llvm-gcc, который испускает машинный код LLVM (и после тонны оптимизаций в llvm выходит финальный исполняемый файл); llvm-gcc - это своего рода хак для соединения готового C / C ++ / Obj-C-интерфейса с LLVM.
В любом случае, обратите внимание, что команда LLVM также создает собственный полный C / C ++ / Obj-C компилятор, называемый clang. Его реализация на C почти завершена, поддержка C ++ становится все лучше и лучше, хотя не знаю об Obj-C.
Так что, если кто-то говорит «компилятор llvm», он на самом деле означает либо llvm-gcc, либо clang.
Потому что люди, которые Beging GCC ненавидит окна со страстью (прочитал Столллер когда-нибудь). Поэтому при портировании GCC к Windows они делают все возможное, чтобы сделать вид, что это просто еще один Unix.
Это, вероятно, не хочет проводить время на удалении зависительных зависимостей POSIX из кода.
Порт MinGW-w64 для gcc создает собственный код для 32- и 64-битная Windows без дополнительных зависимостей. См., Например, http://mstenberg.com/blog/2010/06/13/gcc-for-windows/ для получения краткого руководства по началу работы.