windows dll install does not include lib file
-
QMake version 3.1
Qt version 5.9.7I have a series of libraries that build and then need to be installed into a central location for other libs and apps to access for their builds. The staticlib works fine in this respect since it is only the simple .lib (and maybe .pdb). However, with dll build seems to only install the .dll and not also the associated .lib needed for use with other builds that want to use it.
Is there a config item or flag to trigger this copy of the .lib to the target.path?
-
Hi,
Did you properly export your classes ?
-
-
Yes, all files are non-zero:
07/08/2022 05:17 PM 1,273,344 mylib.dll
07/08/2022 05:17 PM 14,243 mylib.exp
07/08/2022 05:17 PM 4,414,168 mylib.ilk
07/08/2022 05:17 PM 23,866 mylib.lib
07/08/2022 05:17 PM 5,320,704 mylib.pdband yes, using a header just as described for Q_DECL_EXPORT
so what should trigger the install to include the .lib file as well? Is it finding something in the code/header or having a .lib file generated during the build process? Is there an extra config item?
-
Can you show your .pro file ?
-
Ok, i think I have found the issue. You asking about .pro file had me examine it a little closer. I inherited the code that was working in linux and now trying to make it work as shared library in windows. At the top of project file was the following line:
CONFIG += plugin # avoid the version symlinksThis will generate the .so library and not all the .so.#,#.#,#.#.# versioning symbolic links, which seem to be ok in linux. This triggers a different outcome in windows, since I assume, it expects this to be only used as a plugin and thus only the dll is a required component.
I updated the line in the project file as follows and that seems to have done the trick:
!win32: CONFIG += plugin # avoid the version symlinks in non-windows buildSo a quick followup then. If the build produces the .dll but no .lib, then nothing was exported properly and thus the library cannot be linked with app? Seeing this in another library as part of the bigger project building in windows.
-
Ok, i think I have found the issue. You asking about .pro file had me examine it a little closer. I inherited the code that was working in linux and now trying to make it work as shared library in windows. At the top of project file was the following line:
CONFIG += plugin # avoid the version symlinksThis will generate the .so library and not all the .so.#,#.#,#.#.# versioning symbolic links, which seem to be ok in linux. This triggers a different outcome in windows, since I assume, it expects this to be only used as a plugin and thus only the dll is a required component.
I updated the line in the project file as follows and that seems to have done the trick:
!win32: CONFIG += plugin # avoid the version symlinks in non-windows buildSo a quick followup then. If the build produces the .dll but no .lib, then nothing was exported properly and thus the library cannot be linked with app? Seeing this in another library as part of the bigger project building in windows.
@mcarter said in windows dll install does not include lib file:
If the build produces the .dll but no .lib, then nothing was exported properly and thus the library cannot be linked with app
correct
