JDK version 6

DJ Lucas dj at linuxfromscratch.org
Fri Jul 13 16:33:06 PDT 2007

Randy McMurchy wrote:
> DJ Lucas wrote these words on 07/12/07 16:21 CST:
>> http://www.linuxfromscratch.org/~dj/blfs-book-xsl/index.html
>> or the book diff is also in my homedir. OOo-2.2.1 is there too.
> As far as the JDK 6, here's some notes about your first cut:
Sweet, thanks for the tips.
> 1. The "official" build recipe from Sun says to use the JDK version 5
> as the bootstrap JDK. I never tried to use version 6 as the bootstrap,
> but since you have, and it builds, we may as well use it.  
Immediately after the Bootstrap JDK blurb the build instructions say
this:  'Note that the Bootstrap JDK can be a newer JDK, and in fact you
could make the Bootstrap JDK and the Import JDK (described below) the
same. There is some risk in this approach if the Bootstrap JDK you
choose happens to be unstable.'
> 2. As you mention, the download URLs for the source need to be updated.
> 3. The GCC patch should probably be at a -2 revision level, indicating
> a difference in your original.
It'll probably have to be rediffed anyway, I think they got the '>
/dev/null' added in the compiler check when we get the new sources.
> 4. CUPS is now a *required* dependency. You left that off.
Oops, thank you.
> 5. I would prefer (my own preference, however, not required) if the 3
> seds and 3 patches were placed in the main body of the instructions to
> facilitate easy cut and paste. Then use the "command explanation"
> section for the very fine text you created.
> 6. Best as I could tell, the 3 chmod commands after copying the image
> into place are not necessary any longer. All the permissions seem
> correct without them.
I built it as root and thus had no way to check it so I left them alone.
> 7. Is the Xinerma sed used on the binary installation not required
> after building? Additionally, staticly is misspelled. Use statically.
No, this is because they are linked against an old libX11 (specifically
the one from XFree86 of RedHat AS 2.1).  When we build the motif
project, we link dynamically as part of an old fix for early xorg
(6.8.?) where the static libs were not installed.  This fix had remained
part of the motif fixes patch by accident.  It is fortunate, however,
that the unneeded (but generally desirable) patch explained the
difference between the binary and source results when testing in a
Xinerama environment.  I decided to leave it in place as we already do
this with gcc, but there are probably more places to find yet.
> 8. The support text for this var (export BUILD_NUMBER="b02-u02") says
> it is the same as Sun. Best as I can tell, Sun just uses "b2" or "b?"
> with ? being a number. I'm going on info on the "build instructions"
> page of the Sun site.
What I had was correct in earlier ea revisions, I'm not sure when they
changed it.  Look at the plugin information or the output of 'java
-version' on the official releases.  They now use 1.6.0_02-b05 for the
build string, which I don't know how to mimic ATM.  I'm sure I could
find it, but it does need to differ from the official one anyway.  Ours
as it is now winds up being 1.6.0-BLFS-internal-b05-u02.  I can and
should ditch the 'internal' part, that is just what happens if you leave
it blank.  How about a  milestone of '02-BLFS' and 'b05' for the build? 
That gives us 1.6.0-02-BLFS-b05 for the version string (notice the dash
instead of the underscore between version and update level, this is what
I don't know where to fix).
> 9. (This is only a pet peeve of mine, and has bothered me since I've
> been building the JDK using BLFS instructions). I don't care for the
> /opt/jdk/jdk path. I just use /opt/jdk-version-precompiled and
> /opt/jdk-6u2. Then a link (/opt/jdk) to whatever version I'm using.
Yes, I think so too.  /opt/sun/jdk-version would be allowed, but it's
not FHS compliant as it is now (at least if you follow the spec
verbatim, 'jdk' is not a 'vendor').  It also differs from anything else
that we install in /opt which is the more important reason to change it.
> Hope this helps.
It does.  Thanks.

-- DJ Lucas

More information about the blfs-dev mailing list