Undefined reference when linking against custom library DLL

KH-219Design

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_H

Then 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_EXPORT yesterday. I'm digging through to see if maybe you missed a spot....

KH-219Design

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.)

Anyhow, I will make a general statement about similar linker errors I have encountered in the past:

If the symbols are missing (a.k.a. undefined) when you compile the library that should contain those very symbols, then one possibility is that your preprocessor IMPORT_EXPORT macro is getting set as dllimport during that build when it should be set to dllexport
If the symbols are missing when compiling other "user code" that depends on the library with the symbols, then (at a minimum) two possibilities exist: (a) the depended-upon library failed to tag its classes/functions with either dllimport or dllexport (meaning you failed to tag them at all when compiling that DLL), or (b) the preprocessor and header situation is such that dllexport is being applied even by this dependent "user code", whereas in this case it needs to be dllimport-ing the symbols from the depended-upon library.

Joel Bodenmann

@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 via target_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).

kshegunov

@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 ...

Christian Ehrlicher

@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

@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... ;-)

Christian Ehrlicher

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.

kshegunov

@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.

Joel Bodenmann

@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, not and 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

Christian Ehrlicher

@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.

kshegunov

@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.

Joel Bodenmann

@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 :)