无法在cygwin中从源代码构建mysql连接器/c（libmysql）

我试图在cygwin中从源代码构建MySQL的“Connector/C”，但出现了一些问题

-一些上下文-

我们可以谈很多关于为什么有人想在cygwin中使用

libmysql

。在本例中，使用cygwin工具集在windows机箱上进行一些unix开发更简单

根据我的研究，看起来我可以得到一个旧版本（可能是5.1版）的连接器来构建OK。但是当MySQL开发人员从

/configure

切换到

cmake

驱动的构建配置时，cygwin的支持就落后了

MySQL提供供下载的源tar-ball版本是6.0.2，所以这就是我正在研究的版本

-一个（某种）已解决的问题-

我遇到的第一个问题是在

stdlib.h

中找到的

dtoa（）

的不兼容重新声明。（如果谷歌能提供一些指导的话，许多其他试图构建各种最新版本的人也遇到了这个问题。）网络上潜伏着各种各样的建议来解决这个问题。我的选择是：临时将

stdlib.h

替换为已删除

dtoa（）

定义的。丑陋，真的。但它是有效的

（此“修复”消除了早期编译错误，并且该过程一直运行到链接，链接失败的原因显然与此无关。）

-一个未解决的问题-

libmysql

代码依赖于

yaSSL

。即使我给了

cmake

一个

-DWITH_OPENSSL=1

参数，也似乎是这样，只有在我使用cygwin安装工具/软件包管理器将

OPENSSL-devel

软件包添加到我的环境中后，这个参数才被接受

yaSSL

似乎在使用“纯虚拟”类成员。从我（有限的）C++内部结构的知识来看，这意味着编译器隐式地假定特殊符号/函数<代码> > yxCxaPuRyValualAuthor（）/代码>的声明，这导致链接器搜索“代码”>（x）CxaApUrRyPuthId（）/<代码>函数（

）。 按照代码和构建过程的结构，每个

yaSSL

源实现文件都被编译成一个对象文件。其中许多文件引用了另一个文件，该文件定义（即包含）

\uuucxa\upure\uvirtual（）

的实现。在链接阶段，包含定义的每个对象都会相互冲突。（因为符号定义为

extern

，或者更具体地说：

extern "C" {
  int __cxa_pure_virtual() {
    assert("Pure virtual method called." == "Aborted");
    return 0;
  }
}

这些定义位于共享名称空间中。因此，链接器没有被指定一个规则来决定从每个引用链接到哪个定义。）结果是一个

多定义错误，例如：

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

我尝试过一些非常简单的尝试来解决这个问题


我删除了
\uucxa\upure\u virtual（）
的所有定义，但这只是将多个定义错误替换为未定义的引用错误
我将
\uucxa\u pure\u virtual（）
的所有定义更改为
内联
，徒劳地希望编译器将从内联使用的函数中删除外部引用。（我不确定C++何时使用查找表作为间接层，但似乎<代码>内联在这些情况下可能不是一种选择。）如果我记得那个测试的具体结果：它创建了与“<代码> > yxCxAuPuRyValual>>（）/<代码>相同的结果。
我开始在
libmysql
源代码中寻找纯虚拟函数的用法，但这似乎是一个兔子洞
我考虑研究构建过程，以便将
\ucxa\u pure\u virtual（）
的定义放在一个独立的对象文件中（然后，我将从其他每个对象文件中删除该定义）

我正在寻找（包括）之间的选项

对项目进行最小的修改以使其构建有用的东西，以及
使构建过程在所有当前支持的平台和cygwin上正常工作的正确补丁集
“介于”之间，因为可能需要考虑一些中间替代方案。因此，在我看来，这里最重要的问题是，“对于多定义错误（在这种情况下）最简单/最容易的修复方法是什么？”接下来可能是，“应该向MySQL团队反馈哪些内容，以便将构建过程（重新）移植到cygwin？”

-最后的笔记-

如果MySQL的开发人员已经放弃了cygwin支持，我不知道什么会让他们的注意力回到那个平台上

我希望有理由在cygwin中工作的开发人员能够保留使用cygwin/unix构建的MySQL连接器测试代码的选项

在社区中维护一个知识库可能有一定的价值，该知识库至少包含一组最简单的黑客，以便在cygwin中有效地构建连接器的最新版本（可能还有一些最新版本）。实现这一目标的第一步可能是在这里讨论stackoverflow，甚至可以作为对该线程的评论和回答。
为什么需要使用Cygwin构建Connector/C？普通的win32 libmysql.dll不够吗

让它编译的一些想法：

 a）你试图用GCC编译连接器/C作为C++编译器，最好不要这样做。使用g++

b） 克马克-DSKIP_SSL=1（查看CMakeLists.txt表明它将删除yassl）

是的，MySQL已经放弃了cygwin（它已经多年不支持它了）。我不知道是什么让Oracle重新启用它，他们目前正在削减平台支持（例如放弃HPUX和AIX）。另外，我个人认为Cygwin端口没有多大价值，它不是最热门的平台，只要你可以使用本机Windows端口。
它是（b）：
cmake
没有响应