[BUG] apitrace (Windows) stopped working with LWJGL 3

[Kai]

Yes, I can confirm that the issue also persists with a 32-bit JRE and 32-bit upx'ed LWJGL3 when using a self-built 32-bit apitrace and running all of that on a 64-bit system. The application itself runs fine while tracing. Just the trace is broken.
Following output:

d:\downloads\apitrace\build32\MinSizeRel>apitrace trace --output x86.trace "C:\Program Files (x86)\Java\jre1.8.0_74\bin\java.exe" -jar lwjgl3-demos.jar
apitrace: loaded into C:\Program Files (x86)\Java\jre1.8.0_74\bin\java.exe
apitrace: warning: caught exception 0xc0000005
apitrace: tracing to x86.trace
apitrace: unloaded from C:\Program Files (x86)\Java\jre1.8.0_74\bin\java.exe

d:\downloads\apitrace\build32\MinSizeRel>

Sadly I could not build a 32-bit version of LWJGL 3 on my own on a 64-bit system, albeit using the x86 (32-bit) MSVC native tools command prompt.

The build process errors with the following message:

compile-native-platform:
 [Compiler] org_lwjgl_system_jemalloc_JEmacros.c
 [Compiler] org_lwjgl_system_libc_Errno.c
 [Compiler] org_lwjgl_system_libc_Stdlib.c
 [Compiler] org_lwjgl_system_libc_StringH.c
 [Compiler] org_lwjgl_system_libffi_FFIClosure.c
 [Compiler] org_lwjgl_system_libffi_LibFFI.c
 [Compiler] org_lwjgl_system_libffi_LibFFIConstants.c
 [Compiler] org_lwjgl_system_JNI.c
 [Compiler] org_lwjgl_system_simd_SSE.c
 [Compiler] org_lwjgl_system_simd_SSE3.c
 [Compiler] org_lwjgl_system_windows_GDI32.c
 [Compiler] org_lwjgl_system_windows_User32.c
 [Compiler] org_lwjgl_system_windows_WinBase.c
 [Compiler] org_lwjgl_system_xxhash_XXH32State.c
 [Compiler] org_lwjgl_system_xxhash_XXH64State.c
 [Compiler] org_lwjgl_system_xxhash_XXHash.c
 [Compiler] modules\core\src\generated\c\system\jemalloc\org_lwjgl_system_jemalloc_JEmacros.c(50) : error C2220: warning treated as error - no 'object' file generated
 [Compiler] modules\core\src\generated\c\system\jemalloc\org_lwjgl_system_jemalloc_JEmacros.c(50) : warning C4293: '>>' : shift count negative or too big, undefined behavior
 [Compiler] common_tools.c
 [Compiler] org_lwjgl_system_libffi_Closure.c
 [Compiler] org_lwjgl_system_MemoryAccess.c
 [Compiler] org_lwjgl_system_MemoryUtil.c

BUILD FAILED
D:\downloads\lwjgl3-clean\build.xml:291: The following error occurred while executing this line:
D:\downloads\lwjgl3-clean\config\windows\build.xml:40: The following error occurred while executing this line:
D:\downloads\lwjgl3-clean\config\windows\build.xml:21: apply returned: 2

[spasi]

The latest build (3.0.0 #23) does not use UPX. Let me know if everything's fine now please.

Sadly I could not build a 32-bit version of LWJGL 3 on my own on a 64-bit system, albeit using the x86 (32-bit) MSVC native tools command prompt.

The build process errors with the following message:

[Compiler] modules\core\src\generated\c\system\jemalloc\org_lwjgl_system_jemalloc_JEmacros.c(50) : error C2220: warning treated as error - no 'object' file generated
 [Compiler] modules\core\src\generated\c\system\jemalloc\org_lwjgl_system_jemalloc_JEmacros.c(50) : warning C4293: '>>' : shift count negative or too big, undefined behavior

Can't reproduce that either. Which Visual Studio edition did you use and what did you pass to vcvarsall? Did you also use a x86 JVM?

[Kai]

I used both VS2013 and VS2015 now, all of the vcvarsall.bat targets ("x86" and "amd64_x86") that can produce x86, result in that error.
Also, do I have to use a x86 JDK to build the natives? I mean I did now and their header files are identical.
Hmm... strange.

EDIT: Thank you for the hint with the x86 JDK. Now that I actually DID use a x86 JDK in JAVA_HOME when calling ant (not just in PATH) it now works. But why....?
EDIT2: Ah... I think I know why now. Because the LWJGL build process builds the architecture of the LWJGL library based on the identified JDK architecture running ant. And if that does not fit the VS build/arch, BOOM.

[CoDi]

The latest build (3.0.0 #23) does not use UPX. Let me know if everything's fine now please.

I can confirm that it's working again with the latest build. Tested with lwjgl3-demos, and our libGDX project.