Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build DLL with the same STL library as Unreal #27

Open
ryan-motive opened this issue Sep 5, 2024 · 4 comments
Open

Build DLL with the same STL library as Unreal #27

ryan-motive opened this issue Sep 5, 2024 · 4 comments

Comments

@ryan-motive
Copy link

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.

@caseymcc
Copy link
Owner

caseymcc commented Sep 6, 2024

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# :) )

@ryan-motive
Copy link
Author

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!

@caseymcc
Copy link
Owner

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)

@caseymcc
Copy link
Owner

caseymcc commented Sep 10, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants