Unreal's macros are preventing inclusion of a third-party library

I am wrapping the cpr http request library as an external module and running into compilation issues due to Unreal’s macros rewriting the word “verify” in one of the library’s header files.

I include the library in an Unreal .cpp file, wrapping the include in the third party includes directives:

THIRD_PARTY_INCLUDES_START
#include <cpr/cpr.h>
THIRD_PARTY_INCLUDES_END

Somewhere inside the cpr library, a class has a boolean member named verify. Unreal expands the word verify as a macro, introducing a syntax error when I compile and it finds this constructor.

VerifySsl(bool p_verify) : verify(p_verify) {}

Unreal’s macro definition starts here:

#ifndef verify
	#define verify(expr)			UE_CHECK_IMPL(expr)
#endif

Inside my build.cs constructor

		Type = ModuleType.External;
		PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs;

		PublicIncludePaths.Add(Path.Combine(ModuleDirectory, "include"));
		PublicDefinitions.Add("SUPPORT_MAX_TLSv1_3");
		// How can I turn of Unreal's "verify" macro? 

		bEnableUndefinedIdentifierWarnings = false;

		if (Target.Platform == UnrealTargetPlatform.Win64)
		{
			PublicAdditionalLibraries.Add(Path.Combine(ModuleDirectory, "lib", "cpr.lib"));
			PublicAdditionalLibraries.Add(Path.Combine(ModuleDirectory, "lib", "libssl.lib"));
			PublicAdditionalLibraries.Add(Path.Combine(ModuleDirectory, "lib", "libcurl.lib"));

			RuntimeDependencies.Add("$(BinaryOutputDir)/libcurl.dll",
				Path.Combine(ModuleDirectory, "bin", "libcurl.dll"));
			RuntimeDependencies.Add("$(BinaryOutputDir)/libssl-3-x64.dll",
				Path.Combine(ModuleDirectory, "bin", "libssl-3-x64.dll"));
		}

Have other people run into similar issues when including third-party libraries, or have suggestions for workarounds to this problem?

can you perhaps try the include with a combination of namespace?

THIRD_PARTY_INCLUDES_START
namespace CPR
{
#include <cpr/cpr.h>
}
THIRD_PARTY_INCLUDES_END

Not sure if unreal plays well when it comes to mixing them with third-party stuff

In theory the namespace should isolate the variable name to it’s designated area mitigating the conflict. Just not a 100% sure unreal project will combine with that combo.

If the lib is small then you could try wrapping it’s internal functions in a namespace of it’s own

I’ll try that with the namespacing.

The slightly dodgy solution I’m using right now is to undef verify in my cpp file (need to be careful to not accidentally undef it in any headers)

THIRD_PARTY_INCLUDES_START
#undef verify
#include <cpr/cpr.h>
THIRD_PARTY_INCLUDES_END

Namespacing causes its own compiler problems. I’m going to undef verify in my relevant .cpp files for now and “be careful” I don’t undef it in inappropriate places.

Not sure if related, but if including Windows TCP, UDP, and HTTP stuff the solution is here:

Cant get winsock library to link correctly - Development / Programming & Scripting - Epic Developer Community Forums (unrealengine.com)

maybe you can try make a “middleware” to separate UE style code and the 3rd party library code,
the middleware can be 1) static global functions, or 2) a class that only including the 3rd party library header files in the *.cpp files , leaving the middleware class header files only including standard library heads.
with this way , i had integrated Qt6 libraries with UE5 project, i had compiled and link them without problem, only crashed in runtime because the QObject itself 's memory management conflict with UE5, i guess…

I think the “middleware” approach you suggest is another good solution.

It allows the .cpp file to be compiled without any unreal headers being included. I am likely to end up doing this now that I have a proof-of-concept working using #undef.

i had try this way and still need

#undef verify
#define SUPPORT_MAX_TLSv1_0 1

before including <cpr/cpr.h>
i could compiled and link exe file without problem , i still got crashed when running it, i think i still need to understand uboject memory recycling mechanism…

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.