WebMoney:  WMZ Z294115950220  WMR R409981405661  WME E134003968233	Visa  4274 3200 2453 6495

Глава 5. Сборка приложений Connector/C++ Эта глава дает представление о сборке приложений Connector/C++: Общие соображения для сборки. Посмотрите раздел 5.1. Информация о сборке приложений C++, которая относится к определенным платформам, таким как Windows, macOS и Solaris. См. раздел 5.2. Для обсуждения интерфейсов программирования, доступных Connector/C++, см. Chapter 1. 5.1. Общие соображения Эта секция обсуждает общие соображения, чтобы иметь в виду, собирая приложения C++. Для получения информации, которая относится к конкретным платформам, посмотрите секцию, которая относится к вашей платформе, в разделе 5.2 . Команды, показанные здесь, даны из командной строки (например, как вызванные из Makefile). Команды относятся к любой платформе, которая понимает make и такие инструменты командной строки, как g++, cc или clang, но, возможно, нуждаются в поправке на вашу среду сборки. Инструменты и параметры конфигурации Важно, чтобы инструменты, которые вы используете, чтобы собрать приложение Connector/C++, были совместимы с инструментами, используемыми, чтобы собрать сам Connector/C++. Идеально, соберите свои приложения теми же самыми инструментами, которые использовались, чтобы построить Connector/C++. Чтобы избежать проблем, гарантируйте, что эти факторы одинаковы для ваших приложений и самого Connector/C++: Версия компилятора. Библиотека времени выполнения. Параметры конфигурации компоновщика времени выполнения. Чтобы избежать потенциальных катастроф, конфигурация сборки Connector/C++ должна соответствовать конфигурации сборки приложения. Например, не используйте сборку конечных версий Connector/C++ с отладочной сборкой клиентского приложения. Чтобы использовать отличную версию компилятора, конфигурацию выпуска или библиотеку времени выполнения, сначала соберите Connector/C++ из исходного текста, используя ваши желаемые параметры настройки (см. главу 4), затем создайте свои приложения, используя те же самые параметры настройки. Двоичные дистрибутивы Connector/C++ включают файл INFO_BIN, который описывает окружающую среду и параметры конфигурации. Если вы установили из дистрибутива и есть связанные с платформой проблемы, это может помочь проверить параметры настройки, которые использовались, чтобы построить пакет на этой платформе. Также есть файл INFO_SRC, который предоставляет информацию о версии продукта и исходном хранилище, из которого был произведен дистрибутив. До Connector/C++ 8.0.14 был файл BUILDINFO.txt вместо INFO_BIN и INFO_SRC. Поддержка C++ 11 X DevAPI использует языковые особенности C++ 11. Чтобы собрать приложения Connector/C++, которые используют X DevAPI, включите поддержку C++ 11 в компиляторе, используя опцию -std=c++11. Этот выбор не нужен для приложений, которые используют X DevAPI для C (который является просто C API) или старый JDBC API (основанный на простом C++), если код приложения не использует C++ 11. Заголовочные файлы Connector/C++ API приложения определяет, которые использовать заголовочные файлы Connector/C++. Следующее включает советы при предположении, что путь включаемых файлов $MYSQL_CPPCONN_DIR/include, где $MYSQL_CPPCONN_DIR это каталог установки Connector/C++. Включите в вызов компилятора опцию -I $MYSQL_CPPCONN_DIR/include, чтобы гарантировать это. Для приложений, которые используют X DevAPI: #include <mysqlx/xdevapi.h> Для приложений, которые используют X DevAPI for C: #include <mysqlx/xapi.h> Для приложений, которые используют JDBC API, заголовочные файлы зависят от версии: С Connector/C++ 8.0.16 директива #include достаточна: #include <mysql/jdbc.h> До Connector/C++ 8.0.16 надо было использовать набор директив #include: #include <jdbc/mysql_driver.h> #include <jdbc/mysql_connection.h> #include <jdbc/cppconn/*.h> Нотация <jdbc/cppconn/*.h> значит, что необходимо включать все заголовочные файлы из каталога jdbc/cppconn, которые необходимы вашему приложению. Конкретные файлы звисят от приложения. Устаревший код, который использует Connector/C++ 1.1, имеет #include в такой форме: #include <mysql_driver.h> #include <mysql_connection.h> #include <cppconn/*.h> Чтобы построить такой код с Connector/C++ 8.0 не изменяя его, надо добавить $MYSQL_CPPCONN_DIR/include/jdbc к пути включаемых файлов. Чтобы собрать код, который вы намереваетесь связать статически с Connector/C++, определите макрос, который регулирует декларации API в заголовочных файлах для использования со статической библиотекой. Для получения дополнительной информации посмотрите здесь. Заголовочные файлы Boost Заголовочные файлы Boost необходимы при этих обстоятельствах: Чтобы собрать приложения Connector/C++, которые используют legacy JDBC API. До Connector/C++ 8.0.16 на Unix для приложений, которые используют X DevAPI или X DevAPI for C, если вы собираете с использованием gcc и версия библиотеки C++ в вашей системе не реализует конвертер UTF8 (codecvt_utf8). Если заголовочные файлы Boost необходимы, Boost 1.59.0 или более новый должен быть установлен, и местоположение заголовков должно быть добавлено к пути include. Чтобы получить Boost и его инструкции по установке, посетите the official Boost site. Библиотеки Сборка Connector/C++ с применением OpenSSL делает библиотеку зависящей от динамических библиотек OpenSSL. В этом случае: Компонуя приложение динамически с Connector/C++, эта зависимость релевантна только во время выполнения. Компонуя приложение статически с Connector/C++, компонуйте с библиотеками OpenSSL также. На Linux это означает добавление -lssl -lcrypto явно к командам сборки. В Windows это обработано автоматически. В Windows компнуйте с динамической версией библиотеки времени выполнения C++. Библиотеки времени выполнения X DevAPI for C нужно libstdc++ во время выполнения. В зависимости от вашей платформы или инструментов сборки, разные библиотеки могут применяться. Например, библиотека libc++ в macOS, см. раздел 5.2.2. Если приложение создается, используя динамически подключаемые библиотеки, те библиотеки должны присутствовать не только на сборочном хосте, но и на целевых хостах, где идет выполнение приложения. Динамический компоновщик должен правильно формироваться, чтобы найти те библиотеки и их зависимости во время выполнения, а также найти библиотеки Connector/C++ и их зависимости во время выполнения. Библиотеки Connector/C++, построенные Oracle, зависят от библиотек OpenSSL. Последний должен быть установлен на системе, чтобы управлять кодом, который связывается с библиотеками Connector/C++. Другой выбор состоит в том, чтобы поместить библиотеки OpenSSL в то же самое местоположение, где Connector/C++, в этом случае, динамический компоновщик должен найти их рядом с библиотекой, см. также разделы 5.2.1 и 5.2.2. Использование динамической библиотеки Connector/C++ Название динамической библиотеки Connector/C++ зависит от платформы. Эти библиотеки осуществляют X DevAPI и X DevAPI для C, где A в имени библиотеки представляет версию ABI: libmysqlcppconn8.so. A (Unix). libmysqlcppconn8. A.dylib (macOS). mysqlcppconn8- A-vsNN.dll с библиотекой импорта vs NN/mysqlcppconn8.lib (Windows). Для legacy JDBC API динамические библиотеки называют следующим образом, где B в имени библиотеки представляет версию ABI: libmysqlcppconn.so. B (Unix). libmysqlcppconn. B.dylib (macOS). mysqlcppconn-B -vsNN.dll с библиотекой импорта vs NN/mysqlcppconn-static.lib (Windows). В Windows значение vs NN в названии библиотеки зависит от версии набора инструментальных средств MSVC, используемой, чтобы построить библиотеки. Библиотеки Connector/C++ от Oracle применяют vs14, и они совместимы с MSVC и 2015 2017. Это соглашение позволяет пользоваться библиотеками, построенными различными версиями MSVC на той же самой системе. См. также раздел 5.2.1. Чтобы построить код, который использует X DevAPI или X DevAPI для C, надо добавить -lmysqlcppconn8 к опциям компоновщика. Чтобы построить код legacy JDBC API, добавьте -lmysqlcppconn. Необходимо также указать, пользоваться ли 64-битными или 32-битными библиотеками, определяя соответствующий каталог библиотеки. Используйте опцию компоновщика -L, чтобы определить $MYSQL_CONCPP_DIR/lib64 (64-bit) или $MYSQL_CONCPP_DIR/lib (32-bit), где $MYSQL_CPPCONN_DIR это каталог установки Connector/C++. В FreeBSD /lib64 не используется. Название библиотеки всегда заканчивается /lib. Чтобы собрать приложение Connector/C++, которое использует X DevAPI, есть исходные тексты в app.cc, они компонуются динамически с библиотекой, Makefile мог бы быть похожим на это: MYSQL_CONCPP_DIR = Connector/C++ installation location CPPFLAGS = -I $(MYSQL_CONCPP_DIR)/include -L $(MYSQL_CONCPP_DIR)/lib64 LDLIBS = -lmysqlcppconn8 CXXFLAGS = -std=c++11 app : app.cc С этим Makefile команда make app производит следующий вызов компилятора: g++ -std=c++11 -I .../include -L .../lib64 app.cc -lmysqlcppconn8 -o app Чтобы собрать простое приложение C, которое использует X DevAPI для C, из исходных текстов в app.c и скомпоновать динамически с библиотекой, Makefile такой: MYSQL_CONCPP_DIR = Connector/C++ installation location CPPFLAGS = -I $(MYSQL_CONCPP_DIR)/include -L $(MYSQL_CONCPP_DIR)/lib64 LDLIBS = -lmysqlcppconn8 app : app.c С таким Makefile команда make app производит следующий вызов компилятора: cc -I .../include -L .../lib64 app.c -lmysqlcppconn8 -o app Получающийся код даже при том, что это собрано как plain C, зависит от C++ runtime (как правило, libstdc++, хотя это может отличаться в зависимости от платформы или инструментов сборки, см. здесь). Чтобы собрать простое приложение C++, которое использует legacy JDBC API из исходного текста app.c и скомпоновать его автоматически, Makefile мог бы быть похожим на это: MYSQL_CONCPP_DIR = Connector/C++ installation location CPPFLAGS = -I $(MYSQL_CONCPP_DIR)/include -L $(MYSQL_CONCPP_DIR)/lib64 LDLIBS = -lmysqlcppconn app : app.c Выбор библиотеки в этом случае -lmysqlcppcon, а не -lmysqlcppcon8, что касается X DevAPI или X DevAPI для C. С этим Makefile команда make app производит следующий вызов компилятора: cc -I .../include -L .../lib64 app.c -lmysqlcppconn -o app Запуская приложение, которое использует Connector/C++, динамическая библиотека, библиотека и ее зависимости во время выполнения должны быть найдены динамическим компоновщиком. Посмотрите здесь. Используя статическую библиотеку Connector/C++ Возможно связать ваше приложение со статической библиотекой Connector/C++. Этот путь дает независимость во время выполнения от соединителя, и получающийся модуль может работать на системах, где не устанавливается Connector/C++. Компонуя статически, получающийся код все еще зависит от всех зависимостей во время выполнения библиотеки Connector/C++. Например, если Connector/C++ собран, используя OpenSSL, у кода есть зависимость во время выполнения от библиотек OpenSSL. Посмотрите здесь. Статическое название библиотеки зависит от платформы. Эти библиотеки осуществляют X DevAPI и X DevAPI для C: libmysqlcppconn8-static.a (Unix, macOS). vsNN /mysqlcppconn8-static.lib (Windows). Для legacy JDBC API статические библиотеки называют следующим образом: libmysqlcppconn-static.a (Unix, macOS). vs NN/mysqlcppconn-static.lib (Windows). В Windows значение vs NN в названии библиотеки зависит от версии набора инструментальных средств MSVC, используемой, чтобы построить библиотеки. Библиотеки от Oracle обозначены vs14, они совместимы с 2017 и 2015 MSVC.) Это соглашение позволяет пользоваться библиотеками, построенными с различными версиями MSVC на той же самой системе. См. также раздел 5.2.1. Чтобы собрать код, который вы намереваетесь связать статически, с Connector/C++, определите макрос, который регулирует декларации API в заголовочных файлах для использования со статической библиотекой. Один способ определить макрос, это передать опцию -D в команде вызова компилятора: Для приложений, которые используют X DevAPI, X DevAPI для C или (с Connector/C++ 8.0.16) legacy JDBC API, определить макрос STATIC_CONCPP. Все, что имеет значение, это то, что вы его определяете вообще, значение не имеет значения. Например: -DSTATIC_CONCPP. До Connector/C++ 8.0.16 для приложений, которые используют legacyс JDBC API, определите макрос CPPCONN_PUBLIC_FUNC как пустую строку. Чтобы гарантировать это, определите макрос как CPPCONN_PUBLIC_FUNC=, но не как CPPCONN_PUBLIC_FUNC, например: -DCPPCONN_PUBLIC_FUNC=. Чтобы собрать приложение Connector/C++, которое использует X DevAPI, из исходного текста в app.cc и статически скомпоновать с библиотекой, Makefile такой: MYSQL_CONCPP_DIR = Connector/C++ installation location CPPFLAGS = -DSTATIC_CONCPP -I $(MYSQL_CONCPP_DIR)/include LDLIBS = $(MYSQL_CONCPP_DIR)/lib64/libmysqlcppconn8-static.a -lssl -lcrypto -lpthread CXXFLAGS = -std=c++11 app : app.cc С этим Makefile команда make app производит: g++ -std=c++11 -DSTATIC_CONCPP -I .../include app.cc .../lib64/libmysqlcppconn8-static.a -lssl -lcrypto -lpthread -o app Чтобы избежать отчет компоновщика unresolved symbols, строка компиляции должна включать библиотеки OpenSSL и pthread, от которой зависит код Connector/C++. Библиотеки OpenSSL не необходимы, если Connector/C++ строится без них, но дистрибутивы Connector/C++ от Oracle действительно зависят от OpenSSL. Точный список библиотек, требуемых библиотекой Connector/C++, зависит от платформы. Например, на Solaris нужны socket, rt и nsl. Чтобы собрать простое приложение C, которое использует X DevAPI для C, из исходного текста в app.c и скомпоновать его статически с библиотекой, Makefile такой: MYSQL_CONCPP_DIR = Connector/C++ installation location CPPFLAGS = -DSTATIC_CONCPP -I $(MYSQL_CONCPP_DIR)/include LDLIBS = $(MYSQL_CONCPP_DIR)/lib64/libmysqlcppconn8-static.a -lssl -lcrypto -lpthread app : app.c С этим Makefile команда make app выдаст: cc -DSTATIC_CONCPP -I .../include app.c .../lib64/libmysqlcppconn8-static.a -lssl -lcrypto -lpthread -o app Чтобы собрать простое приложение C, которое использует legacy JDBC API, из исходного текста в app.c и скомпоновать его статически с библиотекой, Makefile такой: MYSQL_CONCPP_DIR = Connector/C++ installation location CPPFLAGS = -DCPPCONN_PUBLIC_FUNC= -I $(MYSQL_CONCPP_DIR)/include LDLIBS = $(MYSQL_CONCPP_DIR)/lib64/libmysqlcppconn-static.a -lssl -lcrypto -lpthread app : app.c Выбор библиотеки в этом случае libmysqlcppcon-static.a, вместо libmysqlcppcon8-static.a, как для X DevAPI или X DevAPI for C. С этим Makefile команда make app выдаст: cc -std=c++11 --DCPPCONN_PUBLIC_FUNC= -I .../include app.c .../lib64/libmysqlcppconn-static.a -lssl -lcrypto -lpthread -o app Строя код простого C, важно заботиться о зависимости соединителя от времени выполнения C++, которое вводится библиотекой соединителя даже при том, что код, который использует его, является plain C: Один подход должен гарантировать, что компоновщик C++ используется, чтобы построить окончательный код. Этот подход проявлен в этом Makefile: MYSQL_CONCPP_DIR = Connector/C++ installation location CPPFLAGS = -DSTATIC_CONCPP -I $(MYSQL_CONCPP_DIR)/include LDLIBS = $(MYSQL_CONCPP_DIR)/lib64/libmysqlcppconn8-static.a -lssl -lcrypto -lpthread LINK.o = $(LINK.cc) # use C++ linker app : app.o С этим Makefile у процесса сборки есть два шага: сначала соберите исходный код приложения в app.c с использованием компилятора C, чтобы произвести app.o, затем скомпонуйте заключительный исполняемый файл (app) с использованием компоновщика C++, который заботится о зависимости от времени выполнения C++. Команды выглядят примерно так: cc -DSTATIC_CONCPP -I .../include -c -o app.o app.c g++ -DSTATIC_CONCPP -I .../include app.o .../libmysqlcppconn8-static.a -lssl -lcrypto -lpthread -o app Другой подход должен использовать компилятор и компоновщик C, но добавить библиотеку времени выполнения C++ libstdc++ как явный выбор компоновщика. Этот подход проявлен в этом Makefile: MYSQL_CONCPP_DIR = Connector/C++ installation location CPPFLAGS = -DSTATIC_CONCPP -I $(MYSQL_CONCPP_DIR)/include LDLIBS = $(MYSQL_CONCPP_DIR)/lib64/libmysqlcppconn8-static.a -lssl -lcrypto -lpthread -lstdc++ app : app.c С этим Makefile компилятор вызван следующим образом: cc -DSTATIC_CONCPP -I .../include app.c .../libmysqlcppconn8-static.a -lssl -lcrypto -lpthread -lstdc++ -o app Даже если приложение, которое использует Connector/C++, написано на C, заключительный исполняемый файл зависит от времени выполнения C++, которое должно быть установлено на целевом компьютере. 5.2. Сборка приложений Connector/C++: определенные для платформы соображения Эта секция обсуждает определенные для платформы соображения, чтобы иметь в виду, строя Connector/C++. Для общих соображений, которые применяются на независимой от платформы основе, посмотрите раздел 5.1. 5.2.1. Для Windows Эта секция описывает определенные для Windows аспекты сборки Connector/C++. Разработчики, использующие Microsoft Windows, должны удовлетворить эти условия, чтобы построить приложение Connector/C++: Требуется приемлемая версия Microsoft Visual Studio. Ваши приложения должны использовать ту же самую конфигурацию компоновщика, как Connector/C++. Например, используйте один из /MD, /MDd, /MT или /MTd. У целевых хостов должна быть приемлемая версия Visual C++ Redistributable for Visual Studio. Для получения информации о версиях Visual Studio и VC++ Restributable см. здесь. В Windows приложения могут быть созданы по-разному (также известно как конфигурации сборки), которые определяют тип библиотеки времени выполнения, которой пользуется заключительный исполняемый файл: Приложение может быть создано в 32-битном или 64-битном режиме. Приложение может быть создано в режиме отладки или выпуска. Можно выбрать между статическим временем выполнения (/MT) или динамическим (/MD). Различные версии компилятора MSVC также используют различные версии времени выполнения. Двоичные дистрибутивы Connector/C++ 8.0 доступны как 64-битные и 32-битные пакеты, которые хранят библиотеки в каталогах, названных lib64 и lib, соответственно. Имена пакета и определенные имена файлов библиотеки и имена каталогов также включают vsNN. Значение vsNN в этих именах зависит от версии набора инструментальных средств MSVC, используемой, чтобы построить библиотеки. Это соглашение позволяет пользоваться библиотеками, построенными с различными версиями MSVC на той же самой системе. vsNN представляет основную версию набора инструментальных средств MSVC, используемого, чтобы построить библиотеки. В настоящее время это vs14, который является набором инструментальных средств, используемым с MSVC от 2015 до 2019. Важно гарантировать, чтобы версия компилятора и режим сборки соответствовали параметрам, используемым, чтобы построить библиотеку соединителя, чтобы гарантировать, что соединитель и приложение пользовались той же самой библиотекой времени выполнения. Двоичные дистрибутивы Connector/C++ 8.0 построены в режиме выпуска, используя динамическое время выполнения (/MD). Библиотеки совместимы с 2019 и 2017 MSVC, код, который пользуется этими библиотеками, может быть построен с любым 2019 или 2017 MSVC в режиме /MD. Чтобы построить кодекс в ином режиме, сначала постройте Connector/C++ из исходного кода в нужном режиме (см. раздел 4.3), затем создайте свои приложения, используя тот же самый режим. Компонуя динамически, возможно построить ваш код в режиме отладки, даже если библиотеки соединителя строятся в режиме выпуска. Однако в этом случае невозможно войти в код соединителя во время сеанса отладки. Чтобы быть в состоянии сделать это или построить в режиме отладки, компонуя статически с соединителем, необходимо сначала построить Connector/C++ в режиме отладки. Компоновка приложений с Connector/C++ Connector/C++ доступен как динамическая или статическая библиотека, чтобы использовать с вашим приложением. У динамического названия библиотеки соединителя есть расширение .dll, она используется с библиотекой импорта, у которой есть расширение .lib в подкаталоге vsNN. Таким образом динамическая библиотека соединителя mysqlcppconn8-2-vs14.dll используется с библиотекой импорта vs14/mysqlcppconn8.lib. 2 в имени динамической библиотеки это главный номер версии ABI. Это помогает, пользуясь библиотеками совместимости со старым ABI вместе с новыми библиотеками, имеющими различный ABI. У библиотек, установленных на вашей системе, может быть различная версия ABI в их именах файлов. Соответствующую статическую библиотеку называют vs14/mysqlcppconn8-static.lib. Динамическая библиотека legacy JDBC connector с именем mysqlcppconn-7-vs14.dll используется с библиотекой импорта vs14/mysqlcppconn.lib. Соответствующую статическую библиотеку называют vs14/mysqlcppconn-static.lib. Следующие таблицы указывают файлы динамической и библиотеки импорта, чтобы использовать для динамического подключения, и файлы статической библиотеки, чтобы использовать для статического подключения. LIB обозначает инсталляционное имя пути к библиотеке Connector/C++. Название последнего компонента пути lib64 (64-bit) или lib (32-bit). Таблица 5.1. Библиотеки Connector/C++ дианмическая и импорта Тип соединителя Динамическое имя файла библиотеки Имя файла библиотеки импорта X DevAPI, X DevAPI for C LIB /mysqlcppconn8-2-vs14.dll LIB /vs14/mysqlcppconn8.lib JDBC LIB /mysqlcppconn-7-vs14.dll LIB /vs14/mysqlcppconn.lib Таблица 5.2. Статические библиотеки Connector/C++ Тип соединителя Статическое имя файла библиотеки X DevAPI, X DevAPI for C LIB /vs14/mysqlcppconn8-static.lib JDBC LIB /vs14/mysqlcppconn-static.lib При сборке кода, который пользуется библиотеками Connector/C++, использование эти рекомендации для настройки конфигурации проекта: Как дополнительный включаемый каталог укажите $MYSQL_CPPCONN_DIR/include. Как дополнительный включаемый каталог укажите $MYSQL_CONCPP_DIR/lib64 (для 64-bit) или $MYSQL_CONCPP_DIR/lib (для 32-bit). Чтобы использовать динамический файл библиотеки (.dll), компонуйте приложение с библиотекой импорта .lib: добавьте к опциям компоновки vs14/mysqlcppconn8.lib или vs14/mysqlcppconn.lib для старого кода. Во время выполнения у приложения должен быть доступ к библиотеке .dll. Чтобы использовать статический файл библиотеки (.lib), компонуйте приложение с библиотекой: добавьте vs14/mysqlcppconn8-static.lib или vs14/mysqlcppconn-static.lib для старого кода. Компонуя статически, компоновщик должен найти библиотеки (расширение .lib) для необходимых библиотек OpenSSL. Если соединитель был установлен из двоичного пакета, обеспеченного Oracle, они присутствуют в подкаталоге vs14 в соответствии с главным каталогом библиотеки ($MYSQL_CONCPP_DIR/lib64 или $MYSQL_CONCPP_DIR/lib), соответствующие библиотеки OpenSSL .dll присутствуют в главном каталоге библиотеки, рядом с .dll. Приложение Windows, которое использует динамическую библиотеку соединителя, должно быть в состоянии определить ее местонахождение во время выполнения, а также зависимости, такие как OpenSSL. Распространенный способ устроить это состоит в том, чтобы поместить необходимые DLL в то же самое место, где исполняемый файл. Сборка приложений Connector/C++ в Microsoft Visual Studio Начальные шаги для того, чтобы создать приложение являются теми же самыми, пользуетесь ли вы динамической или статической библиотекой. Некоторые дополнительные шаги варьируются, в зависимости от того, пользуетесь ли вы динамической или статической библиотекой. Начало сборки приложения Эти шаги одинаковы, пользуетесь ли вы динамической или статической библиотекой: Начните новый проект Visual C++ в Visual Studio. В выпадающем списке для конфигурации сборки на панели инструментов измените конфигурацию от опции по умолчанию Debug на Release. Конфигурация сборки Connector/C++ и приложения должны соответствовать. Поскольку прикладная конфигурация сборки должна соответствовать конфигурации сборки Connector/C++, который это использует, Release требуется, используя построенный Oracle Connector/C++, который строится в конфигурации выпуска. Компонуя динамически возможно построить ваш код в режиме отладки, даже если библиотеки соединителя строятся в режиме выпуска. Однако в этом случае невозможно войти в код соединителя во время сеанса отладки. Чтобы быть в состоянии сделать это или построить в режиме отладки, связываясь статически с соединителем, необходимо построить Connector/C++ из исходного текста, используя режим Debug. Из главного меню выбирают Project, Properties. К этому можно также получить доступ, используя горячую клавишу ALT + F7. В Configuration Properties откройте структурный вид. Выберите C/C++, General. В Additional Include Directories: Добавьте каталог include/ Connector/C++. Этот каталог должен быть расположен в рамках инсталляционного каталога Connector/C++. Если нужен Boost, чтобы создавать приложение, также добавьте корневой каталог библиотеки Boost. См. раздел 5.1. В структурном виде откройте Linker, General, Additional Library Directories. В текстовом поле Additional Library Directories добавьте каталог библиотеки Connector/C++. Он должен быть расположен в рамках инсталляционного каталога Connector/C++. Имя каталога заканчивается на lib64 (64-bit) или lib (32-bit). Остающиеся шаги зависят от того, создаете ли вы приложение, чтобы использовать динамическую или статическую библиотеку Connector/C++. Сборка с с динамической библиотекой Чтобы создать приложение, чтобы использовать динамическую библиотеку Connector/C++, выполните эти шаги: Откройте Linker, Input в диалоге Property Pages. Добавьте соответствующее название библиотеки импорта в текстовое поле Additional Dependencies. Например, надо использовать vs14/mysqlcppconn8.lib или vs14/mysqlcppconn.lib для старых приложений, посмотрите здесь. Выберите C++ Runtime Library для компоновки. В диалоге Property Pages откройте C++, Code Generation в структурном виде, затем выберите подходящий вариант для Runtime Library. Компонуйте с динамической версией библиотеки времени выполнения C++, выбрав /MD. Кроме того, у целевых хостов с клиентским приложением, должен быть установленный пакет Visual C++ Redistributable for Visual Studio. Для получения информации о версиях VC++ Restributable посмотрите здесь. Не используйте опции /MTd или /MDd, если вы используете построенный Oracle Connector/C++. Для объяснения посмотрите это обсуждение. Скопируйте соответствующую динамическую библиотеку к тому же самому каталогу, где находится исполняемый файл программы (см. здесь). Альтернативно, расширьте переменную окружения PATH, используя SET PATH=%PATH%;C:\path\ to\ cpp, или скопируйте динамическую библиотеку к инсталляционному каталогу Windows, обычно это C:\windows. Динамическая библиотека должна быть в том же самом каталоге, где исполняемый файл, или где-нибудь в пути системы, чтобы приложение могло получить доступ к динамической библиотеке Connector/C++ во время выполнения. Компоновка со статической библиотекой Чтобы создать приложение, чтобы использовать статическую библиотеку Connector/C++, выполните эти шаги: Откройте Linker, Input в диалоге Property Pages. Добавьте соответствующее статическое название библиотеки в текстовое поле Additional Dependencies. Например, vs14/mysqlcppconn8-static.lib или vs14/mysqlcppconn-static.lib для старых приложений, см. здесь . Чтобы собрать код, который связан статически с библиотекой соединителя, определите макрос, который регулирует декларации API в заголовочных файлах для использования со статической библиотекой. По умолчанию макрос определяется, чтобы объявить, что функции совместимы с приложением, которое вызывает DLL. В Project, Properties откройте структурный вид и под C++, Preprocessor введите соответствующий макрос в текстовое поле Preprocessor Definitions: Для приложений, которые используют X DevAPI, X DevAPI для C или (с Connector/C++ 8.0.16) legacy JDBC API, определите макрос STATIC_CONCPP. Все, что имеет значение, это то, что вы определяете его вообще, значение не имеет значения. Например: -DSTATIC_CONCPP. До Connector/C++ 8.0.16 для приложений, которые используют legacy JDBC API, определяют макрос CPPCONN_PUBLIC_FUNC как пустую строку. Чтобы гарантировать это, определите макрос как CPPCONN_PUBLIC_FUNC=, но не как CPPCONN_PUBLIC_FUNC. Выберите для компоновки C++ Runtime Library. В диалоге Property Pages откройте C++, Code Generation в структурном виде, затем выберите подходящий вариант для Runtime Library. Скомпонуйте с динамической версией библиотеки времени выполнения C++, выбрав опцию /MD. Кроме того, у целевых хостов должен быть установлен пакет Visual C++ Redistributable for Visual Studio. Для получения информации о версиях, см. здесь. Не используйте опцию /MTd или /MDd, если вы используете построенный Oracle Connector/C++. Для объяснения посмотрите это обсуждение. 5.2.2. Для macOS Эта секция описывает macOS-определенные аспекты сборки Connector/C++. Двоичный дистрибутив Connector/C++ для macOS собран, используя родной для macOS компилятор clang. По этой причине приложение, которое использует Connector/C++, должно быть создано с тем же самым компилятором clang. Компилятор clang может использовать две различных реализации библиотеки времени выполнения C++: native libc++ или GNU libstdc++. Важно, чтобы приложение использовало ту же самую реализацию, как и Connector/C++ то есть, native libc++. Чтобы гарантировать это, опция -stdlib=libc++ должна быть передана компилятору. Чтобы построить приложение Connector/C++, которое использует X DevAPI, из исходного файла app.cc и скомпоновать его динамически с библиотекой соединителя, Makefile для построения в macOS мог бы быть похожим на это: MYSQL_CONCPP_DIR = Connector/C++ installation location CPPFLAGS = -I $(MYSQL_CONCPP_DIR)/include -L $(MYSQL_CONCPP_DIR)/lib64 LDLIBS = -lmysqlcppconn8 CXX = clang++ -stdlib=libc++ CXXFLAGS = -std=c++11 app : app.cc Двоичные пакеты для macOS включают библиотеки OpenSSL, которые требуются кодом, связанным с соединителем. Эти библиотеки устанавливаются в том же самом месте, где библиотеки соединителя и должны быть найдены там динамическим компоновщиком. 5.2.3. Для Solaris Эта секция описывает определенные для Solaris аспекты сборки Connector/C++. С Connector/C++ 8.0.13 возможно построить приложения Connector/C++ в Solaris. Это требует компилятор SunPro 5.15 или выше (из Developer Studio 12.6). Более ранние версии и сборка с GCC не поддерживаются. Чтобы использовать пакет Connector/C++ от Oracle, код приложения должен быть построен с SunPro 5.15 или выше со следующими опциями: -m64 -std=c++11. Библиотеки C++ runtime и библиотека atomics должны быть по умолчанию (-library=stdcpp, -xatomics=studio). Библиотека соединителя и любой код, который использует его, зависят от библиотек времени выполнения GCC из Oracle Developer Studio 12.6, которая должна быть установлена, прежде чем вы запустите приложение. Посмотрите download options для Oracle Developer Studio. Инсталляционный пакет позволяет вам установить только библиотеки времени выполнения вместо полной Oracle Developer Studio, см. Installing Only the Runtime Libraries on Oracle Solaris 11 . У целевых хостов должны быть установлены библиотеки времени выполнения из Developer Studio 12.6.

Поиск На сайте В Яндексе

Вы можете направить письмо администратору этой странички, Алексею Паутову.