Как исправить ошибку: "LNK2019 ссылка на неразрешенный внешний символ"?

[Qraizer]

Вероятно, когда ты правил проект по заветам Majestio, ты отредактировал только одну, текущую конфигурацию. Надо было бы все, чтоб не возвращаться к этому, но ничего страшного, просто повтори ещё раз.

[sharky72]

Кстати во избежании будущих проблем с переносом проекта на другой диск или папку рекомендую использовать не абсолютные, а относительные пути до этих библиотек и заголовочных путей в настройках проекта (раз уж они внутри проекта) и использовать макросы подстановки $(SolutionDir) $(ProjectDir) и т.д.
$(SolutionDir)MySQL\lib64\vs14

Добавлено 23.09.25, 22:30
Далее..
Почему вы линкуете mysqlcppconnx-static.lib? У вас же динамическая линковка, а не статическая. Должно быть mysqlcppconnx.lib вернее mysqlcppconn.lib (потому что используете именно mysqlcppconn-10-vs14.dll, а не mysqlcppconnx-2-vs14.dll)

Ну и после исправлений тестовый пример работает нормально.

P.S. 14 это не версия студии, а версия toolchain (так написано в доке с MySQL connector). так что нарушений ODR быть не должно. 22 студия так же использует 14 тулчейн (v14.3), так что все работает и на новых студиях

Сообщение отредактировано: sharky72 - 23.09.25, 22:30

[sharky72]

И в Debug билде надо убрать STATIC_CONCPP в настройках препроцессора. Раз уж решили работать именно с dll.

Сообщение отредактировано: sharky72 - 23.09.25, 22:52

[Qraizer]

Цитата sharky72 @ 23.09.25, 21:46

P.S. 14 это не версия студии, а версия toolchain (так написано в доке с MySQL connector). так что нарушений ODR быть не должно. 22 студия так же использует 14 тулчейн (v14.3), так что все работает и на новых студиях

Никогда не задумывался, что это действительно можно тоже назвать тулчейном, как принято в embedded. Но отсутствие нарушений ODR всё ж не факт. Счас вот глянул, у меня их две версии, 14.16.27023 и 14.44.35207, отличаются минорами, ибо апдейты Студии они такие. Понятно, что первая уже неактуальна и не используется, но минор версии, на которой был собран SQL, неизвестно какой, и даже если в пределах мажора 14 ничего не должно поменяться, поменяться-таки могло, т.к. баги совместимости никто не отменял. Поэтому я всегда после наката нового апдейта рабочие проекты собираю rebuild all. Так, на всякий случай.

Добавлено 24.09.25, 14:30
Но тут всё проще: приложение собирается DEBUG, т.е. с отладочной версией RTL, а SQL был собран с релизной версией. По-хорошему надо где-то там взять отладочную SQL и в дебажные конфигурации своих проектов втыкать их.

[Majestio]

Цитата Majestio @ 21.09.25, 22:34

У меня получилось прописать дополнительно:
E:\Documents\3.Projects\C++\TestMySQL\mysql\lib64\vs14\libcrypto.lib
E:\Documents\3.Projects\C++\TestMySQL\mysql\lib64\vs14\libssl.lib
E:\Documents\3.Projects\C++\TestMySQL\mysql\lib64\vs14\mysqlcppconn.lib
E:\Documents\3.Projects\C++\TestMySQL\mysql\lib64\vs14\mysqlcppconn-static.lib
E:\Documents\3.Projects\C++\TestMySQL\mysql\lib64\vs14\mysqlcppconnx.lib
E:\Documents\3.Projects\C++\TestMySQL\mysql\lib64\vs14\mysqlcppconnx-static.lib

Вот тут я написал неправильно! Т.к. линкеру нужно под каждую конфигурацию указывать нужные либы по строгим правилам. Для статических - статические, для динамических - динамические. В дополнение - для релизных - релизные, для отладочных - отладочные. Все скопоп прописывать низя, скорее всего будут конфликты символов. Сорян!

Ах, да, еще ... где-то в "глубоких водах" GNU я вроде встречал такой термин как "гибридная" или "смешанная" линковка. Это когда часть либ линкуется статически, а часть динамически. ChatGPT утверждает, что и Мелкософтовские линкеры тоже владеют таким кунг-фу. Думаю, тоже стоит внимание обратить на эту шляпу. А то мало ли ...

Добавлено 25.09.25, 15:52

Цитата Qraizer @ 24.09.25, 14:26

Никогда не задумывался, что это действительно можно тоже назвать тулчейном, как принято в embedded.

Это пробел в знаниях. Несущественный, но всё же. В embedded это принято ровно на столько, на сколько принято в не embedded. Ибо термин toolchain (инструментальная цепочка) не привязан исключительно к embedded-системам, а имеет более общий смысл в разработке программного обеспечения. Тулчейн - это набор инструментов, используемых для создания исполняемых файлов, библиотек или других артефактов для определённой целевой платформы (таргета). Он включает в себя компиляторы, ассемблеры, компоновщики (линкеры), отладчики и другие утилиты, необходимые для сборки и, возможно, отладки кода.

[Majestio]

Кстати. С понятием 'toolchain' я столкнулся уже достаточно давно, в районе 2011 года, когда познакомился с проектом MXE. Но именно "кристальное" его воплощение я заметил в языке программирования Rust. Увы и ах, этот язык мне не зашел ввиду слишком узкого диапазона применений. К примеру, лепить GUI-морды сегодня на базе GTK2, когда уже есть GTK4 - считаю просто кощунственным. И тем не менее, заглянул в структуру каталогов когда-то установленного Раста, я наблюдаю:

X:\Tools\Rust\rust\toolchains
 ├─ stable-i686-pc-windows-gnu
 ├─ stable-i686-pc-windows-msvc
 ├─ stable-x86_64-pc-windows-gnu
 └─ stable-x86_64-pc-windows-msvc

Правда прекрасно?

[sharky72]

Цитата Qraizer @ 24.09.25, 14:26

Нет. Проект отлично собирается в DEBUG c релизной dll (pdb есть, функции в стеке посмотреть можно). И работает. В исходном vcxproj для debug конфигурации указана статическая конфигурация в переменных препроцессора для подключения mysqlconnector. Плюс указана неправильная либа для статической линковки, хотя сам проект собирается как /MDd (Multithreaded debug DLL). Короче там в конфигурации каша. Если все указать правильно то ошибок и эксепшнов не возникает. На 2022 студии.
Ну и настройки релизной конфигурации вобще отсутствует.

В любом случае можно скачать и отладочную версию. на dev.mysql.com/downloads/connector/cpp

Сообщение отредактировано: sharky72 - 25.09.25, 16:38

[DDim1000]

У меня возник вопрос: может я вообще делаю ни так? В общем, у меня есть задача: нужно подключиться к базе данных котора находиться на веб-хостинге. Дак, у меня правильная логика программы, или нет?

[Majestio]

Цитата DDim1000 @ 25.09.25, 17:57

Дак, у меня правильная логика программы, или нет?

Вроде бы и правильная но положа честную руку на горячее сердце - боюсь соврать. С Дазами Банных я обычно работал только средствами Qt. Предлагаю тебе воспользоваться "антисанкциями", выкачать и установить себе SQL-клиент Navicat. А вот уже в нём настрой нужный коннект, "увидь" таблицы, и только потом тестируй свою прогу. А то может случиться ситуация что просто проблемсы с БД. Не ленись - проверь!

[sharky72]

Цитата DDim1000 @ 25.09.25, 17:57

У меня возник вопрос: может я вообще делаю ни так? В общем, у меня есть задача: нужно подключиться к базе данных котора находиться на веб-хостинге. Дак, у меня правильная логика программы, или нет?

В смысле работы с Mysql? Ну да. Создали коннектор. Задали строку соединения и логин/пароль. Вызвали метод соединения, обработали исключение в случае ошибки.
Только я бы все таки не стал вызывать соединение из конструктора. Можно, но некрасиво из за того что там бросаются исключения в случае ошибок и isConnected() в данном случае не нужен

P.S. Я до сих пор использую dbForge Studio for MySql 9 (2020) пока она была бесплатной для некоммерческого использования

[Qraizer]

Цитата Majestio @ 25.09.25, 15:27

Это пробел в знаниях. Несущественный, но всё же. В embedded это принято ровно на столько, на сколько принято в не embedded.

Почему пробел. Я в курсе. Просто почему-то до этого не задумывался, что версии RTL можно так называть.

Цитата sharky72 @ 25.09.25, 16:13

Нет. Проект отлично собирается в DEBUG c релизной dll (pdb есть, функции в стеке посмотреть можно). И работает.

Не нет, а да. В проекте используются подставляемые функции (inline которые) с внешним связыванием (external linkage), и по Стандарту они обязаны (не ограничиваясь):

• иметь определение в каждой единице трансляции, в которых используются;
• в каждой единице трансляции, в которых используются, объявляться как подставляемые с внешним связыванием (с точностью до разрешения перегрузки);
• все такие определения должны быть выполнены одинаковой последовательностью токенов.

и неважно, как именно единицы трансляции линкуются в результирующее приложение, посредством статической линковки или динамической. Если конкретно у тебя смешение inline с внешним связыванием — обсуждаемый operator+() является non-static function template, что ставит его в один ряд с inline — работает, то лишь потому, что ожидаемое поведение является частным случаем неопределённого. Вот у нас с ТС, к примеру, не работает. И в отладчике легко видно, почему: в итоге где-то изнутри mysqlcppconn-10-vs14.dll управление попадает в sqlstring.h, конкретно в конструктор SQLString, и контент его параметра const std::string & other не совпадает с определением std::string в приложении, т.б. разные последовательности токенов на лицо. Почему так? Та потому, что линкеру приспичило обработать внешние имена в объектных файлах и библиотеках вот в каком-то таком порядке. И pdb тут совершенно ни причём, на линковку он никак не влияет. Как раз наоборот, создаётся в процессе линковки. Так-то он лишь предоставляет информацию для отладчика, и при нарушении ODR способен даже запутать, т.к. отладчик может в сырцах показывать совсем не то, что в исполняемом коде.

[sharky72]

Не буду спорить. В любом случае решение есть. На сайте есть дебажная версия dll и lib. Правильней будет использовать их в отладочном билде. Решается так же прописыванием путей к нужной либе.
По крайней мере я проверил на своем mysql. Код работает. Единственное пришлось еще доложить папку plugins

Добавлено 25.09.25, 19:56
Ну и чтобы не тащить все это в проект, и облегчить настройку подключения mysqlconnector автору рекомендую посмотреть в сторону vcpkg.

Сообщение отредактировано: sharky72 - 25.09.25, 19:56

[Majestio]

Цитата Qraizer @ 25.09.25, 18:48

Почему пробел. Я в курсе. Просто почему-то до этого не задумывался, что версии RTL можно так называть.

Ну как почему. Потому потому что до этого не задумывался. Варишься в твоих в своих мелкософтах и свету белого не видишь. А люди уже давно научились компилячить, более того - кросскомпилячть с использованием тулчейнов.

Цитата Qraizer @ 25.09.25, 18:48

что версии RTL можно так называть

Вот тут ты не прав - тулчейны, это не просто разные RTL, это полные разные инфраструктуры сопутствующих инструментариев.

И более того! Вспомни многообразие форматов исполняемых файлов - это связка "операционная система +архитектура". И не известно кто тут главный, а кто ведомый. Хотя "архитектура" конечно главнее по факту, т.к. она определяет его бинарный код, его внутренности. Но не факт. Тут сложно сказать, сложно что определить, что более первично - "сосуд" или его "содержимое"

[Qraizer]

Цитата Majestio @ 25.09.25, 22:09

Варишься в твоих в своих мелкософтах и свету белого не видишь.

Тебе что, назвать количество разных процессоров, с которыми работал и работаю? Из них только около половины используют GNU той или иной разновидности. И ОСей в них нет, там сплошной freestanding

[Majestio]

Цитата Qraizer @ 26.09.25, 02:35

Тебе что, назвать количество разных процессоров, с которыми работал и работаю? Из них только около половины используют GNU той или иной разновидности. И ОСей в них нет, там сплошной freestanding

Ага, вот ты и попался! Варишься в твоих в своих мелкософтах и эмбедах всяких, и свету белого не видишь!