Bug#1021894: openjfx: FTBFS on arm64 and armhf
On Sat, Jul 15, 2023 at 01:46:02PM -0700, tony mancill wrote: > I intend to build and upload in the next few days, but you are welcome > to NMU if you would prefer. Uploaded as 11.0.11+1-3.1. (The version number was a slight mistake on my part; I meant to remove the NMU suffix in the changelog before the upload. I will fix it on the next upload.)
Bug#1021894: openjfx: FTBFS on arm64 and armhf
Hi Wookey, Thank you for the investigation and the patch! I intend to build and upload in the next few days, but you are welcome to NMU if you would prefer. Cheers, tony On Fri, Jul 14, 2023 at 02:28:14PM +0100, Wookey wrote: > Source: openjfx > Followup-For: Bug #1021894 > > I was surprised to find that this package was missing on arm64 (making josm > uninstallable) so I investigated. > > 11.0.11+0-1 built OK on 2021-02-03. But 11.0.11+1-3 FTBFS. > > 11.0.11+0-1 no longer builds either. Failing in: > Execution failed for task ':media:buildAVPlugin' > ../../../plugins/av/decoder.c:79:5: error: implicit declaration of function > 'avcodec_register_all' > which seems to be a problem with ffmpeg, but lets ignore that for now - it > seems to be fixed with a patch in +1-3 > > 11.0.11+1-3 fails with: > [ 28%] Building CXX object > Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o > Gradle is still running, please be patient... > In file included from > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerARM64.h:30, > from > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssembler.h:46, > from > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/GPRInfo.h:28, > from > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ArithProfile.h:28, > from > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:28: > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h: > In static member function ‘static void > JSC::ARM64Assembler::replaceWithJump(void*, void*)’: > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:2576:51: > error: ‘class JSC::ExecutableAllocator’ has no member named ‘getJumpIslandTo’ > 2576 | to = > ExecutableAllocator::singleton().getJumpIslandTo(where, to); > | ^~~ > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h: > In static member function ‘static void* > JSC::ARM64Assembler::prepareForAtomicRelinkJumpConcurrently(void*, void*)’: > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:2781:49: > error: ‘class JSC::ExecutableAllocator’ has no member named > ‘getJumpIslandToConcurrently’ > 2781 | return > ExecutableAllocator::singleton().getJumpIslandToConcurrently(from, to); > | > ^~~ > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h: > In static member function ‘static void > JSC::ARM64Assembler::linkJumpOrCall(int*, const int*, void*)’: > /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:3024:51: > error: ‘class JSC::ExecutableAllocator’ has no member named ‘getJumpIslandTo’ > 3024 | to = > ExecutableAllocator::singleton().getJumpIslandTo(bitwise_cast(fromInstruction), > to); > | ^~~ > > (Which is actually a different failure point from the one Sebastian posted in > this bug) > > So all this jumpisland stuff comes from webkit's JavaScript JIT. > > It turns out that this upstream Webkit bug explains what's going on: > https://bugs.webkit.org/show_bug.cgi?id=217079 > jumpislands allow +-128MB jumps to get to the whole 1GB executable space by > having a particular memory layout. > And the build should use _either_ the JIT or 'CLOOP', but not both. > > Applying the patch in that bug (which gates JUMP_ISLANDS on the JIT > being enabled, and avoids compiling in a call to dumpJITMemory if JIT > is disabled) allows everything to get compiled. However it then fails > to link: > > [100%] Linking CXX shared library ../../lib/libjfxwebkit.so > /usr/include/c++/11/ext/new_allocator.h:116: error: undefined reference to > 'std::__throw_bad_array_new_length()' > collect2: error: ld returned 1 exit status > gmake[4]: *** > [Source/WebKitLegacy/CMakeFiles/WebKitLegacy.dir/build.make:2237: > lib/libjfxwebkit.so] Error 1 > > Which seems to be a problem with compiling with gcc11/12, but then trying > to link to the gcc-libstd++ from gcc10. Removing all the gcc-10 > packages from the build environment fixed this. I think this means > the package should get a build-conflict on libstdc++-10-dev > > Also the discussion in the above bug suggests that the JIT should in fact be > enabled on debian arm64. > It only needs to be turned off on iOS and 64k aarch64 kernel (RHEL). I will > test that next. > > Attached is the debdiff that at least makes the build work again for now. > Happy to do an NMU if that's helpful > diff -Nru openjfx-11.0.11+1/debian/changelog >
Bug#1021894: openjfx: FTBFS on arm64 and armhf
Source: openjfx Followup-For: Bug #1021894 I was surprised to find that this package was missing on arm64 (making josm uninstallable) so I investigated. 11.0.11+0-1 built OK on 2021-02-03. But 11.0.11+1-3 FTBFS. 11.0.11+0-1 no longer builds either. Failing in: Execution failed for task ':media:buildAVPlugin' ../../../plugins/av/decoder.c:79:5: error: implicit declaration of function 'avcodec_register_all' which seems to be a problem with ffmpeg, but lets ignore that for now - it seems to be fixed with a patch in +1-3 11.0.11+1-3 fails with: [ 28%] Building CXX object Source/JavaScriptCore/CMakeFiles/LLIntOffsetsExtractor.dir/llint/LLIntOffsetsExtractor.cpp.o Gradle is still running, please be patient... In file included from /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssemblerARM64.h:30, from /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/MacroAssembler.h:46, from /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/jit/GPRInfo.h:28, from /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/bytecode/ArithProfile.h:28, from /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/llint/LLIntOffsetsExtractor.cpp:28: /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h: In static member function ‘static void JSC::ARM64Assembler::replaceWithJump(void*, void*)’: /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:2576:51: error: ‘class JSC::ExecutableAllocator’ has no member named ‘getJumpIslandTo’ 2576 | to = ExecutableAllocator::singleton().getJumpIslandTo(where, to); | ^~~ /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h: In static member function ‘static void* JSC::ARM64Assembler::prepareForAtomicRelinkJumpConcurrently(void*, void*)’: /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:2781:49: error: ‘class JSC::ExecutableAllocator’ has no member named ‘getJumpIslandToConcurrently’ 2781 | return ExecutableAllocator::singleton().getJumpIslandToConcurrently(from, to); | ^~~ /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h: In static member function ‘static void JSC::ARM64Assembler::linkJumpOrCall(int*, const int*, void*)’: /<>/modules/javafx.web/src/main/native/Source/JavaScriptCore/assembler/ARM64Assembler.h:3024:51: error: ‘class JSC::ExecutableAllocator’ has no member named ‘getJumpIslandTo’ 3024 | to = ExecutableAllocator::singleton().getJumpIslandTo(bitwise_cast(fromInstruction), to); | ^~~ (Which is actually a different failure point from the one Sebastian posted in this bug) So all this jumpisland stuff comes from webkit's JavaScript JIT. It turns out that this upstream Webkit bug explains what's going on: https://bugs.webkit.org/show_bug.cgi?id=217079 jumpislands allow +-128MB jumps to get to the whole 1GB executable space by having a particular memory layout. And the build should use _either_ the JIT or 'CLOOP', but not both. Applying the patch in that bug (which gates JUMP_ISLANDS on the JIT being enabled, and avoids compiling in a call to dumpJITMemory if JIT is disabled) allows everything to get compiled. However it then fails to link: [100%] Linking CXX shared library ../../lib/libjfxwebkit.so /usr/include/c++/11/ext/new_allocator.h:116: error: undefined reference to 'std::__throw_bad_array_new_length()' collect2: error: ld returned 1 exit status gmake[4]: *** [Source/WebKitLegacy/CMakeFiles/WebKitLegacy.dir/build.make:2237: lib/libjfxwebkit.so] Error 1 Which seems to be a problem with compiling with gcc11/12, but then trying to link to the gcc-libstd++ from gcc10. Removing all the gcc-10 packages from the build environment fixed this. I think this means the package should get a build-conflict on libstdc++-10-dev Also the discussion in the above bug suggests that the JIT should in fact be enabled on debian arm64. It only needs to be turned off on iOS and 64k aarch64 kernel (RHEL). I will test that next. Attached is the debdiff that at least makes the build work again for now. Happy to do an NMU if that's helpful diff -Nru openjfx-11.0.11+1/debian/changelog openjfx-11.0.11+1/debian/changelog --- openjfx-11.0.11+1/debian/changelog 2023-02-07 14:59:22.0 + +++ openjfx-11.0.11+1/debian/changelog 2023-07-14 11:53:33.0 + @@ -1,3 +1,10 @@ +openjfx (11.0.11+1-3.1) UNRELEASED; urgency=medium + + * Non-maintainer upload. + * Apply patch from webkit #217079 so arm64 builds again + + -- Wookey Fri, 14 Jul 2023 11:53:33 + + openjfx (11.0.11+1-3)
Bug#1021894: openjfx: FTBFS on arm64 and armhf
Control: affects -1 src:libjogl2-java src:beast2-mcmc Control: severity -1 serious Hi, I am restoring the severity of this FTBFS bug, which has concrete consequences on several packages. Cheers, -- Pierre OpenPGP_signature Description: OpenPGP digital signature
Bug#1021894: openjfx: FTBFS on arm64 and armhf
Source: openjfx Version: 11.0.11+1-1 Severity: serious Tags: ftbfs Justification: fails to build from source (but built successfully in the past) openjfx FTBFS on arm64 and armhf for some time now. Let's record that in the BTS. https://buildd.debian.org/status/fetch.php?pkg=openjfx=arm64=11.0.11%2B1-1=1651592229=0 :web:compileNativeLinux FAILED :web:compileNativeLinux (Thread[Task worker for ':' Thread 3,5,main]) completed. Took 10 mins 30.851 secs. FAILURE: Build failed with an exception. * Where: Build file '/<>/build.gradle' line: 3922 * What went wrong: Execution failed for task ':web:compileNativeLinux'. > Process 'command 'perl'' finished with non-zero exit value 2 * Try: Run with --debug option to get more log output. Run with --scan to get full insights. * Exception is: org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':web:compileNativeLinux'. at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:100) at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:70) at org.gradle.api.internal.tasks.execution.OutputDirectoryCreatingTaskExecuter.execute(OutputDirectoryCreatingTaskExecuter.java:51) at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:62) at org.gradle.api.internal.tasks.execution.ResolveTaskOutputCachingStateExecuter.execute(ResolveTaskOutputCachingStateExecuter.java:54) at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:60) at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:97) at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:87) at org.gradle.api.internal.tasks.execution.ResolveTaskArtifactStateTaskExecuter.execute(ResolveTaskArtifactStateTaskExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52) at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:54) at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43) at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:34) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker$1.run(DefaultTaskGraphExecuter.java:248) at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:336) at org.gradle.internal.progress.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:328) at org.gradle.internal.progress.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:199) at org.gradle.internal.progress.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:110) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:241) at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter$EventFiringTaskWorker.execute(DefaultTaskGraphExecuter.java:230) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.processTask(DefaultTaskPlanExecutor.java:123) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.access$200(DefaultTaskPlanExecutor.java:79) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:104) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker$1.execute(DefaultTaskPlanExecutor.java:98) at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.execute(DefaultTaskExecutionPlan.java:626) at org.gradle.execution.taskgraph.DefaultTaskExecutionPlan.executeWithTask(DefaultTaskExecutionPlan.java:581) at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor$TaskExecutorWorker.run(DefaultTaskPlanExecutor.java:98) at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:63) at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:46) at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:55) Caused by: org.gradle.process.internal.ExecException: Process 'command 'perl'' finished with non-zero exit value 2 at org.gradle.process.internal.DefaultExecHandle$ExecResultImpl.assertNormalExitValue(DefaultExecHandle.java:382) at
