0.13.0 nativeCompile failing, unable to find index.json #1464
Comments
|
BTW I am definitely using jdk 21, i checked with java --version right before that command. Was using this just fine like a week or so ago when you dropped the 0.12.8 release to fix the version lockout. |
|
@slithernix: Did you do as suggested and add " |
|
My pipeline builds are working too: https://gitlab.com/packaging/signal-cli/-/jobs/6205355371 Ran into another issue with old gcc an arm64 builds, but nothing like this. |
I did that, and the last thing that happens before the error seen above is: then this error (same as above): So, obviously no index.json in the root of the signal-cli project. Now, on a hunch I ran a find /root/.gradle -type f -name index.json, lots of index.json files in there. so it seems like maybe I am missing an environment variable or something and gradle is looking in the working directory when it should be looking somewhere else for that index.json. Ring any bells? |
|
@slithernix: I tried to reproduce the above error message, but to no avail. I'm afraid we'd need more information regarding your build environment to narrow it down (is this the same as the one mentioned by you in discussion #1431?):
|
|
I can do you one better and just make the repo public, give me a few minutes to make sure main has the working 0.12.8 build and then i will show you the diff of me trying to get 13 going |
|
oh i bet it's GRAALVM_HOME dude, gonna try that first before i inundate you with scripts and Dockerfile etc |
|
that didn't seem to help. here is the working Dockerfile for 0.12.8: this is the patch that is applied to gradle The update to .13.0 has me re-arranging some stuff and doing things slightly differently as it appears that libsignal still uses java 17 while signal-cli now uses 21. I'll get you the broken one soon. tried a few differnt things last night to no avail but just wanted to post the working one so you could have a look. |
|
@slithernix : I'll rerun the above locally tonight with and without changing the respective versions to see whether the latter shows the same error message. At first glance, there are |
|
ok so here is the updated version for the 0.13.0. i def see one bug where i set the path since that ${PATH} is evaluated in Docker and expands to probably nothing. i didn't tackle that yet but here is the updated one: and the updated patch file for build.gradle: |
|
A short update: I started with your previous versions of I can now reproduce the consequential error Now I need to figure out what's the reason for the above errors (does not seem to be a cache-related problem, you can remove By the way, the use of One change I'd recommend (to make sure that you exactly reproduce the upstream configuration for a given version of the library) is to first clone the |
|
nice catch on the rust toolchain loading. i've made that modification. now, when you say use another version of graalvm... you mean downloading 17 and 21? i actually tried that and had two separate graalvms, and modified the env like /opt/graal/17 and /opt/graal/21 depending on which phase of the build i was in. iirc i got the same error. pretty puzzled here. lmk if you come up with anything else or think of something else i can try. appreciate the help. |
|
oh, this is sort of a tangent but i've got an alpine project on the horizon and will need to put signal-cli on there. is there some kind of musl issue right now? i def have encountered my share of those when using alpine for various things... |
|
Ok, I replaced Oracle GraalVM with GraalVM CE that we use … ...and still see the same problem. This means that the build environment somehow differs from those we're using, though this really shouldn't be the case given that the working directory contents, caches should be identical/clean. Really strange. I guess I'll have to sleep over that one. 😝 Regarding musl, see discussion #1453. |
|
i have been away from the java world for a long time now, do you think it's possible that somehow the debian openjdk package is affecting things somehow? |
|
No, because it doesn't work even in the absence of said package. My money is on Docker here, seeing the large amount of posts stating problems when using Gradle in conjunction with Docker (and since a GraalVM-based build is a rather complex process, this likely weighs in as well). I'd suggest to simply convert the If you must use Docker, then IMHO the only (time-consuming!) way to pinpoint the cause would be to also start with the above and afterwards try to compare every step Gradle takes inside and outside of Docker. |
|
Lest I forget: It might be worth a shot to compare your own (build) container image with one of the GraalVM Community Edition Container Images, although those use Oracle Linux. |
|
ok i'll probably do a vagrantfile next week or so. i will update this with results. |
|
I'm quite sure that Docker is not the problem as I'm using for both local and pipeline builds on purpose for multiarch. |
|
That's great! If you can share the part that installs/invokes GraalVM, we can compare the resulting Docker layers, which should be much easier! |
Local build instructions: https://gitlab.com/packaging/signal-cli/-/blob/master/DEV.md |
|
Figured it's about time to make a new build of signal-cli and still getting this weird index.json error.
i took a look here and i don't see really what could be a substantial difference to cause this. the libsignal compile is working fine. any idea what creates index.json in the root of the signal-cli repo? the only thing i see that maybe might have something to do with it is REFLECT_CONFIG. i have even run find / -type f -name index.json, it doesn't exist at all anywhere. |
Got this weird exception related to some type of dependency for an index.json in the root of the checkout... I grep'd for index.json no mention of it anywhere I could find so I don't really know what would pull that in and what requires it. Here is the stacktrace:
The text was updated successfully, but these errors were encountered: