> On Nov 8, 2021, at 8:15 AM, Jonathan Perkin <jperkin%joyent.com@localhost> wrote: > > * On 2021-11-08 at 12:42 GMT, Christos Zoulas wrote: > >>> Ok, so just fix that? If you have a look at the openjdk packages I use for SmartOS, e.g.: >>> >>> https://github.com/joyent/pkgsrc-joyent/tree/master/openjdk11 >>> >>> you can see that I do not have that LD_LIBRARY_PATH setting, and instead have correctly patched each call site to ensure it pulls in the correct libraries. It would be trivial for someone to >>> make similar changes to the NetBSD package. >> >> Then it does not work for bootstrap and it is too complicated. The fact that we have to patch the jdk in many places should be a strong hint that we are are doing something wrong. > > The number of patches to use LD_LIBRARY_PATH is actually very small. If you are simply counting the number of files in the patches/ directory then please understand that the vast majority of them > are because Oracle removed GCC support for Solaris/illumos, not for LD_LIBRARY_PATH: > > $ git grep -l LD_LIBRARY_PATH openjdk11 > openjdk11/patches/patch-make_GenerateLinkOptData.gmk > openjdk11/patches/patch-make_autoconf_spec.gmk.in I was looking at all the places where we interfered with the linking lines. >> Anyway, as you have seen, nobody has attempted to build anything > jdk11 for years just because the whole process is such an unholy mess. > > False: > > https://github.com/joyent/pkgsrc-joyent/tree/master/openjdk12 > https://github.com/joyent/pkgsrc-joyent/tree/master/openjdk13 > https://github.com/joyent/pkgsrc-joyent/tree/master/openjdk14 > https://github.com/joyent/pkgsrc-joyent/tree/master/openjdk15 > Where are the NetBSD packages? >> In fact I don't think that anyone will be able to without following my approach or suffering for days and creating an abomination. > > I like to think that my updated packages are actually very clean, and certainly an improvement over the main pkgsrc ones, rather than being an abomination. That could be the case, but there are no NetBSD ones. I thought PKGSRC was supposed to be OS neutral and maintained in a single place, but I can see now this is not the case. >> I was very temped to rewrite that whole mess which appears to be written by a first year undergrad student who just learned c. It is a probably a thousand lines longer than it has to be. It also >> looks like someone kept finding corner cases that were not handled and instead of re-thinking the whole approach kept adding special case code. Nobody can maintain such code. > > Ok, I think we're done here. I'm incredibly grateful to Joerg for writing cwrappers and improving the performance of pkgsrc by an insane amount, as well as enforcing stricter behaviour. If you > have legitimate improvements to the code then I'm sure we would all be interested to see them up for review. I am also grateful for cwrappers existing, but was not grateful when I had to go through the implementation to figure out where it was doing what. I see that you have packages for each one of the versions which indicates to me that you used the previous version to bootstrap the next one. Have you tried to bootstrap from something else, like linux and it worked? Going from 11 to 16 and 17 and needing to build 13 and 15 is no fun, specially if you are not planning to use them... Finally can you please explain your statement that $ORIGIN is unpredictable? christos
Attachment:
signature.asc
Description: Message signed with OpenPGP