[mysql-connector-cpp[jdbc]] 64-windows-static

[jfnaugusto]

Installing the mysql-connector-cpp[jdbc] will create the output library, not on the root "..\installed\x64-windows-static\lib" but under a subfolder. Also it will label the .lib as mysqlcppconn8-static-mt-mt.lib instead of the usual mysqlcppconn-static.lib (jdbc legacy). This means that when trying to link you will get errors, to fix the copy of the .lib to the root lib folder must be done manually.

• OS: w11
• Compiler: vs2019/22

Steps to reproduce the behavior: vcpkg install mysql-connector-cpp[jdbc]:x64-windows-static

Regards.

[JonLiu1993]

@jfnaugusto, Thanks for posting this issue, Regarding your first question, you think that the lib location exported by mysql-connector-cpp[jdbc] after installation is not under "..\installed\x64-windows-static\lib" but in a subdirectory? However, after installation, I found that it is indeed under "..\installed\x64-windows-static\lib"

[jfnaugusto]

Hi, That lib is for the mysql-connector-cpp:x64-windows-static, and not for the mysql-connector-cpp[jdbc]:x64-windows-static (legacy one). The later one get's installed in the vs14 folder. That's also a reason why I think they should keep the "original" names to avoid this type of confusion. mysqlcppconn8-static-mt.lib -> mysqlcppconn8-static.lib mysqlcppconn8-static-mt-mt.lib -> mysqlcppconn-static.lib

Thanks.

[dudantas]

I am experiencing the same issue, but it only occurs with the static library. Is there any prediction or timeline for a fix?

[dg0yt]

I guess port maintenance wasn't careful enough with regard to the jdbc feature.

• The jdbc feature doesn't use the same lib name patching as the main lib.
• A serious problem for vcpkg: The connector-jdbc lib/target is created as a convenience lib via

  merge_libraries(connector-jdbc jdbc)

  with

  # merge_libraries()
  #   Merge several static libraries into single static or shared library.
  #   Includes all transitive dependencies of the libraries being merged.

  This duplicates at least the main lib symbols. The resulting redundancy is not desired - at least not for files which go directly to /lib. So for the jdbc feature in vcpkg, the connector-jdbc lib must be either created without merging, or the jdbc-enabled lib should replace the original lib, or the jdbc-enabled lib has to be put into subdir (lib/manual-link).

[dudantas]

I'm currently working with CMake in Visual Studio (MySQL), and my setup is fully updated, including Vcpkg in manifest mode. However, I consistently encounter a specific error when attempting to build the static version of my project. The dynamic build, on the other hand, proceeds without any issues. Could this be related to how the static libraries are configured or a particular dependency that behaves differently in static context?

[dg0yt]

Could this be related to how the static libraries are configured or a particular dependency that behaves differently in static context?

YES.

Some things are generally different with static library linkage:

• There are transitive link lib requirements (unless using large "convenience libs"))
• On Windows, package often different lib names due to conflict between static lib and import lib.

In vcpkg, we also see a inconsistent quality of ports and patches: some errors are not visible until libraries are actually used (missing link libs, wrong runtime lib), so they may go unnoticed by CI and maintainers.

[dudantas]

It seems to be linked to this issue as well? #37407

[mkdev-jaugusto]

I have no issues with the building of the jdbc static library, the only issue is that you have to manually copy the .lib to the root, to prevent linking errors.

The 37407 fixed that for the non jdbc lib, nevertheless I think that the libs should keep their orignal names.

mysqlcppconn8-static-mt.lib -> mysqlcppconn8-static.lib mysqlcppconn8-static-mt-mt.lib -> mysqlcppconn-static.lib

Also imo there is no need to add the runtime to the name of the .libs (mt, etc.), since the triplets already creates folders for different runtimes.

It seems to be linked to this issue as well? #37407

[dg0yt]

the only issue is that you have to manually copy the .lib to the root, to prevent linking errors.

This issue should not exist, and it is a result of how this port builds libs. It needs reasonable modifications. Basically, there is no need to have two libs which are mostly identical. If the user asks for jdbc, the lib without jdbc should be replaced IMO.

Naming should be reviewed, too. -mt comes from upstream IIUC, and vcpkg mostly follows upstream. Except for harmonizing static and shared. https://learn.microsoft.com/en-us/vcpkg/contributing/maintainer-guide#do-not-rename-binaries-outside-the-names-given-by-upstream