JDK 7 build 24 is available at the openjdk.java.net website
Anthony.Petrov at Sun.COM
Sun Dec 23 18:48:25 UTC 2007
Concerning the libpng trouble at the 64-bit environment: this is a known
issue, and it had already been fixed, though not integrated yet. I hope
that it will hit the master repository as soon as pushes are allowed.
PS. Yes, even Sun employees cannot push their fixes into the JDK 7 yet. :)
On 12/23/2007 6:48 PM Arnd-Hendrik Mathias wrote:
> Hi Andreas,
> Andreas Sterbenz wrote:
>> See below output of a rebuild of make/javax/crypto after a previous
>> build of a fresh clone of the Mercurial jdk repository. If you see
>> something different, that must be related to your build environment,
>> e.g. version of make used, out of date binary plugs, etc.
> Since my output looked quite different, it was not really comparable
> with the correct output you posted. After further examination of the
> make-/build environment, I found out that the make environment assumes
> some tools to reside in /usr/bin per default. I found that this can be
> overwritten by the ALT_USRBIN_PATH variable. However, if tools reside in
> different directories (/bin /usr/bin ...) setting
> ALT_USRBIN_PATH= <empty>
> and having the PATH variable set to have all these tools available
> directly may be the method the most likely to work. In my special case
> "head" was missing, residing in /bin on my system.
> After changing this setting jdk7 build process ran a bit longer, until
> it ran into another problem:
> Linking of a mass of object files from the jdk/make/sun/splashscreen
> directory results in a number of missing symbols from the png library:
> /opt/jdk/openjdk-1.7.0_b24/tmp/sun/sun.awt/splashscreen/obj64/png.o: In
> function `png_init_mmx_flags':
> png.c:(.text+0xbc): undefined reference to `png_mmx_support'
> In function `png_push_process_row':
> pngpread.c:(.text+0x89e): undefined reference to `png_read_filter_row'
> pngpread.c:(.text+0x964): undefined reference to `png_do_read_interlace'
> In function `png_progressive_combine_row':
> pngpread.c:(.text+0x141): undefined reference to `png_combine_row'
> In function `png_read_row':
> pngread.c:(.text+0xb64): undefined reference to `png_combine_row'
> pngread.c:(.text+0xb79): undefined reference to `png_combine_row'
> pngread.c:(.text+0xc20): undefined reference to `png_read_filter_row'
> pngread.c:(.text+0xc6a): undefined reference to `png_combine_row'
> pngread.c:(.text+0xc92): undefined reference to `png_combine_row'
> pngread.c:(.text+0xc9f): undefined reference to `png_do_read_interlace'
> pngread.c:(.text+0xd10): undefined reference to `png_combine_row'
> collect2: ld returned 1 exit status
> Extending the OTHER_LDLIBS variable in the
> jdk/make/sun/splashscreen/Makefile by
> helps to remove the undefined reference to `png_mmx_support'. The other
> undefined references remain.
> After taking a closer look at the libpng.so by e.g.
> nm /usr/lib/libpng.so | grep png_read_filter_row
> I found out that these symbols exist in the text segment, but only as
> internal symbols:
> 0000000000007de0 t png_read_filter_row
> How come they can link in your environment at all? Have you built your
> libpng in a special way and is there a workaround to replace these
> library calls by OpenJDK-internal implementations or something likewise?
> Anyway, I still got one other question: What is the background of all of
> those overwrite variables in the jdk/make/common/Defs-linux.gmk?
> Omitting the overwrite directive would ease redefining some environment
> definitions like OPENWIN_HOME or OPENWIN_LIB from command line, for
> which no ALT_... variables exist.
> Best regards
More information about the discuss