On 09/09/2010 04:47 AM, Wayne Blaszczyk wrote: > DJ, > Good job on IcedTea.
TY Just gonna answer each question so that there is something in the archive to make the instructions more clear in the interim. > I did have a few questions/points. (I haven't built this yet) > I was confused with where to unpack the 'drops'. Drops do not get unpacked. The IcedTea build does the unpacking and reassembles the individual packages into one source tree (as is with the proprietary JDK and with SCSL/JRL sources). > I think you should explicitly state that you are unpacking the source of > IcedTea since it's in the middle of the installation instructions. Yes. Will do. > The starting point of the installation instructions is in the unpacked > binary package root directory? I thought that this would be like any other package, however, I think I've leaned too much on the old SCSL/JRL instructions. In that case, it was a self extracting bin file. Will add something to that effect. > Can IcedTea source be built without installing the IcedTea binary? or > does it require a JRE? if so, can it be the JDK package? Not just the runtime environment, but a full SDK. IcedTea can actually be built with gcj (with the included classpath), but you'll have to provide a fake jvm root of some sort to do so currently. RedHad has a java-gcj-compat package (instructions are in the wiki for JDK). Typically, distros have been using /usr/lib/jvm/java-gcj-1.5.0/ and including symlinks to the typical locations to simulate a JAVA_HOME. I haven't tried to use the proprietary JDK to build it. It should work (it is mostly the same code, in fact compiler and hostspot are identical so should produce identical results), but that kinda defeats the purpose of having a fully free Java SDK whether it be for political stance, jurisdictional restrictions, local policy, etc.. The binary that I've provided has been through three iterations using only free software (gcj - icedtea-1.8.1 - 1.9.0 - 1.9.0). > I would have preferred to see the Package Information section formatted > to the consistency of the other packages, i.e. Having the section title > called 'Package Information' with IcedTea source package as the main > tarball and the rest, including the binary file under the 'Additional > Download' section. I'm sure the ALFS team would be more happy with that. Again, I went with the style of the existing JDK instructions. Even when SCSL and JRL sources were present, most people only ever installed the binary, which is why I've backported the --with-jdk-home changes form head so that we could use similar instructions (and not jump through hoops to make gcj work). Next is to see if we can eliminate the external jars (this should already be possible). I wanted to leave the option in there for the bin installation (as it has always been with JDK), plus the reciprocal dependency for Ant (and that in itself is fun with gcj) would make it even more difficult to explain and do a removal in the middle. This also gives us the option of using Alien or similar to pull one that has been put through the full JCK by RedHat or Canonical so that we too can "claim" compatibility with the proprietary JDK and use the copyrighted name in the future. There will probably be more changes coming, but nothing functional. For instance, the man page for javaws is for the proprietary JDK, not for NetX. A proper man page was just added in head today. > Regards, > Wayne. -- This message has been scanned for viruses and dangerous content, and is believed to be clean. -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
