Undefined reference when linking against custom library DLL
-
All of my work on Windows has been done with MSVC and not mingw, so I might be way off base... but it seems worth asking...
In the mingw environment, do windows DLL(s) still need to worry about
dllexport?(link to MSDN content regarding dllexport)
If so, then you need a special header for every library, like so:
#ifndef MYHEADER_GUARD_H #define MYHEADER_GUARD_H #include <QtCore/qglobal.h> // be sure to REPLACE "LIBSTYLES" with YOUR library name #if defined( LIBSTYLES_LIBRARY ) # define LIBSTYLES_EXPORT Q_DECL_EXPORT #else # define LIBSTYLES_EXPORT Q_DECL_IMPORT #endif #endif // MYHEADER_GUARD_HThen you have to annotate your classes, and also be sure to configure the preprocessor definition when you build
QSchematic.Actually... looking at your GitHub repo, I see that you added the
QSCHEMATIC_EXPORTyesterday. I'm digging through to see if maybe you missed a spot....@KH-219Design said in Undefined reference when linking against custom library DLL:
In the mingw environment, do windows DLL(s) still need to worry about dllexport?
It works without but it's nice if the library works with MSVC too ;)
@KH-219Design said in Undefined reference when linking against custom library DLL:
I see in your commit 830adbe97f07 that you added lines like #include "qschematic_export.h" but you did not commit a file named qschematic_export.h? Does CMake generate it somehow? (I use qmake on most things and have minimal CMake fluency.)
Yes that's correct. It gets generated by cmake's
generate_export_header()function. That part appears to work as expected.@KH-219Design said in Undefined reference when linking against custom library DLL:
Anyhow, I will make a general statement about similar linker errors I have encountered in the past:
That is certainly helpful information but unfortunately also things I checked before posting here. I also inspected the compiled DLL and that seemed fine on first glance. However, I'm not sure about the aforementioned signals.
In the meantime, I created a clean minimal cmake based application, added the QSchematic library via cmake's
FetchContent_Declare(), linked the DLL into the app viatarget_link_libraries()and the application linked and started fine.The difference between what I have shown in this post and that minimal application is that I'm building a DLL which gets loaded into a Qt application (not a Qt plugin - just a regular home-grown plugin that gets loaded into a Qt application using
QPluginLoader).Industrial process automation software: https://simulton.com
Embedded Graphics & GUI library: https://ugfx.io -
@KH-219Design said in Undefined reference when linking against custom library DLL:
In the mingw environment, do windows DLL(s) still need to worry about dllexport?
It works without but it's nice if the library works with MSVC too ;)
@KH-219Design said in Undefined reference when linking against custom library DLL:
I see in your commit 830adbe97f07 that you added lines like #include "qschematic_export.h" but you did not commit a file named qschematic_export.h? Does CMake generate it somehow? (I use qmake on most things and have minimal CMake fluency.)
Yes that's correct. It gets generated by cmake's
generate_export_header()function. That part appears to work as expected.@KH-219Design said in Undefined reference when linking against custom library DLL:
Anyhow, I will make a general statement about similar linker errors I have encountered in the past:
That is certainly helpful information but unfortunately also things I checked before posting here. I also inspected the compiled DLL and that seemed fine on first glance. However, I'm not sure about the aforementioned signals.
In the meantime, I created a clean minimal cmake based application, added the QSchematic library via cmake's
FetchContent_Declare(), linked the DLL into the app viatarget_link_libraries()and the application linked and started fine.The difference between what I have shown in this post and that minimal application is that I'm building a DLL which gets loaded into a Qt application (not a Qt plugin - just a regular home-grown plugin that gets loaded into a Qt application using
QPluginLoader).@Joel-Bodenmann said in Undefined reference when linking against custom library DLL:
It works without but it's nice if the library works with MSVC too ;)
Only if you don't export anything does mingw default to the *nix behaviour of exporting all the symbols. So either export all (which is what I recommend), or don't export anything.
@Joel-Bodenmann said in Undefined reference when linking against custom library DLL:
However, the issue remains:
It does look like the usual missing symbols. Make sure you're linking correctly against release/debug binary - on windows these are different libraries. Could you check if said symbols are really exported in the binary? I would imagine not ...
PS. I couldn't find your export header in the repository ... please don't tell me you're generating it on the fly ...
Read and abide by the Qt Code of Conduct
-
@Joel-Bodenmann said in Undefined reference when linking against custom library DLL:
It works without but it's nice if the library works with MSVC too ;)
Only if you don't export anything does mingw default to the *nix behaviour of exporting all the symbols. So either export all (which is what I recommend), or don't export anything.
@Joel-Bodenmann said in Undefined reference when linking against custom library DLL:
However, the issue remains:
It does look like the usual missing symbols. Make sure you're linking correctly against release/debug binary - on windows these are different libraries. Could you check if said symbols are really exported in the binary? I would imagine not ...
PS. I couldn't find your export header in the repository ... please don't tell me you're generating it on the fly ...
@kshegunov said in Undefined reference when linking against custom library DLL:
PS. I couldn't find your export header in the repository ... please don't tell me you're generating it on the fly ...
It's generated automatically by cmake in the build dir.
-
@Joel-Bodenmann said in Undefined reference when linking against custom library DLL:
It works without but it's nice if the library works with MSVC too ;)
Only if you don't export anything does mingw default to the *nix behaviour of exporting all the symbols. So either export all (which is what I recommend), or don't export anything.
@Joel-Bodenmann said in Undefined reference when linking against custom library DLL:
However, the issue remains:
It does look like the usual missing symbols. Make sure you're linking correctly against release/debug binary - on windows these are different libraries. Could you check if said symbols are really exported in the binary? I would imagine not ...
PS. I couldn't find your export header in the repository ... please don't tell me you're generating it on the fly ...
@kshegunov said in Undefined reference when linking against custom library DLL:
PS. I couldn't find your export header in the repository ... please don't tell me you're generating it on the fly ...
As @Christian-Ehrlicher mentioned this gets generated by cmake's
generate_export_header()function during the configuration stage.Your statement sounds like you'd have some wisdom/experience to share on this topic... ;-)
Industrial process automation software: https://simulton.com
Embedded Graphics & GUI library: https://ugfx.io -
Your cmake is wrong:
add_library(${TARGET_SHARED} SHARED) target_compile_definitions( ${TARGET_SHARED} PRIVATE qschematic_shared_EXPORTS # We are building this library! ) target_link_libraries( ${TARGET_SHARED} PUBLIC qschematic-objs ) --> set(CMAKE_AUTOMOC ON) set(CMAKE_AUTOUIC ON) set(CMAKE_AUTORCC ON) add_library(${TARGET_SHARED} SHARED ${SOURCES_PRIVATE}) target_link_libraries(${TARGET_SHARED} PUBLIC Qt5::Core Qt5::Gui Qt5::Widgets ${QSCHEMATIC_DEPENDENCY_GPDS_TARGET} ) target_include_directories( ${TARGET_SHARED} PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}> # For qschematic_export.h $<BUILD_INTERFACE:${CMAKE_CURRENT_LIST_DIR}/..> $<INSTALL_INTERFACE:..> )You can not simply add the same compiled object files for your static and dynamic lib since the sources for the dynamic lib need to be compiled with
qschematic_shared_EXPORTS.
You also do not need to define qschematic_shared_EXPORTS by your own - cmake defines it for you.btw: when you want your source to be portable avoid g++ extensions like binary literals (and, or not instead && - it took me ages to change all the places so it can be compiled with msvc.
Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
@kshegunov said in Undefined reference when linking against custom library DLL:
PS. I couldn't find your export header in the repository ... please don't tell me you're generating it on the fly ...
As @Christian-Ehrlicher mentioned this gets generated by cmake's
generate_export_header()function during the configuration stage.Your statement sounds like you'd have some wisdom/experience to share on this topic... ;-)
@Joel-Bodenmann said in Undefined reference when linking against custom library DLL:
As @Christian-Ehrlicher mentioned this gets generated by cmake's generate_export_header() function during the configuration stage.
... that's beautiful ...
Your statement sounds like you'd have some wisdom/experience to share on this topic... ;-)
Nah! Another time.
-
Your cmake is wrong:
add_library(${TARGET_SHARED} SHARED) target_compile_definitions( ${TARGET_SHARED} PRIVATE qschematic_shared_EXPORTS # We are building this library! ) target_link_libraries( ${TARGET_SHARED} PUBLIC qschematic-objs ) --> set(CMAKE_AUTOMOC ON) set(CMAKE_AUTOUIC ON) set(CMAKE_AUTORCC ON) add_library(${TARGET_SHARED} SHARED ${SOURCES_PRIVATE}) target_link_libraries(${TARGET_SHARED} PUBLIC Qt5::Core Qt5::Gui Qt5::Widgets ${QSCHEMATIC_DEPENDENCY_GPDS_TARGET} ) target_include_directories( ${TARGET_SHARED} PUBLIC $<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR}> # For qschematic_export.h $<BUILD_INTERFACE:${CMAKE_CURRENT_LIST_DIR}/..> $<INSTALL_INTERFACE:..> )You can not simply add the same compiled object files for your static and dynamic lib since the sources for the dynamic lib need to be compiled with
qschematic_shared_EXPORTS.
You also do not need to define qschematic_shared_EXPORTS by your own - cmake defines it for you.btw: when you want your source to be portable avoid g++ extensions like binary literals (and, or not instead && - it took me ages to change all the places so it can be compiled with msvc.
@Christian-Ehrlicher said in Undefined reference when linking against custom library DLL:
You can not simply add the same compiled object files for your static and dynamic lib since the sources for the dynamic lib need to be compiled with qschematic_shared_EXPORTS.
You also do not need to define qschematic_shared_EXPORTS by your own - cmake defines it for you.I see - that makes sense. I'm gonna change that!
@Christian-Ehrlicher said in Undefined reference when linking against custom library DLL:
btw: when you want your source to be portable avoid g++ extensions like binary literals (and, or not instead && - it took me ages to change all the places so it can be compiled with msvc.
As far as I can tell the
and,or,notand similar keywords are actually part of the C++ standard. It's just that MSVC doesn't have support for them enabled by default - am I wrong here?I'd appreciate any kind of patch you want to submit tho. Making this library as portable as possible is certainly something I'd like to achieve. So far I've used it only with GCC and Clang.
@kshegunov said in Undefined reference when linking against custom library DLL:
... that's beautiful ...
Given your other messages I'm actually not sure whether that's sarcasm or not...? :p
Industrial process automation software: https://simulton.com
Embedded Graphics & GUI library: https://ugfx.io -
@Joel-Bodenmann said in Undefined reference when linking against custom library DLL:
As far as I can tell the and, or, not and similar keywords are actually part of the C++ standard.
Yes (http://www.cplusplus.com/reference/ciso646/), but MSVC doesn't like them and it's not widely used. Also I find it very hard to read, esp. when you mix both versions in one line as you did :)
I can provide a patch for it if you want.I'm gonna change that!
I think all should compile then correctly. Tested it with your demo application.
-
@Christian-Ehrlicher said in Undefined reference when linking against custom library DLL:
You can not simply add the same compiled object files for your static and dynamic lib since the sources for the dynamic lib need to be compiled with qschematic_shared_EXPORTS.
You also do not need to define qschematic_shared_EXPORTS by your own - cmake defines it for you.I see - that makes sense. I'm gonna change that!
@Christian-Ehrlicher said in Undefined reference when linking against custom library DLL:
btw: when you want your source to be portable avoid g++ extensions like binary literals (and, or not instead && - it took me ages to change all the places so it can be compiled with msvc.
As far as I can tell the
and,or,notand similar keywords are actually part of the C++ standard. It's just that MSVC doesn't have support for them enabled by default - am I wrong here?I'd appreciate any kind of patch you want to submit tho. Making this library as portable as possible is certainly something I'd like to achieve. So far I've used it only with GCC and Clang.
@kshegunov said in Undefined reference when linking against custom library DLL:
... that's beautiful ...
Given your other messages I'm actually not sure whether that's sarcasm or not...? :p
@Joel-Bodenmann said in Undefined reference when linking against custom library DLL:
Given your other messages I'm actually not sure whether that's sarcasm or not...? :p
It is, but you should drop it, I don't want to butt heads with Christian again, I'm too old and frail for that.
-
@Christian-Ehrlicher I have fixed the cmake as per you guidance: No longer building the static and shared libraries from the object library but instead creating them separately. I created a function to setup the stuff common to all targets. Now I can successfully build my Qt5 app/plugin :)
Here's the change I made: https://github.com/simulton/QSchematic/commit/98af6cc914b3340be7f36e9c3a4c7f7057093f97
Now I just have to do that for the GPDS dependency as well.@Christian-Ehrlicher said in Undefined reference when linking against custom library DLL:
Also I find it very hard to read, esp. when you mix both versions in one line as you did :)
I fully agree regarding consistency. This library started off as a hobby project of mine many years ago with a lot less C++ experience on my side. I am currently in the progress of cleaning everything up - hence also this entire fuzz.
As usual: I am very open towards feedback & criticism - My only goal is to make this library become a ready-to-use solution for whoever sees fit in using it.@Christian-Ehrlicher said in Undefined reference when linking against custom library DLL:
I can provide a patch for it if you want.
Patches are certainly appreciated :)
