"archive member will be inaccessible".. but it is accessible!

Hi All!

I have a header managedobject.h containing among others this class template:

template< class tManagedObject >
class DeletedAtShutDown
{
typedef ManagedPointerAdapter<tManagedObject> mt_Adapter;
public:
DeletedAtShutDown();

protected:
virtual ~DeletedAtShutDown();

private:
mt_Adapter* m_pAdapter;
};

#include "managedobject.cpp"

this is part of managedobject.cpp with the implementation:

template< class tManagedObject >
DeletedAtShutDown<tManagedObject>::DeletedAtShutDown()
{
//...
}

template< class tManagedObject >
DeletedAtShutDown<tManagedObject>::~DeletedAtShutDown()
{
//...
}

This gets compiled into a static library, resulting in this warning:

warning LNK4221: no public symbols found; archive member will be inaccessible

however, when building an application with the library, it compiles fine, and I'm able to debug into managedobject.cpp.

Any ideas on how to solve this warning (not including "put the implementation in the header")

Thanks in advance!

Answer this question

"archive member will be inaccessible".. but it is accessible!

Rhodri Jenkins

einaros wrote:
Well, the warning is pretty straight forward. If you've got a translation unit in your library project with no public symbols (that is, no non-static symbols declared at file or namespace scope), nothing will be exported from it. This means that if your your library contains nothing but that one translation unit, linking the library from another project will serve no function. If the templated class definition is all you need, just include the header from the other project.

I do find it curious that you do a #include "managedobject.cpp", though. Why is this

thanks for the reply, I've kinda sorted it out now:
It's indeed logical the warning is raised, as there's nothing to export since the template class isn't used anywhere.

To answer your question: if I would not #include the cpp, there would be unresolved symbols when using the class in another project, since the linker would never find the implementation (because it's not exported, and it cannot be seen from within the other project). Normally one would use the export keyword, but afaik only Comeau supports that.

Now, putting

template class DeletedAtShutDown<int>;

within the cpp, that definition is exported, and the warning disappears.
But since I'm not likely to use an integer with DeletedAtShutDown, this fix just keeps the linker happy, and increases the size of the library, that's it, hence it's not really a fix.
The #include must still remain else DeletedAtShutDown<MyClass> would still be unresolved from another project's point of view..

nanocity
einaros wrote:

That's usually solved by providing the complete definition in the header.
Indeed, but that leads to circular include problems sometimes: as I'm using a lot of templates it's nearly impossible to use headers only.
Also I feel uncomfortable with putting more then 10 lines of source in a header, especially when that source can't be inlined anyway.
einaros wrote:

If I were you, I'd rather just ignore that warning. It's safe to do so, as long as you know why it's there in the first place.

I'll probably stick with that yes, after documenting it.

Case closed []-]

sidhuvirgoster

stinosky wrote:

To answer your question: if I would not #include the cpp, there would be unresolved symbols when using the class in another project, since the linker would never find the implementation

That's usually solved by providing the complete definition in the header.

stinosky wrote:

Now, putting

template class DeletedAtShutDown<int>;

within the cpp, that definition is exported, and the warning disappears.
But since I'm not likely to use an integer with DeletedAtShutDown, this fix just keeps the linker happy, and increases the size of the library, that's it, hence it's not really a fix.

If I were you, I'd rather just ignore that warning. It's safe to do so, as long as you know why it's there in the first place.

Steve1999

Well, the warning is pretty straight forward. If you've got a translation unit in your library project with no public symbols (that is, no non-static symbols declared at file or namespace scope), nothing will be exported from it. This means that if your your library contains nothing but that one translation unit, linking the library from another project will serve no function. If the templated class definition is all you need, just include the header from the other project.

I do find it curious that you do a #include "managedobject.cpp", though. Why is this
Ketchup06
This question is better asked in the General C++ forum. I'm unable to transfer your thread there.
itgold
ok sorry for that. I was quite overwhelmed by the huge amount of subforums upon entering the site for the first time, and took the first one that looked appealing.
Is there a way to move/delet the post myself
I guess a double post is a big no-no ;-]
codehelp
I think I have now transferred your thread to the right place
"archive member will be inaccessible".. but it is accessible!

Answer this question