MySQLとMariaDBの両方のコネクタ（同じ遺産を共有 ）は、Windows上のVisualStudioでのみコンパイルおよび使用することを目的としています 。 StackOverflowには、これに関する多くの以前の質問があります。それらの問題は、標準ライブラリですでに定義されている多くの構造を定義し、標準ライブラリにもリンクしていることです。
VisualStudioまたはLinuxシステムに切り替えることをお勧めします 。 WindowsでGCCを使用する必要がある場合は、別のコネクタを探してください。これらの問題は簡単には解決できません。その場合、ソリューションが移植可能である可能性は低く、2つのコネクタの将来のバージョンでは機能しない可能性があります。 代替案
最初の問題：固定幅の整数
あなたが言及する最初の問題は、実際には固定幅整数型
に関連しています。 ヘッダーファイルで定義された32ビットオペレーティングシステム。 charのような従来の整数型があります 、short 、int 、long およびlong long ただし、前述の固定幅の整数もあります。
MySqlコネクタはint32_tを定義します config.hのデータ型 また、標準C++ライブラリがそれらを定義します。MySqlはint32_tを定義します。 コンパイラのデータ型は__int32
typedef __int32 int32_t;
typedef unsigned __int32 uint32_t;
これは驚くべきことにlong intであることが判明しました データ型
typedef long int int32_t;
typedef long unsigned int uint32_t;
標準ライブラリがそれらを通常のintとして定義している間
typedef int int32_t;
typedef unsigned int uint32_t;
long 整数データ型 少なくとも32ビットであることが保証されています ：32ビットアーキテクチャでは、long int 32ビットです（intのように） ）64ビットの場合、長さは異なります-long int 64ビットでint は32ビットのみです（を参照）ここ
）。つまり、実際には32ビットシステムの場合、これらの定義は同一である必要がありますが、コンパイラはそれらが競合していると見なします。
MySqlヘッダーは、対応するデータ型を定義する必要があるかどうかを決定するさまざまな定義（以下に示す提案されたソリューションが実際に機能する理由を理解できるように、その横に説明を配置します）でラップされています。
// Only define for 32-bit compilation
#if defined(_WIN32)
// Don't define if this custom flag is activated
#ifndef CPPCONN_DONT_TYPEDEF_MS_TYPES_TO_C99_TYPES
// Do not define for Visual Studio 2010 and later (but use C++ standard library instead)
#if _MSC_VER >= 1600
#include <stdint.h>
#else
// Only define if HAVE_MS_INT32 (another custom flag) is set to true (1)
#ifdef HAVE_MS_INT32
typedef __int32 int32_t;
#endif
// Some more data type defines...
#endif
#endif
#endif
ソリューション
上記のヘッダーファイルの構造に基づいて、これにはいくつかの解決策があります。実行可能なものもあれば、実行可能でないものもあります。
-
明らかに、
cstdintに型定義を含めることはできません。 およびstdint.hそして、MySqlが定義するものと一緒に住んでいます。これは実際にはかなり制限されており、遅かれ早かれ別の標準ライブラリヘッダーに含まれる可能性があり、標準ライブラリをまったく使用しないように強制される可能性があり、非常に制限される可能性があります。 -
使用している32ビットビルドツールチェーンを完全に放棄し、** 64ビットコンパイラに切り替えて、64ビット用にコンパイルすることができます。 。この場合、これはヘッダー
config.hとして発生しないはずです。 MySqlには、上記のように32ビットシステムにのみ含まれています。プロジェクトが32ビットである必要があるという正当な理由がない場合、それは私が実際に行うことです。コンパイラについて：2016年にリリースされたGCC 6.3.0を使用しているようですが、実際にはC++17を完全にはサポートしていません 言語標準CMAKE_CXX_STANDARD 17でコンパイルするように指示しています CMakeファイルで。 C ++ 17の機能を広範囲に使用したい場合は、別の新しいコンパイラを使用することをお勧めします。そうでなければ、C++14もそれほど悪くはありません。 -
Visual Studio 2010を使用できます （バージョン
1600）以降 この場合のようにコンパイルする場合、ヘッダーには、独自の定義を定義するのではなく、標準の定義が自動的に含まれます。 -
プリプロセッサフラグを定義する
#define CPPCONN_DONT_TYPEDEF_MS_TYPES_TO_C99_TYPESこのフラグがconfig.hに設定されているかのように、コードの上（またはプロジェクトに使用しているIDE内）に ファイルはデータ型を定義しません。 -
同様に、
MYSQLC~1.0/include/jdbc/cppconn/config.hを開いて解決することもできます。 およびプリプロセッサディレクティブを変更する から#define HAVE_MS_INT32 1 #define HAVE_MS_UINT32 1に
#define HAVE_MS_INT32 0 #define HAVE_MS_UINT32 0これにより、このヘッダーを含む、将来作成するすべてのプログラムに対応する定義が非アクティブ化されます。
2番目の問題：VisualStudioでコンパイルされたライブラリへのリンク
表示される2番目のエラーメッセージは、実際にはライブラリのリンクに関連しています。異なるコンパイラでコンパイルされたWindowsライブラリでは、通常、互換性がありません。つまり、GCCでコンパイルされたプログラムには、VisualStudioでコンパイルされたライブラリを含めることはできません。 この場合、DLLはVisual Studioでコンパイルされているため、GCCプログラムへのリンクは失敗します。
また述べたように、ここ
cmake -G "MinGW Makefiles" を使用すると、CMakeにVisualStudioの代わりにMinGWを使用させることができます。 しかし、私はそれを試しましたが、MariaDBでもMySQLでも動作しません。
MSYS2 を使用する MySQLでは、公式ガイド 次に使用する
cmake -DCMAKE_BUILD_TYPE=RelWithDebInfo -G "MinGW Makefiles" -DCONC_WITH_UNIT_TESTS=Off -DCONC_WITH_MSI=OFF -DWITH_SSL=SCHANNEL .
cmake --build . --config RelWithDebInfo
/src/CArrayImp.hの変更など、いくつかの手動変更を行う必要があります 行59を
#ifndef _WIN32
# define ZEROI64 0LL
#else
# define ZEROI64 0I64
#endif
に
#define ZEROI64 0LL
0I64として VisualStudioによってのみ定義されます。さらに、CArray.cppのテンプレートインスタンス化を削除する必要があります しかし、それでもThe system cannot find the path specified.になります。 エラーメッセージ。同様に、Cygwinでコンパイルすることもできませんでした。
SQLC++コネクタの代替
私は最後の問題の解決策を持っていませんが、あなたは代替案を見てみたいと思うかもしれません。 SQLite をダウンロードできます。 ソースからコンパイルします。 ソースからのインストールガイド によると MinGWと互換性がありますが、軽量 。したがって、シェアウェアは SQLAPI++ である必要があります。 。 彼らの「注文」ページ によると Windowsの試用版は完全に機能しています
どちらもMySqlをサポートする必要があります：例： こちら を参照してください。 。
tl; dr： MySQLおよびMariaDBコネクタはVisualStudioのWindowsのみで使用してください 。 Visual Studioを使用できない場合は、SQLite代替C++SQLコネクタをご覧ください。>> および