How to check plugins for unique class names?
-
Hello, developers.
Due to recent Qt changes forms with same names can conflict. See https://bugreports.qt.io/browse/QTBUG-54354. According to Qt developers this is not a bug. So, I need solution to check all plugins of my application. Which tool should I use for this task? Also, It would be good to provide this tool for third-party plugin developers. -
@trialuser
why do you expect a magical tool which solves your issues when the bug report already says that it's not possible?
There are problems in the programming world which are only solvable when every developer follows some guidelines for clean design.E.g. you can make sure that your class names are always starting with your (companies) initials. When a developer isn't willing to follow such rules it's the developers responsibility to fix it or to live with the fact that his software isn't usable by everyone.
Just my opinion.
-
Unfortunately, I can not find any official guidelines about class naming inside Qt plugins. Also, I don't know why Qt plugins with same form names works fine in Qt 5.5 and lower. So, I'll be glad, if you give me information about recent changes which causes this problem. I tell "Qt plugins" because other plugins (pure c++ and dlopen) have not this problem.
-
@trialuser
did you read the comments on the bug page?Also there is no such guideline for Qt plugins. A possible convention could be your or your companies companies initials, followed by the plugin-type and the name.
E.g. QxxImageFormatSomenewformatPlugin
Who knows, maybe they will fix it in the end anyway.
-
Thank you. Recently I found another solution. This problem was resolved by recompiling all plugins with -fvisibility=hidden. Now my application works fine, but I don't know is this correct. Should I recommend other developers to add CONFIG += HIDE_SYMBOLS to .pro files instead of class renaming?
-
@trialuser
Hi,
This is a typical Linux issue and will not be present on win (except for a special case with mingw). By default on Linux symbols are exported, while Windows requires a specific set of compiler directives (the infamous__declspec(dllexport)and__declspec(dllimport)). As a Qt plugin is no different ABI-wise from a regular dynamic library, then yes, Thiago is absolutely correct that the problem is with your code.In the usual case the library's symbols are resolved by the loader, so such symbol conflicts are removed at link-time. In the case of plugins the symbol resolution is at runtime, so the errors are obvious much later (when the app is already running). This is neither a problem with Qt, the Qt's version, nor with the compiler.
What you can do is to require from your plugin developers to put their classes in their own namespaces and/or prefix the classes by some "unique" means.
Another thing is to "hide" the unnecessarily exported symbols - you can use
Q_DECL_HIDDENfor that (much likeQ_DECL_EXPORTis used).If you're talking about
uicgenerated classes (widget forms), then you're out of luck asuiccares not about the export of symbols and will not put the appropriate macros to hide the form classes (thus they get exported). In this case you can enforce the symbols to not be exported with-fvisibility=hidden.Kind regards.
