Mac, Static lib, Dynamic lib Lost signals!

SGaist

Try again using a dynamic common library.

Dariusz

Hey !

@SGaist I think I finally found the issue! It seems to be to do with https://forum.qt.io/topic/102783/qobject-connect-signal-not-found-in-dll-with-pointer-to-member-function/3 and mainly > See the Creating Shared Libraries chapter in Qt's documentation.

I'm gonna dig in and see how I could fix that.

I just wonder how, I have a cmake project which esentially

createLibrary()
createTestExe()
linkLibraryToTestExe()

And if I understand the post & docs... I have to do something like this

setFlagExport()
createLibrary()
setFlagImport()
createTestExe()
linkLibraryToTestExe()

But I never did that, so I wonder. Gonna test it out soon!

When it comes to annotating those export/import... do I only annotate class or also function/signal/slot?

TIA

SGaist

Annotate what you want to export. Usually the whole classe.

Dariusz

@SGaist said in Mac, Static lib, Dynamic lib Lost signals!:

Annotate what you want to export. Usually the whole classe.

Thanks!

I'm also failing with it... In my head I Have to define a variable in cmake, that then I read in .h and configure macro properly for export/import, but when I run this >

    add_definitions(-D_BUILD_TYPE=\"library\")
    add_library(${exename} "${_libraryMode}" "${_librarySource}")
    add_definitions(-D_BUILD_TYPE=\"app\")

When I run test app, the macro value is library, where as it should be app I think... ?
How do I eee... make it tick ?
Or am I looking at it wrong?

I have 1 project that creates library & includes it in test exe app for testing, I take test exe app should have DLLIMPORT where as library needs DLLEXPORT... How do I bit this thing? o.o

SGaist

Did you already read the dedicated chapter in Qt's documentation ?

Dariusz

Yeah thats what I'm trying to follow. But I'm using CMake not qmake. I also don't know how to "undefined" it
DEFINES += MYSHAREDLIB_LIBRARY it in CMake, I tried remove_definitions() but that did not work.

I also wonder if I have to do it on mac? Windows works fine, its mac that is broken.

Say my cmake is something like:

add_definitions(-D_BUILD_TYPE=\"library\")
add_library(libraryTest SHARED libA.cpp libA.h)
remove_definitions(-D_BUILD_TYPE)
add_executable(testLib test_main.cpp)
target_link_libraries(testLib libraryTest)

When I do

int main(){
auto val = _BUILD_TYPE;
std::cout<<val<<std::endl;
return 1;
}

In my testLib, it still prints library. Or is this some kind of false positive? I'm trying to wrap my head around it all.

Dariusz

Uuu I might be able to do it using

https://cmake.org/cmake/help/latest/command/target_compile_definitions.html

target_compile_definitions(${exename} PRIVATE  DBUILD_TYPE=\"library\")

Dariusz

Hey
@SGaist sadly no luck.
I added target_compile_definitions private/public. & added macro to the 2 classes that I try to signal/slot link. Rebuild all, hes still failing to find the files. Here is structure of the app

libraryA = static
libraryB = static
pluginA = SHARED
exeA = link libraryA & libraryB 
exeA.runtime. include plugins from folders, pluginA. 
pluginA creates object from libraryB = QObject::connect: signal not found in ...

I'm loss. Windows works just fine, Mac M1 ARM has a bad time. Should I somehow... configure something for it to work on ARM ?

Im making my signals slots like this :

    Q_SIGNALS:
        void sHandleAddGroup();
        void sHandleAddCommit();
    public Q_SLOTS:
        void handleAddCommit();

Is any of it due to ARM arch ? o.o

Dariusz

Ok so I found a work around. Its nasty...

        //connect(mMainWidgetPtr, &icVCManagerGUI::sHandleAddCommit, this, &icVCManager::handleAddCommit);

To

        connect(mMainWidgetPtr, SIGNAL(sHandleAddCommit()), this, SLOT(handleAddCommit()));

Same errors as bois here>
https://forum.qt.io/topic/75801/signal-not-found-error-solved-by-using-old-connect-sythax-why/3
https://stackoverflow.com/questions/61879664/qobjectconnect-not-working-signal-not-found-with-function-syntax

I'll still dig at it as I don't like these old macros, but at least they work! whhh

SGaist

Libraries that are shared between plugins and executable shall be shared and not static. Otherwise you will end up with multiple definition of the static meta object of your QObject based classes which is not good.