Я пытаюсь собрать MySQL "Connector / C" из исходного кода в 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 в тщетной надежде, что компилятор удалит внешнююссылка на функцию, которая была использована в строке.(Я не уверен, когда C ++ использует таблицу поиска в качестве слоя косвенности, но кажется, что inline может не быть вариантом в этих случаях.) Если я помню конкретный результат этого теста: он создал тот же результаткак нет определение __cxa_pure_virtual(). - Я начал искать использование чисто виртуальных функций в источнике
libmysql, но это выглядело как кроличья нора ... - I рассматривал изучение процесса сборки, чтобы поместить определение
__cxa_pure_virtual() в независимый объектный файл (и затем я бы удалил определение из любого другого объектного файла).
Я ищу варианты между (и включающими)
- минимальной модификацией проекта, чтобы сделать его полезной, и
- правильным набором исправленийэто делает процесс сборки корректно работающим на всех поддерживаемых в настоящее время платформах и cygwin.
«Между», потому что могут быть некоторые промежуточные альтернативы, которые следует рассмотреть.Итак, на мой взгляд, самый важный вопрос здесь: «Каково самое простое / простое исправление ошибки множественного определения (в данном контексте)?» может сопровождаться «Какие вещи нужно передать команде MySQL, чтобы процесс сборки можно было (пере) перенести в cygwin?»
- заключительные замечания -
Если бы разработчики MySQL отказались от поддержки cygwin, я не знаю, что могло бы привлечь их внимание к этой платформе.
Я хотел бы видеть, что разработчики, у которых есть причина работать в cygwin, могут сохранитьвозможность проверить свой код на сборке cygwin / unix коннектора MySQL.
В сообществе может быть какая-то ценность, поддерживая базу знаний, содержащую, по крайней мере, минимальный минимальный набор хаков для создания последней версии(и, может быть, некоторые последние версии) коннектора с пользой собираются в cygwin.Хорошим первым шагом в этом направлении может стать обсуждение стекопотока, возможно, даже в качестве комментариев и ответов в этой теме.