Qt shared library project exporting symbols that arent marked for export?
-
Shared Library Project Exporting ALL Symbols
I am unsure why this is happening, but I am assuming its some sort of automatic magic somewhere.
Question
What I'd like to know is this:
- Does Qt further process symbols to decide automatically if they should be exported? (Like looking at relationships to other project)
- Are there certain classes that always get exported in a Shared Lib Project (like QObject?)
- Do the symbols for classes get exported if they are used by another class, when defined under the same library?
- If the answer to any is yes, is there any setting to control this behavior?
For simplicity i've omitted guards, access levels etc.. Let us assume these classes inherit from QObject in the usual manner...
library.pro:----file a.h--- class EXPORTMACRO A() { A(); a(); } ----file a.cpp--- #include "c.h" A::A() { yeah i should be able to run this, fine...} ----file b.h--- class B() { B(); b(); } ----file b.cpp--- #include "b.h" B::B() { For some reason, I can run this...but why? I'm not marked for export or import? }
Its definitely using the library, if I take "mylib.so" away from the program's view, it will complain about missing the library when I try to run it, or complain about missing symbols if I try to recompile it in any form including just instancing the B() or just referencing the A() class.
So the question becomes, why is this happening? Is there some way to control that?
-
Shared Library Project Exporting ALL Symbols
I am unsure why this is happening, but I am assuming its some sort of automatic magic somewhere.
Question
What I'd like to know is this:
- Does Qt further process symbols to decide automatically if they should be exported? (Like looking at relationships to other project)
- Are there certain classes that always get exported in a Shared Lib Project (like QObject?)
- Do the symbols for classes get exported if they are used by another class, when defined under the same library?
- If the answer to any is yes, is there any setting to control this behavior?
For simplicity i've omitted guards, access levels etc.. Let us assume these classes inherit from QObject in the usual manner...
library.pro:----file a.h--- class EXPORTMACRO A() { A(); a(); } ----file a.cpp--- #include "c.h" A::A() { yeah i should be able to run this, fine...} ----file b.h--- class B() { B(); b(); } ----file b.cpp--- #include "b.h" B::B() { For some reason, I can run this...but why? I'm not marked for export or import? }
Its definitely using the library, if I take "mylib.so" away from the program's view, it will complain about missing the library when I try to run it, or complain about missing symbols if I try to recompile it in any form including just instancing the B() or just referencing the A() class.
So the question becomes, why is this happening? Is there some way to control that?
Hi,
read here:
I think you forgot
Q_DECL_IMPORT
/Q_DECL_EXPORT
-
Hi,
read here:
I think you forgot
Q_DECL_IMPORT
/Q_DECL_EXPORT
@Pl45m4 said in Qt shared library project exporting symbols that arent marked for export?:
I think you forgot Q_DECL_IMPORT / Q_DECL_EXPORT
I think OP knows this. We are to assume
EXPORTMACRO
onclass A
has the necessary and correctQ_DECL
s.class B
does not have these. You then have to read the question in that light. It is a question of howB
nonetheless seems as accessible asA
.I think Q_DECL_IMPORT / Q_DECL_EXPORT is about import/export into/from a library, not to do with internal references.
-
so i think i got it now, turns out Linux shared libraries export all symbols by default, requiring attributes to HIDE the symbols, rather than on windows where symbols are NOT exported by default, that became evident when I looked up Q_DECL_EXPORT and Q_DECL_IMPORT's Linux-specific settings and saw they bear same attribute unlike windows which just translates them to __dllimport and __dllexport. Thanks for the input all the same :3
-
Shared Library Project Exporting ALL Symbols
I am unsure why this is happening, but I am assuming its some sort of automatic magic somewhere.
Question
What I'd like to know is this:
- Does Qt further process symbols to decide automatically if they should be exported? (Like looking at relationships to other project)
- Are there certain classes that always get exported in a Shared Lib Project (like QObject?)
- Do the symbols for classes get exported if they are used by another class, when defined under the same library?
- If the answer to any is yes, is there any setting to control this behavior?
For simplicity i've omitted guards, access levels etc.. Let us assume these classes inherit from QObject in the usual manner...
library.pro:----file a.h--- class EXPORTMACRO A() { A(); a(); } ----file a.cpp--- #include "c.h" A::A() { yeah i should be able to run this, fine...} ----file b.h--- class B() { B(); b(); } ----file b.cpp--- #include "b.h" B::B() { For some reason, I can run this...but why? I'm not marked for export or import? }
Its definitely using the library, if I take "mylib.so" away from the program's view, it will complain about missing the library when I try to run it, or complain about missing symbols if I try to recompile it in any form including just instancing the B() or just referencing the A() class.
So the question becomes, why is this happening? Is there some way to control that?
@osirisgothra said in Qt shared library project exporting symbols that arent marked for export?:
For some reason, I can run this...but why? I'm not marked for export or import?
Where do you want to call
B()
? Within your library? Or from the program which where your lib is linked?Edit:
Ok you figured it out already. :)
-
just as a follow up Q_DECL_HIDDEN was what you would use to force it to hidden in such cases
Q_DECL_HIDDEN just does a attribute((visibility("hidden")))
while Q_DECL_EXPORT/IMPORT both attribute((visibility("default"))) which is what tipped me off... On that hunch I searched and quickly found a general cross-platform discussion about Linux's exhibitionist nature vs Windows "more reserved" nature when it comes to shared libraries and that confirmed it :3 I wonder why since qt is cross platform that its not mentioned in the qt documentation's Shared library intro? (or least I didn't notice anything about it there). -
O osirisgothra has marked this topic as solved on