strrange LNK2022 problem with C++/CLR project, but only for 64bit RRS feed

  • Question

  • Hello,

    I have a strange linker problemn with my /clr, but onyl in 64bit build.

    The C++/Clr project consists of one cpp file which is a wrapper for a
    native project with C++ interface.

    Both are compiled with VS 2017 15.9.16

    With this

    public ref class AxisSubsetDef {
    	String^ SubsetHandle;
    	array<array<String^>^>^ Excepts;
    	String^ Parent;
    	String^ Calculation;
    	unsigned int ZeroSup;
    	bool Hidden;
    public enum class AxisType {
    	Page = 0,
    	Row = 1,
    	Column = 2
    public ref class Connection {
    // ....
    void ViewDefineAxisCore(Server* server, String^ database, AxisType axisId, array<AxisSubsetDef^>^ axisdefs, size_t start, size_t limit, array<String^>^ properties, std::string* handle) {
    // do the actual work
    String^ Connection::ViewDefineAxisProxy(msclr::gcroot<String^> database, msclr::gcroot<AxisType> axisId, msclr::gcroot<array<AxisSubsetDef^>^> axisdefs, size_t start, size_t limit, msclr::gcroot<array<String^>^> properties) {
    	pin_ptr<struct sock_obj> pso = so;
    	auto ft1 = std::bind(&ViewDefineAxisCore, pso->myServer, database, axisId, axisdefs, start, limit, properties, std::placeholders::_1);
    	return nullptr;
    // ---
    void ViewDefineAreaCore(Server* server, String^ database, String^ cube, array<String^>^ axes, array<String^>^ properties, bool ignorehidden, std::string* handle) {
    // do the actual work
    String^ Connection::ViewDefineAreaProxy(msclr::gcroot<String^> database, msclr::gcroot<String^> cube, msclr::gcroot<array<String^>^> axes, msclr::gcroot<array<String^>^> properties, bool ignorehidden) {
    	pin_ptr<struct sock_obj> pso = so;
    	auto ft2 = std::bind(&ViewDefineAreaCore, pso->myServer, database, cube, axes, properties, ignorehidden, std::placeholders::_1);
    	return nullptr;

    I get in 64bit and only 64bit the following linker erros

    error LNK2022:
    metadata operation failed (8013118D) :
    Inconsistent layout information in duplicated types
    (std._Binder<std::_Unforced,void ,std::D::ar_traits,std::allocator<char> >):

    error LNK2022:
    metadata operation failed (8013118D) :
    Inconsistent layout information in duplicated types
    (std._Compressed_pair<void ,std::D::ar_traits,palo::allocator<char> >):

    error LNK2022:
    metadata operation failed (8013118D) :
    Inconsistent layout information in duplicated types

    I use in my code several std:bind, but  for the test I have remarked out all others,
    except this two above.

    Ehat I see, that this two proxy methods are the only proxy methods which have two
    msclr::gcroot<array<...>^> arguments.

    What can I do the get rid of this obscure link errors ?


      Hendrik Schmieder

    Wednesday, September 25, 2019 9:23 AM

All replies

  • See Linker Tools Error LNK2022.

    Did you run ildasm -tokens on the object files to find which types have the tokens listed in error_message, and look for differences?

    Did you look at all definitions of the specified types?

    Did you ensure that that the metadata file (.dll or .netmodule) is in the same location when passed to the linker, as it was when it was passed to the compiler?

    Sam Hobbs

    Wednesday, September 25, 2019 6:28 PM
  • Hi,

    Thank you for posting here.

    >>strrange LNK2022 problem with C++/CLR project, but only for 64bit

    I suggest you could try to set Configuration Properties -> C/C++ -> Code Generation -> Struct Member Alignment -> 16 Bytes (/Zp16)

    For more details, I suggest you could refer to the links:

    Best Regards,

    Jeanine Zhang

    Thursday, September 26, 2019 5:41 AM
  • @Simple Samples

    I look at the given link before I posted here, but it wasn't help full here.

    I run  ildasm -Tokens  with the Options text and out.

    Strangely, there are more than two binder entries in the log, much more,

    although I commented out all std::bind call except the two mentioned in the above Code

    and do a rebuild

    I don't know what you meant with metafile ?

    There's no .dll file created becuse of the  linker error.

    Thursday, September 26, 2019 8:36 AM
  • @Jeanine Zhang

    I already looked at these stackoverflow links before posting.

    I already had
    - Enable Minimal Rebuild to No (/RM-), and Basic Runtime Checks to Default.
    - Program Database /Zi

    Can't set Enable C++ Exceptions to No beacuse the native dll could throw c++ exception.

    Struct Member Alignment was set to default, but using  16 Bytes (/Zp16) doesn't help either.
    I have this already cheked.

    The C++ language Standard i set to /stdc++17.

    Strange thing is that the ildasm output has more than two binder entries,

    although I remarked out all std::bind calls except two.

    Thursday, September 26, 2019 8:59 AM
  • Just as note.

    If I remark out one ouf the auto lines in my Code given in my initial post,

    the linker error doesn't occur.

    I looked at all the defintion, but doesn't find anything.

    But maybe I'm too involved to find the culprit. 

    best regards

       Hendrik Schmieder

    Thursday, September 26, 2019 9:03 AM
  • Hi

    I am glad you have got your solution and thanks for your sharing, I would appreciate it if you mark them as answer and this will be beneficial to other community.

    Best Regards,

    Jeanine Zhang

    Friday, September 27, 2019 2:48 AM
  • Hello,

    why do you think, I have a solution ?

    This is not the case.

    Commenting out one of the Auto line only shows that the given code shows the core of the problem,

    but is not a solution.

    Friday, September 27, 2019 7:56 AM
  • I have created a simple solution practically only using the Code I gave in my first post and wanted to add this here as zip for reference.

    But it Looks like this is not possible.

    with best regards.

      Hendrik Schmieder


    Friday, September 27, 2019 1:12 PM
  • Hello,

    added my small testcase to

    developer community Link2022 bug report


      Hendrik Schmieder


    Thursday, October 24, 2019 8:59 AM