MantisBT
Mantis Bug Tracker Workflow

View Revisions: Issue #31124 All Revisions ] Back to Issue ]
Summary 0031124: Configuration - linker errors when building with CLang on Windows
Revision 2019-11-01 23:47 by abv
Description This issue is to document strange linker errors that appear when OCCT is built with CLang on Windows (toolset Clang-CL in Visual Studio 2019). It looks to be a compiler bug.

The problem appears for classes that:

- Have virtual functions not declared as Standard_EXPORT (usually private or protected)
- Have non-trivial inline destructor (i.e. have some fields with destructors but do not have explicitly defined destrucror, or have it defined inline)
- Have out-of-line constructor (if not, the linker error is explainable)

The simplest example consists of DLL defining class CLangLinkError:

CLangLinkError.hxx:

~~~~
#include <Standard_Transient.hxx>

class CLangLinkError
{
public:

  Standard_EXPORT CLangLinkError();

  virtual void f();

  Handle(Standard_Transient) myField; // any field with destructor
};
~~~~

CLangLinkError.cxx:

~~~~
#include <CLangLinkError.hxx>

CLangLinkError::CLangLinkError() { }
void CLangLinkError::f() { }
~~~~

... and another DLL or executable using that class:

~~~~
#include <CLangLinkError.hxx>
...
CLangLinkError anObj; // causes linker error
~~~~

Linker error looks as follows:

~~~~
2>lld-link : error : undefined symbol: "protected: virtual void __cdecl CLangLinkError::f(void)" (?f@CLangLinkError@@UEAAXXZ)
2>>>> referenced by ....\Test.obj:("const CLangLinkError::`vftable'" (??_7CLangLinkError@@6B@))
~~~~

If the object is allocated dynamically (with operator new), the problem does not reproduce, even if the object is explicitly delted by 'delete'.

If out-of-line destructor is defined for the class CLangLinkError (exported from main DLL), or the field is removed, the problem is not reproduced.

Logically there is no need for compiler to generate vtbl for that class, it should be only generated in the constructor that is defined in main DLL. Hence, the issue looks like a bug in CLang.
Revision 2019-11-01 23:46 by abv
Description This issue is to document strange linker errors that appear when OCCT is built with CLang on Windows (toolset Clang-CL in Visual Studio 2019). It looks to be a compiler bug.

The problem appears for classes that:

- Have virtual functions not declared as Standard_EXPORT (usually private or protected)
- Have non-trivial inline destructor (i.e. have some fields with destructors but do not have explicitly defined destrucror, or have it defined inline)
- Have out-of-line constructor (if not, the linker error is explainable)

The simplest example consists of DLL defining class CLangLinkError:

CLangLinkError.hxx:

~~~~
#include <Standard_Transient.hxx>

class CLangLinkError
{
public:

  Standard_EXPORT CLangLinkError();

  virtual void f();

  Handle(Standard_Transient) myField; // any field with destructor
};
~~~~

CLangLinkError.cxx:

~~~~
#include <CLangLinkError.hxx>

CLangLinkError::CLangLinkError() { }
void CLangLinkError::f() { }
~~~~

... and another DLL or executable using that class:

~~~~
#include <CLangLinkError.hxx>
...
CLangLinkError anObj; // causes linker error
~~~~

Linker error looks as follows:

~~~~
2>lld-link : error : undefined symbol: "protected: virtual void __cdecl CLangLinkError::f(void)" (?f@RWC@@MEAAXXZ)
2>>>> referenced by ....\Test.obj:("const CLangLinkError::`vftable'" (??_7CLangLinkError@@6B@))
~~~~

If the object is allocated dynamically (with operator new), the problem does not reproduce, even if the object is explicitly delted by 'delete'.

If out-of-line destructor is defined for the class CLangLinkError (exported from main DLL), or the field is removed, the problem is not reproduced.

Logically there is no need for compiler to generate vtbl for that class, it should be only generated in the constructor that is defined in main DLL. Hence, the issue looks like a bug in CLang.
Revision 2019-11-01 23:45 by abv
Description This issue is to document strange linker errors that appear when OCCT is built with CLang on Windows (toolset Clang-CL in Visual Studio 2019). It looks to be a compiler bug.

The problem appears for classes that:

- Have virtual functions not declared as Standard_EXPORT (usually private or protected)
- Have non-trivial inline destructor (i.e. have some fields with destructors but do not have explicitly defined destrucror, or have it defined inline)
- Have out-of-line constructor (if not, the linker error is explainable)

The simplest example consists of DLL defining class CLangLinkError:

CLangLinkError.hxx:

~~~~
#include <Standard_Transient.hxx>

class CLangLinkError
{
public:

  Standard_EXPORT CLangLinkError();

  virtual void f();

  Handle(Standard_Transient) myField; // any field with destructor
};
~~~~

CLangLinkError.cxx:

~~~~
#include <CLangLinkError.hxx>

CLangLinkError::CLangLinkError() { }
void CLangLinkError::f() { }
~~~~

... and another DLL or executable using that class:

~~~~
#include <CLangLinkError.hxx>
...
CLangLinkError anObj; // causes linker error
~~~~

Linker error looks as follows:

~~~~
2>lld-link : error : undefined symbol: "protected: virtual void __cdecl CLangLinkError::f(void)" (?f@RWC@@MEAAXXZ)
2>>>> referenced by ....\Test.obj:("const CLangLinkError::`vftable'" (??_7CLangLinkError@@6B@))
~~~~

If the object is allocated dynamically (with operator new), the problem does not reproduce, even if the object is explicitly delted by 'delete'.

If out-of-line destructor is added in the class CLangLinkError, the problem is not reproduced.

Logically there is no need for compiler to generate vtbl for that class, it should be only generated in the constructor that is defined in main DLL. Hence, the issue looks like a bug in CLang.
Revision 2019-11-01 23:43 by abv
Description This issue is to document strange linker errors that appear when OCCT is built with CLang on Windows (toolset Clang-CL in Visual Studio 2019). It looks to be a compiler bug.

The problem appears for classes that:

- Have virtual functions not declared as Standard_EXPORT (usually private or protected)
- Have non-trivial inline destructor (i.e. have some fields with destructors but do not have explicitly defined destrucror, or have it defined inline)
- Have out-of-line constructor (if not, the linker error is explainable)

The simplest example consists of DLL defining class CLangLinkError:

CLangLinkError.hxx:

~~~~
#include <Standard_Traneient.hxx>

class CLangLinkError
{
public:

  Standard_EXPORT CLangLinkError();

  virtual void f();

  Handle(Standard_Transient) myField; // any field with destructor
};
~~~~

CLangLinkError.cxx:

~~~~
#include <CLangLinkError.hxx>

CLangLinkError::CLangLinkError() { }
void CLangLinkError::f() { }
~~~~

... and another DLL or executable using that class:

~~~~
#include <CLangLinkError.hxx>
...
CLangLinkError anObj; // causes linker error
~~~~

Linker error looks as follows:

~~~~
2>lld-link : error : undefined symbol: "protected: virtual void __cdecl CLangLinkError::f(void)" (?f@RWC@@MEAAXXZ)
2>>>> referenced by ....\Test.obj:("const CLangLinkError::`vftable'" (??_7CLangLinkError@@6B@))
~~~~

If the object is allocated dynamically (with operator new), the problem does not reproduce, even if the object is explicitly delted by 'delete'.

If out-of-line destructor is added in the class CLangLinkError, the problem is not reproduced.

Logically there is no need for compiler to generate vtbl for that class, it should be only generated in the constructor that is defined in main DLL. Hence, the issue looks like a bug in CLang.


Copyright © 2000 - 2020 MantisBT Team
Powered by Mantis Bugtracker