LINK : fatal error LNK1104: cannot open file 'wxmsw31ud_stc.lib'

[AliKet]

Hi Ulrich, Why does wxSqlite3 depend on wxstc or maybe wxaui and the other irrelevent wxLibs ?

[utelle]

wxSQLite3 does not depend on wxstc or wxaui. The wxSQLite3 library itself does only depend on wxWidgets core and base libraries, the treeview sample additionally requires the adv library.

Which version of wxSQLite3 are you trying to build? Which compiler are you using?

For Visual C++ link dependencies are resolved automatically using the special setup.h residing in include/msvc/wx. Maybe you have a mismatch somewhere in your wxWidgets installation.

[AliKet]

Hi Ulrich, and think you for your quick respense

Indeed i have this USE_STC = 0 in build/msw/config.vc to exclude stc from build process but wxUSE_STC still defined as 1 in setup.h which leads to confusion when i try to build wxSqlite3 itself !!

Thank you again for your support and for the awesome library.

[utelle]

I'm pretty sure that the symbols USE_STC and wxUSE_STC should be kept in sync. So this is in fact a wxWidgets build issue. When using the configure build system this is automatically taken care of. However, for Windows based builds it seems to be the responsibility of the developer.

[patlkli]

I ran into a similiar problem today.

I wanted to do a static wxSQLite3 build against a static wxWidgets. I have multiple builds of wxWidgets in my lib directory there for different Visual Studio versions, which were built with COMPILER_PREFIX=vc{14,15,...}, so the library folders are named vc{14,15}[_x64_]_lib.

First of all, the "special" wx/setup.h in include/msvc can only determine the correct library directory (where the actual setup.h is), if wxCOMPILER_PREFIX and wxCFG were set before including it, so you'd have to specify it on the command line here. That would actually be possible using the settings from wx_{setup,local}.props, but it isn't done correctly right now.

Secondly and most importantly, the "special" wx/setup.h is pulling all wxWidgets components (which are not defined out with wx{NO,USE}_XXX) as dependencies into the resulting wxSQLite3 static library.

If you happen to use CMake for an application depending on wxSQLite3 (like I am), you will notice that the CMake find module for wxWidgets is actually explicitly linking the wx components with their absolute path and not by giving it the library directory. Now I'm getting lots of "no such file or directory" errors for wx components that neither my application nor wxSQLite3 actually needs, because they are linked into wxSQLite3 explicitly.

I actually don't understand why you would need the special setup.h, because wx_setup.props has all the information to find the actual setup.h file which is in lib/vc{...}_lib. In fact you are even specifying the include directory for the actual setup.h in the include path. It works perfectly if I throw out the include/msvc part.

[utelle]

The route I followed on generating the Visual C++ build files is described in the last section of the file docs/msw/install.txt of the wxWidgets distribution. There it reads:

Microsoft Visual C++ users can simplify the linker setup by prepending "$(WXWIN)\include\msvc" to the include path (it must come before the "$(WXWIN)\include" part!) and omitting the last step: the required libraries will be linked in automatically using the "#pragma comment(lib)" feature of this compiler.

I started to use this feature in February 2017 already, but @AliKet and you are the first reporting linker problems. So, I assume for most developers the build files work out of the box ... or they were reluctant to report issues.

For @AliKet the reason for the issue was definitely a misconfiguration of his wxWidgets installation. Your case is different, since you have multiple builds of wxWidgets which are distinguished by their compiler prefixes.

Since I use the default compiler prefix myself and distinguish between different wxWidgets builds by different means, I have to admit that I wasn't aware of the fact that the compiler version and the configuration (wxCFG) have to be defined as precompiler symbols to make the special setup.h file work as expected.

The file wx_setup.props coming with wxSQLite3 allows to define the compiler prefix and the configuration. However, the missing part is to forward these definitions to the precompiler through the symbols wxMSVC_VERSION and wxCFG resp. I will adjust the build files accordingly for the next release.

If the wxWidgets library path is set up correctly, pulling in all wxWidgets libraries should not impose a problem. If CMake does not properly set up the wxWidgets library path(s) for the linker, this seems to be a deficiency of CMake. However, I can't comment on CMake further, since I don't use it myself.

Removing include\msvc from the include header search path will work only for building the static library, but not for building the DLL, since for the static library the actual link step takes only place when the final executable or DLL is linked (for which you then have to explicitly list all dependencies).

[patlkli]

I agree, that the end result (hopefully) won't differ much if the linker of my final executable pulls in all wxWidgets components, because in the end, it should notice unused symbols and just strip them away.

However, the fact that you actually can't link wxSQLite3 without the linker having access to those components, which are neither required for wxSQLite3 or the application, is inconvenient at the very least. It imposes unnecessary limits and requirements on users.

[utelle]

Sorry, I'm not sure I fully understand the problem. The linker definitely has to have access to the link libraries of the wxWidgets build in question. And that wxWidgets build has all libraries that are pulled in through the special setup.h file, of course. And the Visual C++ linker is smart enough to include only required objects from those libraries.

In the wxWidgets documentation it reads

Microsoft Visual C++ users may use the special wx/setup.h file for this compiler in include/msvc subdirectory. This file implicitly links in all the wxWidgets libraries using MSVC-specific pragmas which usually is much more convenient than manually specifying the libraries list in all of the project configurations.

So, obviously the wxWidgets developers have a slightly different opinion of what is convenient.

If the build specific setup.h file was properly set up, then using the special setup.h file should work flawlessly without producing any linker errors.

Yes, the wxSQLite3 build files currently have an issue, if the developer made use of multiple wxWidgets builds using different compiler prefixes for the libraries. However, as I already wrote I will try to fix this for the next release.

[utelle]

I adjusted the property file wx_setup.props in the build directory. If you set/overwrite the value for wxCompilerPrefix and set the value for wxMsvcVersion so that they match your wxWidgets installation, the special setup.h file for Visual C++ should determine the library names and paths correctly.

Please give it a try and let me know whether this solves your issue. Thanks in advance.

[patlkli]

It does in fact solve the issue of not being able to compile wxSQLite3 at all.

However, I would like to address the other issue again. Please bear with me.

I know there are two ways of linking in wxWidgets:

• provide appropriate preprocessor defines and library search path and then just include wx/setup.h from include/msvc in your code
• provide the libraries you want to link in yourself

The first one has one actual benefit:

You don't have to explicitly specify the name of the wx library files, which is a bit of a pain because they include variable parts of their own. However, all except the wxSHORT_VERSION_STRING have to be given as defines to the special wx/setup.h anyway, so by adding that to wx_setup.props the solution files could actually assemble the library names itself.

But the special wx/setup.h has some flaws too, which are especially noticable when doing a static library build:

It forces the linker to actually pull in all the wx component libraries and even though it won't affect the resulting executable does hurt compile times quite a bit. For a shared library build, that doesn't affect your users directly, because the resulting wxSQLite3 DLLs won't depend on the unused wx components, because they were already processed by the linker which discarded them. For a static library build, wxSQLite3 actually passes the additional unused dependencies on to the final executable of the user, which then forces the user to actually link in everything.

Another thing is, that, while you don't have to specify the libary names explicitly, you still have to provide the full library search path, because the special setup.h can only assemble the actual wx/setup.h include path and tell the linker to link some wx<...>.lib library, but it doesn't actually set the library search path.

In the end, you're stuck with having to assemble paths anyway. So why not remove the additional imposed dependencies for your users by adding the wx version to the props file and assembling the library names by yourself?

If you want, I can do the necessary changes, test them for the different configurations and send you a PR. You can still reject it then, if you don't want them, but I will probably have to keep them locally, because I'm stuck with using CMake for my project and it's much easier for me to change the build of wxSQLite3 than to change the FindwxWidgets.cmake module of CMake and make it pull in wxWidgets differently.

[utelle]

I know there are two ways of linking in wxWidgets:

• provide appropriate preprocessor defines and library search path and then just include wx/setup.h from include/msvc in your code

After inspecting the special setup.h file again in more detail it seems to be beneficial not only for shared builds but also for static builds, since all system library dependencies are also pulled in. And this spares the developer to add indirect library dependencies to his own build files.

• provide the libraries you want to link in yourself

My wxWidgets components used this approach in the past. This was done by adding the required link library names and separately the link library path. However, this approach requires to add all indirect library dependencies to projects using the components - rather inconvenient. And that's why I switched to the former approach.

The problem with the FindwxWidgets.cmake module seems to be that it doesn't make use of the option to define additional link library search paths. Instead, it produces a list of absolute library paths. However, this seems to be the general approach of CMake (at least under Windows). This is what I would call flawed.

It forces the linker to actually pull in all the wx component libraries and even though it won't affect the resulting executable does hurt compile times quite a bit.

Hm, it shouldn't increase compile times. However, most probably it will slightly increase link times. But is the difference really significant? Have you measured it? At least in my own projects I didn't experience a big effect.

For a static library build, wxSQLite3 actually passes the additional unused dependencies on to the final executable of the user, which then forces the user to actually link in everything.

The user??? I'd say the linker ... and if the build file is set up properly (that is, using linker search paths), this would happen transparently.

Another thing is, that, while you don't have to specify the libary names explicitly, you still have to provide the full library search path, because the special setup.h can only assemble the actual wx/setup.h include path and tell the linker to link some wx<...>.lib library, but it doesn't actually set the library search path.

Of course, the special setup.h file can't do anything about the linker search path, since it is used at compile time, not at link time.

However, setting up linker search paths should be done by the tools used to generate the build files. In your case CMake. In my case premake5 (and bakefile in the past).

CMake resp the FindwxWidgets.cmake module is to blame, if linker search paths are not used under Windows - a really weird decision, since linker search paths are common practice and in use for ages on all platforms.

So why not remove the additional imposed dependencies for your users by adding the wx version to the props file and assembling the library names by yourself?

This was the approach for Visual C++ in the past ... and still is for GNUMake. The premake5 script handles this.

If you want, I can do the necessary changes, test them for the different configurations and send you a PR.

I'm always willing to accept assistance, contributions etc. However, in this particular case it would simply mean to revert the premake5 script to use the approach of the past to generate build files with explicit library dependencies for Visual C++ (forcing the developer to add all indirect library dependencies to his own projects himself).

If a majority of the developers using wxSQLite3 would prefer this approach, I would certainly consider this step.

I'm stuck with using CMake for my project and it's much easier for me to change the build of wxSQLite3 than to change the FindwxWidgets.cmake module of CMake and make it pull in wxWidgets differently.

Maybe adding CMake support to wxSQLite3 would then be the best option. However, I'm not going to implement and test it myself, since I do not use CMake and don't intend to in the future, since I'm quite happy with premake5 for my own projects.