I'm trying to build my project to launch it into my Oculus (Meta) Quest 2, the exact build that I'm choosing is Android (ASTC). But when I try to build, I get the following error
UATHelper: Packaging (Android (ASTC)): ERROR: Missing precompiled manifest for 'SteamShared'. This module was most likely not flagged for being included in a precompiled build - set 'PrecompileForTargets = PrecompileTargetsType.Any;' in SteamShared.build.cs to override.
PackagingResults: Error: Missing precompiled manifest for 'SteamShared'. This module was most likely not flagged for being included in a precompiled build - set 'PrecompileForTargets = PrecompileTargetsType.Any;' in SteamShared.build.cs to override.
I added that line PrecompileForTargets = PrecompileTargetsType.Any; to the SteamShared.build.cs file but it didn't change anything, the error persists.
Here's my Project.Build.cs
PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs;
PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore", "HeadMountedDisplay", "UMG", "LibOVRPlatform"}); //, "OnlineSubsystem"
PrivateDependencyModuleNames.AddRange(new string[] { "FirebaseFeatures", "OnlineSubsystem", "OnlineSubsystemOculus", "OnlineSubsystemSteam" });
So I'm also using the plugin AdvancedSessions & AdvancedSteamSessions. These plugins are in the Engine's plugins but also in the Project's plugins.
But the SteamSharedModule Plugin that's giving me the error is only in the engine (at C:\Epic\UE_4.27\Engine\Plugins\Runtime\Steam), and the OnlineSubsystemSteam Plugin is also only in the engine (at C:\Epic\UE_4.27\Engine\Plugins\Online).
When I try to disable the SteamSharedModule Plugin, it says "This plugin is required by OnlineSubsystemSteam", and when I try to disable the plugin OnlineSubsystemSteam, it says "This plugin is required by AdvancedSteamSessions".
NOTE: The multiplayer functionality I have made it in blueprints, but the project isn't completely in Blueprints, I do have some C++ classes.
Related
I've recently updated expo sdk to the latest version. I've created a project with bare workflows and tried to do a native build . And after a time it fails with the message Execution failed for task ':expo-modules-core:buildCMakeDebug[arm64-v8a]'.
I create expo project with yarn create expo-app <name> --template bare-minimum and run it with npx expo run:android.
I've already tried to reinstall expo sdk, reinstall android sdk and ndk, clear npm caches and create other expo projects to ensure that it isn't caused by libraries. I also face this problem when try to create project with expo init <name> with minimal template.
While the old project build with expo 42 builds without any problem. I suppose it is becase of using unimodules instead of expo-modules in old versions.
Stackoverflow doesn't allow me to upload full log here, so I uploaded to Google Drive. And here are some typical problems he outputs me:
/home/x3noku/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/typeinfo:215:14: error: cast from pointer to smaller type 'std::__type_info_implementations::__non_unique_arm_rtti_bit_impl::__type_name_t' (aka 'unsigned int') loses information
return reinterpret_cast<__type_name_t>(__v);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/x3noku/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/cmath:317:9: error: no member named 'signbit' in the global namespace; did you mean '__signbit'?
using ::signbit;
~~^
/usr/include/bits/mathcalls-helper-functions.h:24:24: note: '__signbit' declared here
__MATHDECL_ALIAS (int, __signbit,, (_Mdouble_ __value), signbit)
/home/x3noku/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/cmath:324:7: error: no member named 'isgreaterequal' in the global namespace; did you mean '::std::greater_equal'?
using ::isgreaterequal;
^~
/home/x3noku/Android/Sdk/ndk/21.4.7075529/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/include/c++/v1/functional:767:29: note: '::std::greater_equal' declared here
struct _LIBCPP_TEMPLATE_VIS greater_equal : binary_function<_Tp, _Tp, bool>
In file included from ../../../../src/main/cpp/JSIInteropModuleRegistry.cpp:3:
In file included from ../../../../src/main/cpp/JSIInteropModuleRegistry.h:6:
In file included from ../../../../src/main/cpp/JavaScriptModuleObject.h:7:
In file included from /home/x3noku/Code/js/expo46/node_modules/react-native/ReactAndroid/src/main/jni/react/jni/ReadableNativeArray.h:10:
In file included from /home/x3noku/Code/js/expo46/node_modules/react-native/ReactAndroid/src/main/jni/react/jni/NativeArray.h:11:
In file included from ../../../../build/third-party-ndk/folly/folly/dynamic.h:66:
In file included from ../../../../build/third-party-ndk/folly/folly/Range.h:45:
/usr/include/fmt/format.h:2510:10: error: no member named '__builtin_isfinite' in namespace 'std'; did you mean simply '__builtin_isfinite'?
return std::isfinite(value);
^~~~~
/usr/include/fmt/format.h:2506:22: note: '__builtin_isfinite' declared here
FMT_CONSTEXPR20 bool isfinite(T value) {
^
/usr/include/math.h:994:23: note: expanded from macro 'isfinite'
# define isfinite(x) __builtin_isfinite (x)
^
I have been dealing with this issue for a couple of days now. I Built the .so library using cmake under visual studio using the fallowing settings:
CMakeList.txt:
cmake_minimum_required (VERSION 3.8)
set(ANDROID_STL c++_static)
set(CMAKE_TOOLCHAIN_FILE C:/Microsoft/AndroidNDK/android-ndk-r21d/build/cmake/android.toolchain.cmake)
project("GetValsDudeLib").
So far I have been unable to find any examples online
set(CMAKE_SYSTEM_PROCESSOR x86)
set(CMAKE_ANDROID_ARCH arm)
set(CMAKE_SYSTEM_NAME ANDROID)
set(CMAKE_ANDROID_NDK "C:/Microsoft/AndroidNDK/android-ndk-r21d")
set(CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION clang5.0)
set(CMAKE_SYSTEM_VERSION 23) # API level
set(CMAKE_ANDROID_ARCH_ABI x86)
file(GLOB GetValsDudeSRC ${CMAKE_CURRENT_SOURCE_DIR}/*.cpp ${CMAKE_CURRENT_SOURCE_DIR}/*.hpp)
add_library (GetValsDudeLib STATIC ${GetValsDudeSRC})
CMakeSetting.json
{
"configurations": [
{
"name": "x86-Debug",
"generator": "Ninja",
"configurationType": "Debug",
"buildRoot": "${projectDir}\\out\\build\\${name}",
"installRoot": "${projectDir}\\out\\install\\${name}",
"cmakeCommandArgs": "",
"buildCommandArgs": "",
"ctestCommandArgs": "",
"inheritEnvironments": [ "gcc-arm" ],
"variables": []
}
]
}
I added the the reference to the android native activity project:
Added headers folder path. Project properties C/C++ => Additional Include Directories.
Added library (.so) folder path. Project properties Linking => input=> Additional Library Directories.
Specified Library. Project properties Linking => input=> Library Dependencies (set that to "GetValsDudeLib").
After that I am able to create an instance of the class provided by the Library (GetValsDude) and build. It runs with no issues. But if I try to use a method of the object (AddOne(int)) it fails with the fallowing exception:
1>C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\MSBuild\Microsoft\VC\v160\Application Type\Android\3.0\Android.Common.targets(119,5): error MSB6006: "clang.exe" exited with code 1.
1> 263 Warning(s)
1> 1 Error(s)
1>
Looking into the logs I found the following:
...
1> C:\Microsoft\AndroidNDK\android-ndk-r21d\toolchains\x86-4.9\prebuilt\windows-x86_64/lib/gcc/i686-linux-android/4.9.x/../../../../i686-linux-android/bin\ld: Opened new descriptor 10 for "x86\Debug\libRevEngineAndroid.so"
1> undefined reference to 'GetValsDude::AddOne(int)'
...
So obviously there is a failure Linking GetValsDude header to the .so library.
Any help will be greatly appreciated.
I’ve been using bazel to build an android project, initially starting with a 0.24 version, then using the 2.0 version for a longer time, and now I am trying to switch to the latest 3.7.0 / 3.7.1 versions.
Currently I am using the following important .bazelrc settings for android:
build:androidbuild --crosstool_top=#androidndk//:default_crosstool
build:androidbuild --host_crosstool_top=#bazel_tools//tools/cpp:toolchain
build:android-32 --config=androidbuild --cpu=x86 --fat_apk_cpu=x86
All cc_binary / cc_library targets can still be built the same way we used to, but the android_binary targets no longer builds and I am getting this error:
ERROR: While resolving toolchains for target
#bazel_tools//tools/android:databinding_exec: No matching toolchains
found for types #bazel_tools//tools/cpp:toolchain_type. Maybe
--incompatible_use_cc_configure_from_rules_cc has been flipped and there is no default C++ toolchain added in the WORKSPACE file? See
https://github.com/bazelbuild/bazel/issues/10134 for details and
migration instructions.
I tried to find which was the bazel version that started to throw this error, and I found that I can still build my project with 3.6.0, but I start getting the above error if I switch to 3.7.0 or 3.7.1.
Looking at the 3.6.0 vs 3.7.0 changes, I am wondering if the new create_dummy_sdk_toolchain call in tools/android/android_sdk_repository_template.bzl would cause this failure or there is something else I am missing (like changes in the cc_flags_supplier.bzl / compiler_flag.bzl sources to set incompatible_use_toolchain_transition to True).
I tried the approach of using --platforms instead, but I am still getting errors even in that case:
build:androidbuild --extra_toolchains=#androidndk//:all
build:android-32 --config=androidbuild --cpu=x86 --platforms=//config:android_x86
With:
platform(
name = "android_x86",
constraint_values = [
"#bazel_tools//platforms:x86_32",
"#bazel_tools//platforms:android",
],
cpu_constraints = [
],
os_constraints = [
],
target_platform = True,
)
Error:
ERROR: While resolving toolchains for target
#bazel_tools//tools/android:instrumentation_test_check: No matching
toolchains found for types #bazel_tools//tools/cpp:toolchain_type.
Maybe --incompatible_use_cc_configure_from_rules_cc has been flipped
and there is no default C++ toolchain added in the WORKSPACE file? See
https://github.com/bazelbuild/bazel/issues/10134 for details and
migration instructions.
Can you please advise me on what is missing from the project that is required to solve the problem caused by the 3.6.0 vs 3.7.0 diffs, do we now need to define a proper toolchain for Android (can't we rely anymore on bazel to figure out how to build android targets)?
UPDATE Dec/16/2020
Looks like the problem was caused by this code:
WORKSPACE:
register_execution_platforms(
"//tools/config:host_platform",
)
In the BUILD file:
platform(
name = "host_platform",
constraint_values = [
],
cpu_constraints = [
"#bazel_tools//platforms:x86_32",
"#bazel_tools//platforms:x86_64",
],
host_platform = True,
os_constraints = [
"#bazel_tools//platforms:windows",
],
)
For some reason this works in bazel 3.6.0 even when the host is Linux, but it's no longer working in 3.7.0.
The problem was caused by this code:
WORKSPACE:
register_execution_platforms(
"//tools/config:host_platform",
)
In the BUILD file:
platform(
name = "host_platform",
constraint_values = [
],
cpu_constraints = [
"#bazel_tools//platforms:x86_32",
"#bazel_tools//platforms:x86_64",
],
host_platform = True,
os_constraints = [
"#bazel_tools//platforms:windows",
],
)
For some reason this works in bazel 3.6.0 even when the host is Linux, but it's no longer working in 3.7.0.
when I do bazel build --platforms=//:linux_arm64 it gave me the same error:
hile resolving toolchains for target #io_bazel_rules_go//:cgo_context_data: No matching toolchains found for types #bazel_tools//tools/cpp:toolchain_type. Maybe --incompatible_use_cc_configure_from_rules_cc has been flipped and there is no default C++ toolchain added in the WORKSPACE file? See https://github.com/bazelbuild/bazel/issues/10134 for details and migration instructions.
The follow command works
bazel build --platforms=#io_bazel_rules_go//go/toolchain:linux_arm64
I am trying to build my Unity project with Jenkins.
Created a BuildScript with the following calls (not all is shown):
BuildPlayerOptions options = new BuildPlayerOptions();
options.scenes = new string[] { "Assets/game.unity" };
options.targetGroup = BuildTargetGroup.Android;
options.target = BuildTarget.Android;
options.locationPathName = "/Users/Admin/my.apk";
BuildPipeline.BuildPlayer(options);
When I call this build from a local shell, the build works great and an apk is created.
When I try to call it from Jenkins using the Unity3d plugin, I get a strange compilation error which seems to be related to a missing UNITY_ANDROID directive. So basically code inside
#if UNITY_ANDROID
...
#endif
Is not called.
Is there any reason why when my code is compiled from the Jenkins build, the above directive (and others I guess) are not defined automatically?
So I was able to solve this one, by trial and error.
It appears that when I ran the build with a -projectPath, Unity does not recognise the platform and set the directive.
Adding the -buildTarget Android command line to the build, solves this issue.
It seems that sbt-android is ignoring the presence of the RenderScript files and is not generating the ScriptC_xxx java classes that are normally generated by gradle builds/Android Studio [UPDATE: this is false, se the update note below]. Because of this issue, the sbt-android build is failing because to use the scripts we need to reference the generated ScriptC_xxx classes, which gives the following error when building:
[error] apackage/YYYClass.java:55: cannot find symbol
[error] symbol: class ScriptC_xxx
[error] location: class apackage.YYYClass
[error] ScriptC_xxx xxxScript = new ScriptC_xxx(rs);
The generated .sbt file from the existing project (which compiles normally by gradle) has the apparent necessary configuration for RenderScript, generated from the build.gradle file:
rsTargetApi in Android := "18",
rsSupportMode in Android := rsSupportMode.value || true
What I am missing to be able to compile renderscript-containing android projects with sbt-android ?
UPDATE: I realized that the java classes for the scripts are being generated correctly, but somehow the classes that use those generated classes cannot find them, so maybe I have a classpath configuration problem.
This is the current file structure:
./asubmodule/src/main/rs/xxx.rs
(using package declaration #pragma rs java_package_name(apackage.scripts))
./asubmodle/src/main/java/apackage/YYYClass.java
./asubmodule/target/android/generated/source/android/support/v7/appcompat/R.java
./asubmodule/target/android/generated/source/apackage/scripts/ScriptC_xxx.java
Unfortunately, it seems com.android.builder.core.AndroidBuilder no longer generates .d files for processed renderscript sources. Bypassing AndroidBuilder to use com.android.sdklib.build.RenderScriptProcessor in sbt-android could restore the .d files that are required to determine the generated files. But that would be a solution for a future version of sbt-android.
To work around your problem for now, you can add the following into your build.sbt:
sourceGenerators in Compile += Def.task {
implicit output = outputLayout.value
val layout = projectLayout.value
(layout.generatedSrc ** "ScriptC_*.java").get ++ (layout.generatedSrc ** "*BitCode.java").get
}.taskValue
Since it sounds like you're using sbt-android-gradle you can just create a new file build.sbt and throw the above in (do not edit the 00-gradle-generated.sbt)
Update: this will be fixed in the next version of sbt-android https://github.com/scala-android/sbt-android/commit/ec09a55233aabd50e7df0085b10c567e38b616d3