Open ryan-motive opened 2 months ago
Its not safe for the stl types, its going to be a mixture of padding/packing/optimization levels. I attempted at one point to get the cmake compile options used in the engine build to match the library builds, but the way Epic structured the build tools most of it is private and unreachable from the public interface. I think I might be able to support it though C#'s reflection of the private fields but I have not had a chance to test it (and really try to limit my exposure to C# :) )
Digging in I think the issue was that my library was linked against the debug MSVCP library. When I switched to the release library everything works. As far as I can tell this should be fairly safe since the DLL is where the alignment comes into play, so as long as both are using the same one we should be in good shape. Ultimately though the safest would be for this to just be built directly as part of the Unreal Build Tool, would be interesting to think about how we could use this plugin to work that way.
Thanks for the great plugin!
I just want to say, I blame you for my recent pain. I think I might have something working, it uses the reflection api to pull out most (maybe all) of the flags from the toolchains. I have not tested it on Windows but seems to work on Linux, (although fastnoise2 with the rtti options is giving me a lot of trouble, as UE does not like rtti)
It does seem to fetch the cxx_flags, that I then inject into cmake
argument: -c
argument: -pipe
argument: -msse4.2
argument: -I"/mnt/data/projects/UE4_FastNoise2/Source"
argument: -D"UE_IS_ENGINE_MODULE=0"
argument: -D"UE_ENABLE_INCLUDE_ORDER_DEPRECATED_IN_5_1=1"
argument: -D"UE_ENABLE_INCLUDE_ORDER_DEPRECATED_IN_5_2=1"
argument: -D"UE_ENABLE_INCLUDE_ORDER_DEPRECATED_IN_5_3=1"
argument: -D"UE_PROJECT_NAME=FastNoise2Example"
argument: -D"UE_TARGET_NAME=FastNoise2Example"
argument: -D"IMPLEMENT_ENCRYPTION_KEY_REGISTRATION()="
argument: -D"IMPLEMENT_SIGNING_KEY_REGISTRATION()="
argument: -D"DEPRECATED_FORGAME=DEPRECATED"
argument: -D"UE_DEPRECATED_FORGAME=UE_DEPRECATED"
argument: -D"FASTNOISE2EXAMPLE_API="
argument: -Wall
argument: -Werror
argument: -Wdelete-non-virtual-dtor
argument: -Wenum-conversion
argument: -Wbitfield-enum-conversion
argument: -Wno-enum-enum-conversion
argument: -Wno-enum-float-conversion
argument: -Wno-ambiguous-reversed-operator
argument: -Wno-deprecated-anon-enum-enum-conversion
argument: -Wno-deprecated-volatile
argument: -Wno-unused-but-set-variable
argument: -Wno-unused-but-set-parameter
argument: -Wno-ordered-compare-function-pointers
argument: -Wno-bitwise-instead-of-logical
argument: -Wno-gnu-string-literal-operator-template
argument: -Wno-inconsistent-missing-override
argument: -Wno-invalid-offsetof
argument: -Wno-switch
argument: -Wno-tautological-compare
argument: -Wno-unknown-pragmas
argument: -Wno-unused-function
argument: -Wno-unused-lambda-capture
argument: -Wno-unused-local-typedef
argument: -Wno-unused-private-field
argument: -Wno-unused-variable
argument: -Wno-undefined-var-template
argument: -Wshadow
argument: -Wundef -Wno-error=undef
argument: -Wno-float-conversion
argument: -Wno-implicit-float-conversion
argument: -Wno-implicit-int-conversion
argument: -Wno-c++11-narrowing
argument: -fdiagnostics-absolute-paths
argument: -fdiagnostics-color
argument: -Wno-undefined-bool-conversion
argument: -fno-inline-functions
argument: -O3
argument: -fno-optimize-sibling-calls
argument: -fno-omit-frame-pointer
argument: -fno-exceptions
argument: -DPLATFORM_EXCEPTIONS_DISABLED=1
argument: -gdwarf-4
argument: -ggnu-pubnames
argument: -fvisibility-ms-compat
argument: -fvisibility-inlines-hidden
argument: --driver-mode=g++
argument: -nostdinc++
argument: -isystem"/mnt/data/projects/UnrealEngine/Engine/Source/ThirdParty/Unix/LibCxx/include"
argument: -isystem"/mnt/data/projects/UnrealEngine/Engine/Source/ThirdParty/Unix/LibCxx/include/c++/v1"
argument: -fbinutils-version=2.36
argument:
argument: -fno-math-errno
argument: -fno-rtti
argument: -mssse3
argument: -ffunction-sections
argument: -fdata-sections
argument: -fno-PIE
argument: -target x86_64-unknown-linux-gnu
argument: --sysroot="/mnt/data/projects/UnrealEngine/Engine/Source/../Extras/ThirdPartyNotUE/SDKs/HostLinux/Linux_x64/v22_clang-16.0.6-centos7/x86_64-unknown-linux-gnu"
argument: -isystem"/mnt/data/projects/UnrealEngine/Engine/Extras/ThirdPartyNotUE/SDKs/HostLinux/Linux_x64/v22_clang-16.0.6-centos7/x86_64-unknown-linux-gnu/lib/clang/16/include/"
argument: -std=c++20
I'm trying to understand some issues I'm seeing using STL types in a dll built with UE4CMake. I know that in general it's not recommended to use STL types with a DLL, but I assumed that UE4CMake would remedy this by making sure the toolchain, compilers, etc. were all aligned. However I'm finding that the DLL and code in Unreal have very different ideas of how the STL types are laid out.
Is this caused by the DLL pointing at a different library or would this be another issue like the 4-byte packing issue? I can just bring the whole project into my Plugins folder, but I'm hoping to keep this library somewhat separate.