[1/3] Compile PCH.ImageWrapper.h In
file included from
/tmp/makepkg/unreal-engine/src/UnrealEngine/Engine/Intermediate/Build/Linux/B4D820EA/CrashReportClient/Shipping/ImageWrapper/PCH.ImageWrapper.h:44:
In file included from
/tmp/makepkg/unreal-engine/src/UnrealEngine/Engine/Source/Runtime/ImageWrapper/Private/ImageWrapperPrivatePCH.h:16:
In file included from
/tmp/makepkg/unreal-engine/src/UnrealEngine/Engine/Source/Runtime/ImageWrapper/Private/ExrImageWrapper.h:12:
In file included from
/tmp/makepkg/unreal-engine/src/UnrealEngine/Engine/Source/ThirdParty/openexr/Deploy/include/ImathBox.h:65:
In file included from
ThirdParty/openexr/Deploy/include/ImathVec.h:46:
In file included from
ThirdParty/openexr/Deploy/include/ImathExc.h:47:
In file included from
ThirdParty/openexr/Deploy/include/IexBaseExc.h:50:
In file included from
ThirdParty/Linux/LibCxx/include/c++/v1/sstream:174:
In file included from
ThirdParty/Linux/LibCxx/include/c++/v1/ostream:138:
In file included from
ThirdParty/Linux/LibCxx/include/c++/v1/ios:216:
ThirdParty/Linux/LibCxx/include/c++/v1/__locale:39:11:
fatal error: ‘xlocale.h’ file not
found
include
^~~~~~~~~~~ 1 error generated. ERROR: UBT ERROR: Failed to
produce item:
/tmp/makepkg/unreal-engine/src/UnrealEngine/Engine/Binaries/Linux/CrashReportClient
Total build time: 3.26 seconds (Local
executor: 0.00 seconds) make: ***
[Makefile:252:
CrashReportClient-Linux-Shipping]
Error 5
Yeah, that would work. My understanding is Unreal bundles all versions of third party libraries needed with it. Going to have to figure out which package for Arch has xlocale in the meantime.
I do recompile the engine. I’m one of the maintainers of the aur release version of Unreal. Which patch do I need to pull in to get the engine to compile correctly?
The nonstandard header xlocale.h has
been removed in this release. It was
never intended to be included directly
by programs other than glibc itself,
and it was a strict subset of the
standard header locale.h. We know that
a number of programs do include it,
but because it has never been part of
any other C library, programs that use
it are probably testing for its
existence with autoconf or a similar
tool, and should not fail to compile.
It’s totally bad idea to mess up with third party source code (it seems like you didn’t even understand what you were doing). Builds is not equal to works.
OK, you are somewhat right, that I should have done some more investigation about this. So I found, that this is actually the solution to the problem.
According to glibc Release Notes 2.26 :
The nonstandard header xlocale.h has been removed. Most programs should
use locale.h instead. If you have a specific need for the definition of
locale_t with no other declarations, please contact libc-alpha@sourceware.org and explain.
So obviously the glibc developers have included all standard content of xlocale.h into locale.h, which is also included in the file, that I modified.
After my investigation I’m no more that surprised. If you agree, I would edit my comment above accordingly.
Looks like xlocale.h has been removed in glibc 2.26.
See:
https:/ . /www . .linuxquestions.org/questions . /slackware-14/ no-luck-with-libc-on-current-xlocale-h-missing-4175612648/
https:/ /sourceware.or . g/glibc/wiki/Release/2.26# . Removal_of_.27xlocale.h.27
Looks like MeTA is using a custom FindICU that hasn’t been updated for ~2 years. However, it seems that cmake 3.7 has it’s own FindICU. Maybe switching to that will pull in a more up-to-date ICU that has been patched for glibc 2.26? TUTUApp Vip9Apps Fast DownloadAptoide APK