Я пытаюсь собрать «Connector/C» MySQL из исходного кода в cygwin, и есть проблемы.
-некоторый контекст-
Мы могли бы много говорить о том, почему кто-то захочет использовать libmysql в cygwin. В этом случае проще выполнить некоторую разработку для Unix в окне Windows с помощью набора инструментов cygwin.
Судя по моим исследованиям, я могу получить более старую версию (возможно, 5.1) коннектора для сборки в порядке. Но поддержка cygwin прекратилась, когда разработчики MySQL перешли с конфигурации сборки, управляемой ./configure, на cmake.
Версия исходного tar-шара, которую MySQL предлагает для загрузки, — 6.0.2, поэтому я работаю над ней.
-одна (вроде) решенная проблема-
Первой проблемой, с которой я столкнулся, было несовместимое переобъявление dtoa(), найденное в stdlib.h. (Многие другие, кто пытался собрать различные последние версии, также столкнулись с этой проблемой - если Google поможет.) В сети есть различные предложения, чтобы решить эту проблему. Мой выбор: временно заменить stdlib.h на тот, у которого удалено определение dtoa(). Некрасиво, правда. Но это работает.
(Это «исправление» устраняет раннюю ошибку компиляции, и процесс проходит прямо до компоновки, где он терпит неудачу по явно не связанным причинам.)
-нерешенная проблема-
Код libmysql зависит от yaSSL. Похоже, это так, несмотря на то, что я дал cmake параметр -DWITH_OPENSSL=1, который принимается только после добавления пакета openssl-devel в свою среду с помощью cygwin setup-tool/package-manager. yaSSL, похоже, использует «чисто виртуальные» члены класса. Исходя из моих (несколько ограниченных) знаний о внутреннем устройстве C++, это означает, что компилятор неявно предполагает объявление специального символа/функции __cxa_pure_virtual(), и это заставляет компоновщик искать (единственное) определение функции __cxa_pure_virtual().
Код и процесс сборки структурированы так, что каждый из yaSSL исходных файлов реализации компилируется в объектный файл. Многие из этих файлов ссылаются на другой, который определяет (т.е. содержит реализацию) __cxa_pure_virtual(). На этапе связывания каждый объект, содержащий определение, конфликтует друг с другом. (Поскольку символ определяется как extern, а точнее:
extern "C" {
int __cxa_pure_virtual() {
assert("Pure virtual method called." == "Aborted");
return 0;
}
}
Эти определения находятся в общем пространстве имен. Таким образом, компоновщику не было дано правило, по которому он мог бы решить, на какую из ссылок ссылаться.) Результатом является multiple definition error, например:
CMakeFiles/libmysql.dir/__/extlib/yassl/taocrypt/src/algebra.cpp.o:algebra.cpp:(.text+0x40): multiple definition of `___cxa_pure_virtual'
CMakeFiles/libmysql.dir/__/extlib/yassl/taocrypt/src/aes.cpp.o:aes.cpp:(.text+0x0): first defined here
Я пробовал несколько очень упрощенных попыток решить эту проблему.
- Я удалил все определения
__cxa_pure_virtual(), но это просто заменяет ошибки с несколькими определениями на ошибки с неопределенными ссылками. - Я изменил все определения
__cxa_pure_virtual()наinlineв тщетной надежде, что компилятор удалит внешнюю ссылку из встроенной функции. (Я не уверен, когда С++ использует таблицу поиска в качестве уровня косвенности, но кажется, чтоinlineв таких случаях не подходит.) Если я помню конкретный результат этого теста: он создал тот же результат, что и < em>нет определения__cxa_pure_virtual(). - Я начал искать применение чисто виртуальным функциям в исходниках
libmysql, но это казалось кроличьей норой... - Я подумывал изучить процесс сборки, чтобы поместить определение
__cxa_pure_virtual()в независимый объектный файл (а затем удалить определение из всех остальных объектных файлов).
Ищу варианты между (и в том числе)
- минимальная модификация проекта, чтобы сделать из него что-то полезное, и
- правильный набор исправлений, обеспечивающий правильную работу процесса сборки на всех поддерживаемых в настоящее время платформах и cygwin.
«Между», потому что могут быть некоторые промежуточные альтернативы, которые следует рассмотреть. Итак, на мой взгляд, самый важный вопрос здесь: "Какое самое простое/самое легкое исправление ошибки множественного определения (в данном контексте)?" за которым может следовать "Какие сведения должны быть переданы команде MySQL, чтобы о процессе сборки можно было (отчетно) сообщить в cygwin?"
-последние примечания-
Если разработчики MySQL отказались от поддержки cygwin, я не знаю, что вернет их внимание к этой платформе.
Я хотел бы, чтобы разработчики, у которых есть причина работать в cygwin, могли сохранить возможность протестировать свой код на сборке cygwin/unix соединителя MySQL.
Сообществу может быть полезно поддерживать базу знаний, содержащую, по крайней мере, минимальный набор хаков, чтобы сделать последнюю версию (и, возможно, некоторые последние версии) коннектора полезной для сборки в cygwin. Хорошим первым шагом к этому может быть обсуждение здесь stackoverflow, возможно, даже в виде комментариев и ответов в этой ветке.
