dll using static const char*

koahnig

@kshegunov
Sorry, too deep in thoughts.

No, it does not fix the problem.

kshegunov

@koahnig
Hello,
The plot thickens. I think (don't hold me to it, as I haven't been actively developing on Win for years) the static variable should be visible ... can you get a symbol dump from the dll and see if it was properly exported?
As a side note you could also try with a global variable (not scoped in a class, as in my first post) just to check everything is okay with that at least?

Kind regards.

koahnig

@kshegunov

the symbol dump of dependency walker lists the entry. So it should be exported.
The error comes with the initialization. I got a whole list. If I am marking the one listed, the next one will pop up as the source of error.

I am gong to try the global version of your first suggestion. If it works, I am not loosing anything.

kshegunov

@koahnig said:

The error comes with the initialization.

What initialization? There's no initialization that's connected to linking to my knowledge. And for linking to occur the symbol must only be found by it's fully qualified (and decorated) name, nothing more.

koahnig

@kshegunov
with this statement

const char * const MyClass::myStaticVar = "Some string";

I have a list of these member initializations. When I comment out the first one, the next becomes the problem.
However, dependency walker shows the entry with and without the member initializations.

Not sure yet, if there is somewhere an include without import and export macro. It is a bit strange.

kshegunov

@koahnig
Okay, wait a minute!
You can't have a binary generated if the linker doesn't run properly. So this:

const char * const MyClass::myStaticVar = "Some string";

causing a linker error would mean your dll is not linked, how does dependency walker report symbols then? Have I missed something here? Do you mind putting the exact lines from the header (with wrapper class name, inheritance etc) and source for one of your static variables? And also please show the portion of your .pro dealing with linkage, preprocessor macros and how you define the export macro itself. This would really help things along.

koahnig

@kshegunov

I should better make a condensed case of it then. You are right, possibly I messed up things somewhere there. I thought I lined it up properly.

koahnig

@kshegunov said:

Okay, wait a minute!
You can't have a binary generated if the linker doesn't run properly. So this:

const char * const MyClass::myStaticVar = "Some string";
causing a linker error would mean your dll is not linked, how does dependency walker report symbols then?
I have used the dependency walker with dll. You are right since the link step does give an error I am getting no exe.

I have tried to get a reduced version showing the problem. But the reduced version can compile and link and run. Therefore, I have to check my complex setup for a flaw. When starting the discussion I thought I am trying to do something which is not possible at all.

Many thanks for your sparring support, it is appreciated.

kshegunov

@koahnig said:

I have used the dependency walker with dll. You are right since the link step does give an error I am getting no exe.

But then, the initialization wouldn't be in the exe would it? .. as the variable is declared in the dll (and the dll source shouldn't be at all involved with said exe). :)

When starting the discussion I thought I am trying to do something which is not possible at all.

Not at all, it's quite commonly done, albeit I prefer in most cases to have a function that returns the relevant object/variable (not really applicable in your case, though).

Many thanks for your sparring support, it is appreciated.

No problem! I enjoy a good mystery. ;)
Cheers!

koahnig

@kshegunov said:

But then, the initialization wouldn't be in the exe would it? .. as the variable is declared in the dll (and the dll source shouldn't be at all involved with said exe). :)

No. The whole code of class and therefore its member initialization shall be part of a dll. That is the reason why I was checking the particular dll.

However, within the linkage of the exe suddenly the problem pops up.

kshegunov

@koahnig said:

No. The whole code of class and therefore its member initialization shall be part of a dll. That is the reason why I was checking the particular dll.

This means you just can't get a linker error in the line where the var is initialized, or you won't get a dll.
As for the exe that links the dll it should be oblivious to the statics initialization and I see no way how code that's internal to dll could cause a linking error in the exe. What I mean is this:

dll header:

class EXPORT_MACRO MyClass
{
public:
    static const char * const myStaticVar;
}

dll source

const char * const MyClass::myStaticVar = "Some string";

So the exe can't actually see MyClass::myStaticVar's initialization (code snippet 2); it can't have anything to do with that. This is a static initialization that's done by the loader immediately after the dll is mapped in memory. The executable has no bearing or any control over it. I hope I explained it well enough.

Kind regards.

koahnig

@kshegunov

Thanks for your patience and continued support.

I have found the problem. It was caused right between keyboard and chair ;)

As shown in one of my early responses the error respectively the warning, which was in this case more important.

@koahnig said:

Here is the error message

warning: 'KlaSlim::__ION_NONE' redeclared without dllimport attribute: previous dllimport ignored [-Wattributes]
error: definition of static data member 'KlaSlim::__ION_NONE' of dllimport'd class

What puzzled me was the reference redeclared without dllimport. I have the typical mechanism as suggested by Qt dll template for export and import. I have added another wrap around it making it usuable also when I do not like to have a dll at all.

After your feedback indicated what I am doing is the right way, I had focused on why is the stuff redeclared without dllimport. However, I could not a problem here. Actually all is fine there with the includes and they have always the import or the export declaration. Unfortunately implementation files slipped into the compilation of the application.

The warning text is misleading though, but it was actually showing the cause, duplicated declarations or better duplicated implementations.

kshegunov

@koahnig said:

Thanks for your patience and continued support. I have found the problem.

That's great. I'm glad I was able to contribute. :)

Unfortunately implementation files slipped into the compilation of the application.

Ah, sneaky .cpps :)

The warning text is misleading though, but it was actually showing the cause, duplicated declarations or better duplicated implementations.

Sadly that's always the case with the linker. A linker is dumb as a shoe, it doesn't have any context or semantics to the code, it just reorders symbols and puts addresses, that's why linker error are so cryptic. :)

I myself get into a hateful depression when I get the notorious "undefined vtable for ..." :D

In any case, I'm glad it worked out.
Cheers!