Unresolved External when using TArray

Development Programming & Scripting
1

So, I have 2 plugins – “Dungeon Generator” and “State Machine.” Dungeon Generator has a dependency on the State Machine plugin, which is reflected in the .uplugin file:

  "Modules": [
    {
      "Name": "DungeonMaker",
      "Type": "Developer",
      "LoadingPhase": "Default"
    }
  ],
  "Plugins": [
    {
      "Name": "StateMachine",
      "Enabled": true
    }
  ]

and the .build.cs file:

PrivateDependencyModuleNames.AddRange(
	new string[]
	{
		"CoreUObject",
		"Engine",
		"Slate",
		"SlateCore",
		"StateMachine",
	}
);

One of the things I’m trying to access is the FGrammarResult struct, which is defined as so:

USTRUCT(BlueprintType)
struct STATEMACHINE_API FGrammarResult
{
	GENERATED_BODY()
public:
	UPROPERTY(EditAnywhere, BlueprintReadOnly)
	const UGrammar* Grammar;
	UPROPERTY(EditAnywhere, BlueprintReadOnly)
	const UStateMachineState* NextState;

	UPROPERTY(EditAnywhere, BlueprintReadWrite)
	EGrammarResultType GrammarResult;

	UPROPERTY(EditAnywhere, BlueprintReadOnly)
	TArray<UGrammarAlphabet*> GrammarInputShape;
};

As you can see, STATEMACHINE_API is in the struct definition. However, my project still fails to compile. This is the output from the linker:

2>Module.DungeonMaker.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl FGrammarResult::FGrammarResult(void)" (__imp_??0FGrammarResult@@QEAA@XZ) referenced in function "protected: void __cdecl UDungeonMissionGenerator::TryToCreateDungeon(class UDungeonMissionNode *,class TArray<class UDungeonMissionGrammar const *,class FDefaultAllocator>,struct FRandomStream &,int)" (?TryToCreateDungeon@UDungeonMissionGenerator@@IEAAXPEAVUDungeonMissionNode@@V?$TArray@PEBVUDungeonMissionGrammar@@VFDefaultAllocator@@@@AEAUFRandomStream@@H@Z)
2>Module.DungeonMaker.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl FGrammarResult::~FGrammarResult(void)" (__imp_??1FGrammarResult@@QEAA@XZ) referenced in function "protected: void __cdecl UDungeonMissionGenerator::TryToCreateDungeon(class UDungeonMissionNode *,class TArray<class UDungeonMissionGrammar const *,class FDefaultAllocator>,struct FRandomStream &,int)" (?TryToCreateDungeon@UDungeonMissionGenerator@@IEAAXPEAVUDungeonMissionNode@@V?$TArray@PEBVUDungeonMissionGrammar@@VFDefaultAllocator@@@@AEAUFRandomStream@@H@Z)
2>Module.DungeonMaker.cpp.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __cdecl FGrammarResult::FGrammarResult(struct FGrammarResult const &)" (__imp_??0FGrammarResult@@QEAA@AEBU0@@Z) referenced in function "protected: void __cdecl UDungeonMissionGenerator::TryToCreateDungeon(class UDungeonMissionNode *,class TArray<class UDungeonMissionGrammar const *,class FDefaultAllocator>,struct FRandomStream &,int)" (?TryToCreateDungeon@UDungeonMissionGenerator@@IEAAXPEAVUDungeonMissionNode@@V?$TArray@PEBVUDungeonMissionGrammar@@VFDefaultAllocator@@@@AEAUFRandomStream@@H@Z)

What’s really weird is that it only happens when using a TArray. The following compiles just fine:

	UPROPERTY(EditAnywhere, BlueprintReadOnly)
	UGrammarAlphabet* GrammarInputShape;

It’s not just limited to UGrammarAlphabet, either. Even what’s below causes an unresolved external:

	UPROPERTY(EditAnywhere, BlueprintReadOnly)
	TArray<UObject*> GrammarInputShape;

This is driving me nuts. There is no reason why it would work fine without the TArray, but then suddenly making it into an array causes an unresolved external. Even including "Containers/Array.h" doesn’t fix it. TSet and TMap run into the same issue.

What gives?

2

Hi,

It’s complaining about a missing default constructor, copy constructor and destructor for your FGrammarState struct. There is a difference with and without the TArray, and that is that adding the TArray member stops those special functions being trivial. My guess is that similar problems should occur if it was any other kind of non-trivial class, like FString or even FVector.

That struct is being constructed by your TryToCreateDungeon function, and you haven’t posted any code for that. But in any case, the compiler should be able to construct the struct whether or not it’s a trivial type, so I’m still not sure what’s going on.

Even without the code for TryToCreateDungeon, I’d suggest defining a constructor for your struct in the .cpp file, like this:

// GrammarResult.h
#pragma once
#include "GrammarResult.generated.h"

USTRUCT(BlueprintType)
struct STATEMACHINE_API FGrammarResult
{
    GENERATED_BODY()

    FGrammarResult();
    FGrammarResult(const FGrammarResult&);
    FGrammarResult& operator=(const FGrammarResult&);
    ~FGrammarResult();

    ...
};

// GrammarResult.cpp
#include "GrammarResult.h"

FGrammarResult::FGrammarResult() = default;
FGrammarResult::FGrammarResult(const FGrammarResult&) = default;
FGrammarResult& FGrammarResult::operator=(const FGrammarResult&) = default;
FGrammarResult::~FGrammarResult() = default;

This should be regarded as a workaround though - it shouldn’t be necessary and doesn’t explain the original problem.

Steve

3

I’ve tried that, and it didn’t seem to help. The only thing that fixes it is combining the two plugins back into a single plugin again – which still doesn’t make much sense, because the code is the same.

TryToCreateDungeon is indeed the function causing the issue, but I’ve narrowed it down to a single line of code inside that function:

FGrammarResult result;

I can place that single line of code in any function in my Dungeon Generator plugin and still get unresolved externals. It’s not limited to FGrammarResult, either – any struct which has a TArray in it causes an unresolved external.

The only thing I can think of is somehow the plugin isn’t exporting these structs properly for whatever reason, but here’s the kicker – calling it from game code is fine. No issues whatsoever. It only occurs when it’s called from another plugin.

My workaround for right now is just to keep the plugins merged into a single plugin. It means some code duplication, so I’m not entirely happy with this solution, but it compiles and runs fine.

4

Have you try replace GENERATED_BODY() with GENERATED_USTRUCT_BODY() ?