[Master] Build fails after d6bc920e056baad7782f47b86cba85d1336bb134 - Class not found #24225
Closed
6 tasks
Labels
Triage: Needed
(managed by bot!) issue that was just created and needs someone looking at it
Comments
xbmc-gh-bot
bot
added
the
Triage: Needed
coffeinflash
changed the title
|
No idea sorry. Ive made same folder structure for the groovy/commons extractions, and it doesnt fail locally, cant see build log, dont know how opensuse builders work. Can you actually check the workspace has the folders extracted/located as intended? |
|
Only way i can get it to fail is to intentionally give an incorrect path to the groovy extraction So im guessing your builder isnt packaging/extracting the groovy zip file for whatever reason. |
|
Yes, you are/were right. |
|
So this is no kodi issue. |
|
It looks like this is a potential bug with JDK11. I can reproduce this on x86_x64 on Debian Bullseye. Oddly I cannot reproduce this with the same build environment on armv7. Both build environments are identical with the x86_x64 one simply running as a QEMU chroot. On x86_x64: On ARMv7: |
|
@samnazarko aarch64 runs without issues but, armv7hf is not picking up path spec: aarch64 output: armv7f: tested with jre17,21,22 openjdk and started to think this is more an issue of qemu side. my elf configs for qemu: armv7h: aarhc64: could you find a solution? |
|
What distribution are you using in the container?
Cheers
Sam
On 13 May 2024, at 22:57, Hüseyin BIYIK ***@***.***> wrote:
@samnazarko<https://github.com/samnazarko>
i reproduced the same error with a twist.
I have 2 containers running both with qemu-user-static, one is armv7hf, the other one is aarch64.
aarch64 runs without issues but, armv7hf is not picking up path spec:
cmd: _JAVA_LAUNCHER_DEBUG=true /usr/bin/java -cp "build/share/groovy/lib/*" groovy.ui.GroovyMain
aarch64 output:
…----_JAVA_LAUNCHER_DEBUG----
Launcher state:
First application arg index: 4
debug:on
javargs:off
program name:java
launcher name:openjdk
javaw:off
fullversion:17.0.11+9
Java args:
Command line args:
argv[0] = /usr/bin/java
argv[1] = -cp
argv[2] = build/share/groovy/lib/*
argv[3] = groovy.ui.GroovyMain
JRE path is /usr/lib/jvm/java-17-openjdk
jvm.cfg[0] = ->-server<-
jvm.cfg[1] = ->-client<-
1721 micro seconds to parse jvm.cfg
Default VM: server
Does `/usr/lib/jvm/java-17-openjdk/lib/server/libjvm.so' exist ... yes.
mustsetenv: FALSE
JVM path is /usr/lib/jvm/java-17-openjdk/lib/server/libjvm.so
39230 micro seconds to LoadJavaVM
Expanded wildcards:
before: "build/share/groovy/lib/*"
after : "build/share/groovy/lib/junit-4.13.2.jar:build/share/groovy/lib/groovy-4.0.16.jar:build/share/groovy/lib/commons-cli-1.6.0.jar:build/share/groovy/lib/multiverse-core-0.7.0.jar:build/share/groovy/lib/groovy-contracts-4.0.16.jar:build/share/groovy/lib/groovy-astbuilder-4.0.16.jar:build/share/groovy/lib/groovy-toml-4.0.16.jar:build/share/groovy/lib/groovy-console-4.0.16.jar:build/share/groovy/lib/groovy-test-4.0.16.jar:build/share/groovy/lib/groovy-ant-4.0.16.jar:build/share/groovy/lib/jackson-dataformat-yaml-2.16.0.jar:build/share/groovy/lib/ant-junit-1.10.14.jar:build/share/groovy/lib/groovy-sql-4.0.16.jar:build/share/groovy/lib/snakeyaml-2.2.jar:build/share/groovy/lib/groovy-yaml-4.0.16.jar:build/share/groovy/lib/junit-jupiter-engine-5.10.1.jar:build/share/groovy/lib/mxparser-1.2.2.jar:build/share/groovy/lib/junit-platform-commons-1.10.1.jar:build/share/groovy/lib/jackson-core-2.16.0.jar:build/share/groovy/lib/groovy-test-junit5-4.0.16.jar:build/share/groovy/lib/testng-7.5.1.jar:build/share/groovy/lib/jcommander-1.78.jar:build/share/groovy/lib/org.abego.treelayout.core-1.0.3.jar:build/share/groovy/lib/ant-1.10.14.jar:build/share/groovy/lib/groovy-jsr223-4.0.16.jar:build/share/groovy/lib/groovy-docgenerator-4.0.16.jar:build/share/groovy/lib/groovy-ginq-4.0.16.jar:build/share/groovy/lib/groovy-dateutil-4.0.16.jar:build/share/groovy/lib/opentest4j-1.3.0.jar:build/share/groovy/lib/ivy-2.5.2.jar:build/share/groovy/lib/jackson-databind-2.16.0.jar:build/share/groovy/lib/ant-launcher-1.10.14.jar:build/share/groovy/lib/groovy-groovydoc-4.0.16.jar:build/share/groovy/lib/junit-platform-launcher-1.10.1.jar:build/share/groovy/lib/groovy-json-4.0.16.jar:build/share/groovy/lib/groovy-typecheckers-4.0.16.jar:build/share/groovy/lib/jsr166y-1.7.0.jar:build/share/groovy/lib/groovy-xml-4.0.16.jar:build/share/groovy/lib/jansi-2.4.1.jar:build/share/groovy/lib/groovy-cli-commons-4.0.16.jar:build/share/groovy/lib/groovy-datetime-4.0.16.jar:build/share/groovy/lib/groovy-jmx-4.0.16.jar:build/share/groovy/lib/groovy-servlet-4.0.16.jar:build/share/groovy/lib/xstream-1.4.20.jar:build/share/groovy/lib/jackson-dataformat-toml-2.16.0.jar:build/share/groovy/lib/jquery-3.5.1.jar:build/share/groovy/lib/groovy-swing-4.0.16.jar:build/share/groovy/lib/junit-platform-engine-1.10.1.jar:build/share/groovy/lib/groovy-nio-4.0.16.jar:build/share/groovy/lib/groovy-macro-4.0.16.jar:build/share/groovy/lib/groovy-templates-4.0.16.jar:build/share/groovy/lib/groovy-macro-library-4.0.16.jar:build/share/groovy/lib/junit-jupiter-api-5.10.1.jar:build/share/groovy/lib/ant-antlr-1.10.14.jar:build/share/groovy/lib/slf4j-api-2.0.9.jar:build/share/groovy/lib/gpars-1.2.1.jar:build/share/groovy/lib/groovy-groovysh-4.0.16.jar:build/share/groovy/lib/javaparser-core-3.25.6.jar:build/share/groovy/lib/jline-2.14.6.jar:build/share/groovy/lib/qdox-1.12.1.jar:build/share/groovy/lib/groovy-cli-picocli-4.0.16.jar:build/share/groovy/lib/groovy-testng-4.0.16.jar:build/share/groovy/lib/hamcrest-core-1.3.jar:build/share/groovy/lib/jackson-annotations-2.16.0.jar"
armv7f:
----_JAVA_LAUNCHER_DEBUG----
Launcher state:
First application arg index: 4
debug:on
javargs:off
program name:java
launcher name:openjdk
javaw:off
fullversion:21.0.2+13
Java args:
Command line args:
argv[0] = /usr/bin/java
argv[1] = -cp
argv[2] = /home/boogie/.agr/packages/boogie/kodi-mpp-git/src/kodi-build/build/share/groovy/lib/*
argv[3] = groovy.ui.GroovyMain
JRE path is /usr/lib/jvm/java-21-openjdk
jvm.cfg[0] = ->-server<-
jvm.cfg[1] = ->-client<-
1596 micro seconds to parse jvm.cfg
Default VM: server
Does `/usr/lib/jvm/java-21-openjdk/lib/server/libjvm.so' exist ... yes.
mustsetenv: FALSE
JVM path is /usr/lib/jvm/java-21-openjdk/lib/server/libjvm.so
24576 micro seconds to LoadJavaVM
Expanded wildcards:
before: "/home/boogie/.agr/packages/boogie/kodi-mpp-git/src/kodi-build/build/share/groovy/lib/*"
after : "/home/boogie/.agr/packages/boogie/kodi-mpp-git/src/kodi-build/build/share/groovy/lib/*"
JavaVM args:
version 0x00010002, ignoreUnrecognized is JNI_FALSE, nOptions is 4
option[ 0] = '-Dsun.java.launcher.diag=true'
option[ 1] = '-Djava.class.path=/home/boogie/.agr/packages/boogie/kodi-mpp-git/src/kodi-build/build/share/groovy/lib/*'
option[ 2] = '-Dsun.java.command=groovy.ui.GroovyMain'
option[ 3] = '-Dsun.java.launcher=SUN_STANDARD'
382295 micro seconds to InitializeJVM
Main class is 'groovy.ui.GroovyMain'
App's argc is 0
Error: Could not find or load main class groovy.ui.GroovyMain
Caused by: java.lang.ClassNotFoundException: groovy.ui.GroovyMain
java.lang.ClassNotFoundException: groovy.ui.GroovyMain
at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:641)
at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:526)
at java.base/java.lang.Class.forName0(Native Method)
at java.base/java.lang.Class.forName(Class.java:534)
at java.base/java.lang.Class.forName(Class.java:513)
at java.base/sun.launcher.LauncherHelper.loadMainClass(LauncherHelper.java:797)
at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:692)
tested with jre17,21,22 openjdk and started to think this is more an issue of qemu side.
my elf configs for qemu:
armv7h:
`:qemu-arm:M::\\x7fELF\\x01\\x01\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x02\\x00\\x28\\x00:\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\xfe\\xff\\xff\\xff:/usr/bin/qemu-arm-static:FPC`
aarhc64:
`:qemu-aarch64:M::\\x7fELF\\x02\\x01\\x01\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x00\\x02\\x00\\xb7\\x00:\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\x00\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xff\\xfe\\xff\\xff\\xff:/usr/bin/qemu-aarch64-static:FPC\n`
could you find a solution?
—
Reply to this email directly, view it on GitHub<#24225 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHDWLD65PWVC7XOJMDWYT3ZCEZNFAVCNFSM6AAAAABARC6COGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBYHA3TCMRSGE>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
@samnazarko |
|
Thanks. To be honest we are moving to ARM64 userland shortly and a revert of the commit is good enough for v21 so not sure how much time I will put in to this.
It’s also not one I would know where to look at. I know QEMU has a few quirks. Would be curious if it works where both host and container are 32-bit. If this is the case I think I have an idea of the problem
Sam
On 13 May 2024, at 23:11, Hüseyin BIYIK ***@***.***> wrote:
@samnazarko<https://github.com/samnazarko>
the rootfs in container is archlinux arm.
host is archlinux.
—
Reply to this email directly, view it on GitHub<#24225 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHDWLGKCIOMPD277NQORC3ZCE3APAVCNFSM6AAAAABARC6COGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBYHA4DSNJTGQ>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
thanks for the tips, i think i made a progress... i copied jars to /tmp (tempfs) folder, it works from there. the original path which does not work was an overlay mounted path
so something seems to be fishy there. |
|
btw i am using systemd-nspawn if it would matter, and somehow i am now suspucious about those inodes things. purely speculative though. |
|
We use a bind mount and then straight chroot
On 13 May 2024, at 23:37, Hüseyin BIYIK ***@***.***> wrote:
@samnazarko<https://github.com/samnazarko>
thanks for the tips, i think i made a progress...
i copied jars to /tmp folder, it works from there.
the original path which does not work was an overlay mounted path
overlay on /home type overlay (rw,relatime,lowerdir=/home/boogie/.agr/containers/alarm-armv7h/alarm-armv7h/home,upperdir=/home/boogie/.agr/containers/alarm-armv7h/overlays/home,workdir=/home/boogie/.agr/containers/alarm-armv7h/overlays/.#homecfe90636e6c3f273,index=off,xino=off)
so something seems to be fishy there.
—
Reply to this email directly, view it on GitHub<#24225 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAHDWLFXMAXTIWGLD7NCHMDZCE6CPAVCNFSM6AAAAABARC6COGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDCMBYHEYTQOJRGU>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
|
Here is summary of my investigation: The issue is triggered when java is used in containerized environment. Workarounds: For ext4 mounting to container, i could not find a workaround. General workaround in Kodi Buildsystem is to point directly to jar files instead of using wildcards. here is a patch diff --git a/xbmc/interfaces/swig/CMakeLists.txt b/xbmc/interfaces/swig/CMakeLists.txt
index 0d0cadc..60e5739 100644
--- a/xbmc/interfaces/swig/CMakeLists.txt
+++ b/xbmc/interfaces/swig/CMakeLists.txt
@@ -1,7 +1,9 @@
function(generate_file file)
- set(classpath ${groovy_SOURCE_DIR}/lib/*
- ${apache-commons-lang_SOURCE_DIR}/*
- ${apache-commons-text_SOURCE_DIR}/*
+ set(classpath ${groovy_SOURCE_DIR}/lib/groovy-${GROOVY_VER}.jar
+ ${groovy_SOURCE_DIR}/lib/groovy-xml-${GROOVY_VER}.jar
+ ${groovy_SOURCE_DIR}/lib/groovy-templates-${GROOVY_VER}.jar
+ ${apache-commons-lang_SOURCE_DIR}/commons-lang3-${APACHE_COMMONS_LANG_VER}.jar
+ ${apache-commons-text_SOURCE_DIR}/commons-text-${APACHE_COMMONS_TEXT_VER}.jar
${CMAKE_SOURCE_DIR}/tools/codegenerator
${CMAKE_CURRENT_SOURCE_DIR}/../python)
if(NOT CORE_SYSTEM_NAME STREQUAL windows AND NOT CORE_SYSTEM_NAME STREQUAL windowsstore)
@fuzzard @samnazarko do you think above patch makes sense to PR, this is how it was working before commit d6bc920 Regardless of my findings above i have seen other complaints that openjdk can not find jar files when wildcards are used, so may be having the patch is a little bit more defensive to future whatever problem... |
|
Thanks for investigating. Yes -- I suspected an architecture mismatch would be the cause of this problem; and it explains why building on an ARM system doesn't exhibit these symptoms. I think the proposed change is acceptable and worthy of a PR. |
14 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug report
Describe the bug
Building the latest master fails after d6bc920 .
The required groovy class(es) cannot be found.
I am building kodi packages for openSUSE using OBS: https://build.opensuse.org/package/show/home:Herbster0815:HTPC:Test/kodi
During the build there is no network connection so the required zips containing the needed java libraries can not be downloaded.
As stated in d6bc920 I added the source directories to cmake configuration:
Complete spec-file: https://build.opensuse.org/package/view_file/home:Herbster0815:HTPC:Test/kodi/kodi.spec?expand=0
Except from spec-file:
(...)
Source12: http://mirrors.kodi.tv/build-deps/sources/apache-groovy-binary-4.0.16.zip
Source13: http://mirrors.kodi.tv/build-deps/sources/commons-lang3-3.14.0-bin.tar.gz
Source14: http://mirrors.kodi.tv/build-deps/sources/commons-text-1.11.0-bin.tar.gz
(...)
unzip -q %{SOURCE12}
tar xzf %{SOURCE13}
tar xzf %{SOURCE14}
(...)
%cmake
-DVERBOSE=ON
-DCMAKE_BUILD_TYPE=Release
-DCORE_SYSTEM_NAME=linux
-DAPP_RENDER_SYSTEM=gles
-DCORE_PLATFORM_NAME=gbm
-DGIT_VERSION="%{_git_version}"
-DENABLE_EVENTCLIENTS=ON
-DENABLE_INTERNAL_CROSSGUID=OFF
-DENABLE_INTERNAL_CDIO=OFF
-DENABLE_INTERNAL_FLATBUFFERS=OFF
-DENABLE_INTERNAL_FMT=OFF
-DENABLE_INTERNAL_FSTRCMP=OFF
-DENABLE_INTERNAL_RapidJSON=OFF
-DENABLE_INTERNAL_SPDLOG=OFF
-DENABLE_INTERNAL_DAV1D=ON
-DDAV1D_URL="%{SOURCE11}"
-DENABLE_INTERNAL_UDFREAD=ON
-DUDFREAD_URL="%{SOURCE10}"
-Dgroovy_SOURCE_DIR="%{buildroot}"/groovy-4.0.16
-Dapache-commons-lang_SOURCE_DIR="%{buildroot}"/commons-lang3-3.14.0
-Dapache-commons-text_SOURCE_DIR="%{buildroot}"/commons-text-1.11.0
-DENABLE_INTERNAL_GTEST=OFF
-DENABLE_INTERNAL_KISSFFT=OFF
-DENABLE_INTERNAL_TINYXML2=OFF
-DENABLE_AIRTUNES=OFF
-DENABLE_DVDCSS=OFF
-DENABLE_PULSEAUDIO=OFF
-DENABLE_PIPEWIRE=OFF
-DENABLE_MYSQLCLIENT=OFF
-DENABLE_MARIADBCLIENT=ON
-DENABLE_GOLD=OFF
-DENABLE_MOLD=OFF
-DENABLE_INTERNAL_FFMPEG=ON
-DFFMPEG_URL="%{SOURCE9}"
-DENABLE_INTERNAL_CEC=OFF
-DENABLE_INTERNAL_NFS=OFF
-DENABLE_INTERNAL_PCRE=OFF
-DENABLE_INTERNAL_TAGLIB=OFF
-DENABLE_OPENGLES=ON
-DENABLE_VAAPI=ON
-DENABLE_VDPAU=OFF
-DUSE_LTO=ON
-DBUILD_SHARED_LIBS=1
-DENABLE_TESTING=OFF
-DENABLE_DEBUGFISSION=OFF
Expected Behavior
Building from source shoud find all java classed and succeed.
Actual Behavior
Building fails:
To me it seems the classpath is set correctly but nevertheless the groovy classed cannot be found:
-cp /home/abuild/rpmbuild/BUILDROOT/kodi-21.x.+git.20231211T201719~e62709b37-62.1.x86_64/groovy-4.0.16/lib/*:/home/abuild/rpmbuild/BUILDROOT/kodi-21.x.+git.20231211T201719~e62709b37-62.1.x86_64/commons-lang3-3.14.0/*:/home/abuild/rpmbuild/BUILDROOT/kodi-21.x.+git.20231211T201719~e62709b37-62.1.x86_64/commons-text-1.11.0/*Possible Fix
No idea at the moment.
To Reproduce
Try to build a kosi rpm with sources and spec file from https://build.opensuse.org/package/show/home:Herbster0815:HTPC:Test/kodi
Debuglog
The buildlog can be found here: https://build.opensuse.org/build/home:Herbster0815:HTPC:Test/openSUSE_Tumbleweed/x86_64/kodi/_log
Screenshots
Additional context or screenshots (if appropriate)
Here is some additional context or explanation that might help:
Your Environment
Used Operating system:
Android
iOS
tvOS
[x ] Linux
macOS
Windows
Windows UWP
Operating system version/name:
Kodi version: kodi-21.x.+git.20231211T201719~e62709b37
note: Once the issue is made we require you to update it with new information or Kodi versions should that be required.
Team Kodi will consider your problem report however, we will not make any promises the problem will be solved.
The text was updated successfully, but these errors were encountered: