IRC channel logs
2026-09-04.log
back to list of logs
<GNU_Hurd_Rocks>damo22: you mentioned stuff about Java in the past, was that OpenJDK? <damo22>GNU_Hurd_Rocks: yes, openjdk7 (built using icedtea) <damo22>i have the bootstrapped java 1.7.0 but it hangs on Hurd <damo22>i need to dig into the code more to figure out why <damo22>i would like to get openjdk8 eventually as a minimum <damo22>but i dont have the motivation to do more than that <GNU_Hurd_Rocks>ah I've ended up building openjdk25, will ::gentoo ebuilds for older versions <damo22>wait, you built openjdk25 on hurd? <GNU_Hurd_Rocks>will have to try building with crossdev but I haven't fully set it up yet <damo22>i dont think you can bootstrap openjdkN without openjdk(N-1) on the platform <GNU_Hurd_Rocks>ah, checked logs, emerge (5 of 6) dev-java/openjdk-bin-25.0.4_p7 to / <damo22>i dont understand how that can work, unless someone did the porting work for hurd <damo22>there are C++ components with operating-system specific code <GNU_Hurd_Rocks>setting up a crossdev environment which will take some time unfortunately, since I didn't keep the previous <damo22>no rush, but if you are interested in java it would be good to see what we can get <damo22>i assumed there is no other way to bootstrap except the long way <GNU_Hurd_Rocks>damo22: forgot to mention, there is an ebuild for OpenJDK8 in ::gentoo <damo22>how does it bootstrap java without java? <GNU_Hurd_Rocks>jbootstrap : Build OpenJDK twice, the second time using the result of the first <damo22>ok, thats interesting, but i still cant understand how it builds openjdk without an existing java toolchain <GNU_Hurd_Rocks>I had to do "-system-bootstrap" or it created a circular dependency, although apparently I don't see that USE on my GNU/Linux machine <damo22>hmm maybe it uses the host openjdk to compile java sources? <damo22>since the resulting java classes run on any java vm <damo22>then it can avoid bootstrapping javac from an existing java on the target <damo22>it would be an interesting experiment <damo22>but not sure how we could integrate that into a deb package <GNU_Hurd_Rocks>emerge allows using --sysroot= or SYSROOT= to decide where the package should be installed to, however would probably have to make some changes to configurations to have it work for Debian <GNU_Hurd_Rocks>unfortunately ran into an error unrelated to OpenJDK, debugging it <GNU_Hurd_Rocks>damo22: having issues with definitions not being defined, such as PATH_MAX and MAXPATHLEN <GNU_Hurd_Rocks>would need to somehow debug C includes to know where it was defined but I don't have the tool for that <GNU_Hurd_Rocks>or perhaps I should say it as, how it was included, rather than where it was defined <azeem>the GNU system does not define those <GNU_Hurd_Rocks>I will have to look at how the macros get defined for GNU/Linux to then look for a decent solution that can be applied to GNU/Hurd, azeem, although I should sleep first <sam_>GNU_Hurd_Rocks: no, it's that you shouldn't use such constructs to begin with <sam_>anway, first thing to do is file a bug with pkgconf if it is relying on PATH_MAX <sam_>azeem: sorry, they asked a question in another channel wrt PATH_MAX <damo22>i have a whole stack of changes for java, not just PATH_MAX etc i think you will run into a lot of things <azeem>I managed to capture a build/install tree of a Postgres testsuite run that failed with "invalid page in block 26 of relation "base/4/1255"", see here: <azeem>however, on inspection, it looks like the files are ok (at least the Postgres checksumming client tool does not complain), and the data corruption seems to happen in-memory <GNU_Hurd_Rocks>I have noticed at least one other package that has the same problem, sam_, app-text/libpaper-2.1.3, have not looked at other versions though, it specifically looks for MAXPATHLEN, will report upstream <sam_>GNU_Hurd_Rocks: our libpaper isn't up to date <sam_>but i see you tested upstream sources too <GNU_Hurd_Rocks>I did not test upstream but sort of assumed it would still be there