无法从Cygwin的源代码编译的MySQL Connector / C（的libmysql） [英] Fail to build mysql connector/c (libmysql) from source in cygwin

问题描述

我试图从Cygwin的源代码编译MySQL的连接器/ C，有问题。

- 某些方面 -

我们可以谈了很多有关的为什么的有人想在Cygwin中使用的libmysql 。在这种情况下，它只是简单的做用cygwin的工具集Windows中某些UNIX的发展。

从我的研究，它看起来像我能得到连接器的老版本（5.1，也许）打造确定。不过cygwin的支持落后了，当MySQL开发从 ./配置切换到 cmake的驱动生成配置。

源焦油球，MySQL的下载提供最多的版本是6.0.2所以这是一个我的工作。

酮解决的问题（排序的） -

我遇到的第一个问题是不兼容的重新声明DTOA（）发现文件stdlib.h 。 （谁试图建立近期各种版本的许多人遇到过这个问题，也 - 如果谷歌是任何指导。）有各种建议潜伏在网络上解决这个问题。我的选择：暂时一个替换文件stdlib.h 有删除的 DTOA（）定义。的丑的，真实的。但它的和的

（这个修复消除早期的编译错误和过程贯穿到连接，它失败显然不相关的原因不清楚。）

-an没有解决的问题 -

的的libmysql code依赖于 yaSSL 。这似乎是，即使我把情况 cmake的的 -DWITH_OPENSSL = 1 参数，它才能被接受的在的我加入了的OpenSSL DEVEL 包我的cygwin的安装工具/包经理环境。 yaSSL 好像是用'纯虚'类成员。从C ++的内部的我（比较有限）的知识，这意味着编译器隐含地假定特殊符号/功能的声明__ cxa_pure_virtual（），这将导致链接器搜索 __ cxa_pure_virtual（）函数的（单）的定义。

一路code和建设过程中的结构，每个 yaSSL 代码实现文件编译成目标文件。许多这些文件的引用另一个定义（即包含的实现） __ cxa_pure_virtual（）。在链接阶段，每个对象包含彼此的定义冲突。 （因为符号定义为的extern ，或者更具体地说：

 的externC{
  INT __cxa_pure_virtual（）{
    断言（纯称为虚拟方法。==中止）;
    返回0;
  }
}
 

这些定义是在一个共享命名空间。因此，链接器并没有得到通过该决定从每个引用链接到一个）结果是多重定义错误，比如一个规则：

<$p$p><$c$c>CMakeFiles/libmysql.dir/__/extlib/yassl/taocrypt/src/algebra.cpp.o:algebra.cpp:(.text+0x40):多重定义`___cxa_pure_virtual
CMakeFiles / libmysql.dir / __ / EXTLIB / yassl / taocrypt / src目录/ aes.cpp.o：aes.cpp :(文字+为0x0）：首先这里定义

我已经尝试了一些高度简化的尝试解决这一问题。

• 我删除__ cxa_pure_virtual 的所有定义（）但这只是未定义引用错误取代了多重定义错误。


• 我改变__ cxa_pure_virtual 的所有定义（）到在线徒然希望编译器将消除外部从已使用的内联函数引用。 （我不知道，当C ++使用一个查找表作为间接层，但似乎在线可能无法在这种情况下的一个选项。）如果我记得该测试的具体结果是：它创造的结果相同的没有的的定义__ cxa_pure_virtual（）
。

• 我开始寻找在的libmysql 源的纯虚函数的用途但似乎是一个兔子洞...


• 我的认为的研究构建过程，以便放置的__ cxa_pure_virtual定义（）在一个独立的对象文件（的话，我将移除所有其他目标文件中定义）。

我在寻找的选项（包括）

1. 最小修改项目，使其建立一些有用的东西，和


2. 正确的补丁集，正确地使所有目前支持的平台上构建过程中工作的和的cygwin的。

之间，因为有可能是应考虑的一些中间的替代品。所以，我看到它的样子，这里最重要的问题是，什么是多重定义错误的最简单/最简单的解决（在这方面）？的可能紧随其后的是，应喂什么样的东西回来到MySQL团队，使构建过程可以（重新）移植到的cygwin？的

-Final笔记 -

如果MySQL的开发者已经放弃了cygwin的支持，我不知道是什么会带来他们的注意力回到了那个平台。

我想看到谁有理由在Cygwin的工作，开发人员可以保留测试其code对MySQL连接器的一个cygwin / UNIX构建的选项。

有可能在社会上保持一个知识库包含，至少，黑客最低限度的设定，使最新版本（和，也许，最近的一些版本）中的连接器构建有效的cygwin的一些价值。为了实现这一良好的第一步可能是在这里计算器上的一些讨论，甚至因为在此线程的意见和解答。

解决方案

为什么需要连接器/ C建有Cygwin的？将不正常的Win32下的libmysql.dll就够了？

一些想法，把它编译：

A）你试图连接器编译/ C使用gcc作为C ++编译器，最好不要。使用G ++。

B）cmake的。 -DSKIP_SSL = 1（寻找到的CMakeLists.txt建议它会删除yassl）

是的，MySQL已经被遗弃的cygwin（和它现在不支持它多年）。我不知道什么可能会甲骨文重新启用它回来了，他们目前相当成切割平台支持（例如HPUX和AIX被抛弃）。还亲自，我不会看到Cygwin的港口太大的价值，它不是最热的平台，只要您可以使用本地Windows端口。

I am trying to build MySQL's "Connector/C" from source in cygwin and there are problems.

-some context-

We could talk a lot about why anyone would want use libmysql in cygwin. In this case, it is just simpler to do some unix development on a windows box with the cygwin tool set.

From my research, it looks like I could get an older version (5.1, maybe) of the connector to build OK. But cygwin support trailed off when the MySQL developers switched from ./configure to cmake driven build configuration.

The version of the source tar-ball that MySQL offers up for download is 6.0.2 so that is the one I'm working on.

-one (sort-of) solved problem-

The first problem I encountered was an incompatible redeclaration of dtoa() found in stdlib.h. (Many others who have tried to build various recent versions encountered this problem, also - if google is any guide.) There are various suggestions lurking on the net to resolve this. My choice: temporarily replacing stdlib.h with one that has the dtoa() definition removed. Ugly, true. But it works.

(This 'fix' eliminates an early compile error and the process runs clear through to linking, where it fails for apparently unrelated reasons.)

-an unsolved problem-

The libmysql code relies on yaSSL. This seems to be the case even though I gave cmake the -DWITH_OPENSSL=1 parameter, which is accepted only after I added the openssl-devel package to my environment with the cygwin setup-tool/package-manager. yaSSL seems to be using 'pure virtual' class members. From my (somewhat limited) knowledge of the internals of C++, this means that the compiler implicitly assumes the declaration of the special symbol/function __cxa_pure_virtual() and this causes the linker to search for a (single) definition of the __cxa_pure_virtual() function.

The way the code and build process are structured, each of the yaSSL source implementation files is compiled into an object file. Many of those files reference another that defines (i.e. contains an implementation of) __cxa_pure_virtual(). In the linking stage, each object that contains a definition conflicts with each other. (Because the symbol is defined as extern, or more specifically:

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

These definitions are in a shared namespace. Thus, the linker has not been given a rule by which to decide which one to link-to from each reference.) The result is a multiple definition error, e.g.:

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

I've tried some highly simplistic attempts to resolve this problem.

• I removed all definitions of __cxa_pure_virtual() but that just replaces the multiple-definition errors with undefined-reference errors.
• I changed all definitions of __cxa_pure_virtual() to inline in the vain hope that the compiler would remove the external reference from a function that was used inline. (I'm not sure when C++ uses a lookup-table as a layer of indirection but it seems that inline may not be an option in those cases.) If I remember the specific result of that test: it created the same result as no definition of __cxa_pure_virtual().
• I started looking for uses of pure-virtual functions in the libmysql source but that seemed like a rabbit hole...
• I considered studying the build process in order to place a definition of __cxa_pure_virtual() in an independent object file (and, then, I would remove the definition from every other object file).

I'm looking for options between (and including)

1. the minimum modification to the project to make it build something useful, and
2. the correct patch-set that makes the build process work correctly on all currently supported platforms and cygwin.

"Between" because there might be some intermediate alternatives that should be considered. So, the way I see it, the most important question here is, "What is the simplest/easiest fix for the multiple-definition error (in this context)?" maybe followed closely by, "What kinds of things should be fed back to the MySQL team so that the build process can be (re-)ported to cygwin?"

-final notes-

If MySQL's developers have abandoned cygwin support, I don't know what would bring their attention back to that platform.

I would like to see that developers who have cause to work in cygwin could retain the option to test their code against a cygwin/unix build of the MySQL connector.

There might be some value in the community maintaining a knowledge base containing, at least, the bare minimum set of hacks to make the latest version (and, maybe, some recent versions) of the connector build usefully in cygwin. A good first step toward that might be some discussion here on stackoverflow, maybe even as comments and answers on this thread.

解决方案

Why do you need Connector/C built with Cygwin? Would not normal win32 libmysql.dll suffice?

Some ideas to get it compiling:

a)you're trying to compile Connector/C with gcc as C++ compiler, better don't. Use g++.

b)cmake . -DSKIP_SSL=1 (looking into CMakeLists.txt suggests it will remove yassl)

And yes, MySQL has abandoned cygwin (and it did not support it for many years now). I do not know what might get Oracle to reenable it back, they are currently rather into cutting platform support (e.g HPUX and AIX are abandoned). Also personally,I would not see much value in Cygwin port, it is not the hottest platform, as long as you can use native Windows port.

这篇关于无法从Cygwin的源代码编译的MySQL Connector / C（的libmysql）的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！