Issues when compiling for Linux

I’m currently trying to compile my SteamWorkshopAccessor Plugin for Linux to help out one of the customers.

One issue is that a variable of the parent class is unknown in the child class

template <typename SteamResultType, typename CallbackPayloadType>
class **FSteamAsyncObject**

    CallbackPayloadType **m_callbackPayload**;


template <typename QueryParameterType, typename QueryResultType>
class FSteamAsyncObjectQueryWorkshopForItems : public **FSteamAsyncObject**<SteamUGCQueryCompleted_t, QueryResultType>
    FSteamAsyncObjectQueryWorkshopForItems(const SteamAPICall_t& apiCall, const QueryParameterType& queryParams, TFunction<void(QueryResultType)>&& inCallbackFunction)
        : FSteamAsyncObject<SteamUGCQueryCompleted_t, QueryResultType>(FString("QueryWorkshopForItems"), apiCall, MoveTemp(inCallbackFunction))
**m_callbackPayload**.queryParams = queryParams;

**m_callbackPayload **is unknown member variable. Why?..

Another issue is a

#define **R_OK**

inside the crosscompile chain which seems to inject files in the plugin files when compiling.
It conflicts with

enum class EResultBP : uint8
    R_INVALIDRESULT = 0, // FIX unreal wants a 0 value since UE4.24
    // Success.
**R_OK **= 1,

It even conflits with clear references to the enum


I could fix most of the code by

#ifdef R_OK
#pragma push_macro("R_OK")
#undef R_OK
#define NEED_R_OK_POP


#ifdef NEED_R_OK_POP
#undef NEED_R_OK_POP
#pragma pop_macro("R_OK")

but now there is the generated code from the header tool that generated

UEnum* Z_Construct_UEnum_SteamGeneral_EResultBP()
        UPackage* Outer = Z_Construct_UPackage__Script_SteamGeneral();
        static UEnum* ReturnEnum = FindExistingEnumIfHotReloadOrDynamic(Outer, TEXT("EResultBP"), 0, Get_Z_Construct_UEnum_SteamGeneral_EResultBP_Hash(), false);
        static UEnum* ReturnEnum = nullptr;
        if (!ReturnEnum)
            static const UE4CodeGen_Private::FEnumeratorParam Enumerators] = {
                { "EResultBP::R_INVALIDRESULT", (int64)EResultBP::R_INVALIDRESULT },
                { "EResultBP::R_OK", (int64)EResultBP::R_OK },

more R_OK that again conflict with the toolchain, where I’m not able to inject the undefine fix from above …

The simplest thing would be to rename R_OK to something else, which probably causes a mess in blueprint …

any ideas?

To you first question, about missing members? Do you miss any headers?

To your second question, I would not rename the define, I would redesign your enum. (you can replace string in many files with nqq).

No. The parent class was declared right above. And the parent is not declared as missing. Also the plugin was compiling fine for windows.
I could solve it with a

typedef ... ParentType;

Should not have been necessary, but it did not work without.

I don’t want to redefine the enum. I don’t even know why the linux toolchain seems to inject another file.

I noticed that the generated .cpp file includes the header where the enum was defined. So I just undefined the define, without redefining it afterwards again. But the solution is very clunky and not statisfying.