<oriansj>rekado: absolutely agreed. I'm tired of it. ***Server sets mode: +cnt
***Server sets mode: +cnt
***Server sets mode: +cnt
***theruran_ is now known as theruran
***ChanServ sets mode: +o rekado_
<rekado_>found something. The problem lies with icedtea-2.6.13/openjdk.build-boot/j2sdk-image/jre/lib/resources.jar, which looks wrong <rekado_>first element in that zip file is called “META-INF/,” followed by some unprintable characters <rekado_>and it also has two entries for META-INF/MANIFEST.MF, different sizes, same name <rekado_>it also contains things that I wouldn’t have expected: makefiles, for example <rekado_>so my next step is to figure out how it’s created <stikonas>rekado_: hmm, it might be that I didn't hit it because I didn't rm -rf *.jar as Guix does <stikonas>which is the correct thing to do but might explain why I didn't spot it <stikonas>hmm, it's only openjdk 9 and newer ebuild that do (for-each delete-file (find-files "." ".*.(bin|exe|jar)$")) <rekado_>stikonas: turns out that the problem does not happen when I use gjar from GNU classpath. <rekado_>so I got past the build phase with gjar. Still gotta fix the keystore phase. <rekado_>not sure what to do about gtk and all that. <rekado_>I don’t want to add gtk to the inputs, because this is just a bootstrap build. But when I remove gtk I need to allow icedtea to use the included header files. <rekado_>I’d prefer not to build any of that stuff at all. <rekado_>all I care about is the subset I need to build the next JDK <rekado_>I thought I had built icedtea@3 already with this new icedtea@2, but now I’m getting “error: package sun.security.action does not exist” during the build of icedtea@3. <rekado_>I guess this means that some required parts of icedtea@2 weren’t built. <stikonas>although, disabling gtk shouldn't really cause this <stikonas>rekado_: and you are still doing two stage build of icedtea@2? <stikonas>or to be more precise, --enable-bootstrap in configure <rekado_>I added gtk back in, but it’s the same. <rekado_>gotta grep the sources a little more to figure out what provides sun.security.action, and why it’s not there. <rekado_>when I build icedtea@3 with “--disable-bootstrap” it builds fine, but jre/lib/amd64/libsaproc.so retains a reference to icedtea@2, which I’d like to avoid. <rekado_>don’t know what tha library is and why it has a reference to icedtea@2 <stikonas>but in the end I think you should use --enable-bootstrap <stikonas>but this information might be useful for debugging purpose <rekado_>the only reference appears to be the name of the “include” directory of the old JDK. <rekado_>gotta figure out where that’s embedded, but it seems that this is not a big deal <rekado_>why would it be better to use --enable-bootstrap for the second real JDK? <rekado_>(that’s what I’m using in the old bootstrap, but for the new bootstrap that bypasses icedtea 1 I thought I’d try to further reduce build times) <stikonas>well, icedtea@3 is used as production JRE... <stikonas>so it might be better to build it with itself <stikonas>rekado_: btw, are you building icedtea 3.7.0? <rekado_>oh, I didn’t know there are newer versions <stikonas>yeah, I'm trying to update my overlay from 3.7.0 to 3.21 too <stikonas>although, I'm still trying to add musl patches for 3.21 (glibc build does work for me) but that's not relevant for guix <rekado_>about sun.security.action: the lib/rt.jar of icedtea@2 contains it, but the javac of the bootstrap JDK explicitly sets the classpath to *its* bootstrap JDK, i.e. jamvm’s lib/rt.jar and GNU Classpath. <rekado_>pretty obvious mistake; just gotta figure out where I made it… <stikonas>so are you building icedtea@2 without bootstrap? <rekado_>no, I am building it with --enable-bootstrap <stikonas>I would have thought icedtea@2 should have no references to jamvm and classpath later <stikonas>well, you can try pushing your wip code, I can try to review <stikonas>hmm, not sure what it can be... The only thing that comes to my mind is somehow results of first compilation are installed rather than second one... <rekado_>I think it’s a side-effect of using gexps in build phases <rekado_>icedtea@3 inherits a build phase from icedtea@2 that sets the CLASSPATH <stikonas>well, let's see if that helps. Although, it would probably be good to bump icedtea-8 to 3.21.9 anyway <rekado_>yes, I’ll first build it as is and then upgrade separately. <rekado_>there are already too many changes in my worktree <rekado_>before I went MIA I had actually worked on reducing the Java bootstrap by building only selected parts of icedtea 6, package by package <stikonas>well, ecj-4 should be much faster than icedtea-6 anyway <rekado_>I had grown tired of the long builds, and I felt uncomfortable with building all those things we don’t really want. <rekado_>yeah, going through ecj4 was a very good idea <rekado_>yeah, I didn’t realize how good we had it with the Java bootstrap, hah :) <stikonas>although mrustc is at least able to catch up eventually <stikonas>with java we just get new versions and probably won't be able to skip icedtea 2 ever... <rekado_>gotta go now, but I’ll report back later