JDK 7 build 24 is available at the openjdk.java.net website

[Kelly O'Hair]

Adding build-dev to the CC list, seems like these are build issues...

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.

At some point in time (a long long time ago?), it was decided that the jdk
Makefiles should always run utilities with a full pathname and not rely on
the PATH setting. I kind of understand what the issue was, PATH ordering issues
can be extremely hard to diagnose. But I myself find it a maintenance
nightmare because of what you have run into.
I don't know if this will change, and there is some risk of relying on PATH
especially on Windows, but just so you know, this is a known issue and
debate. I tend to think that we should rely on PATH more, especially when
it relates to the basic utility commands like 'cd', 'sed', etc. I hate
having to use '$(CD)' in the makefiles instead of just 'cd'. :^(
Maybe a PATH sanity check on the utilities used somehow, devise a simple
use case for each utility used, and verify the utility from PATH is
acceptable...  Ah...  but I know what you will say, just use autotools...
well...  does autotools work on Windows with VS2003? :^(

> 
> 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'
> /opt/jdk/openjdk-1.7.0_b24/tmp/sun/sun.awt/splashscreen/obj64/pngpread.o: 
> 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'
> /opt/jdk/openjdk-1.7.0_b24/tmp/sun/sun.awt/splashscreen/obj64/pngpread.o: 
> In function `png_progressive_combine_row':
> pngpread.c:(.text+0x141): undefined reference to `png_combine_row'
> /opt/jdk/openjdk-1.7.0_b24/tmp/sun/sun.awt/splashscreen/obj64/pngread.o: 
> 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
> 
> -lpng
> 
> 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?

Sounds like the above is a known png issue...

> 
> 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.

This is the same question I have. These have been handed down over time and
I'm not exactly sure why the override (you did mean override, right?) was
used so much. I consider the use of override bad style, figuring out how
make variables get defined is hard enough without complicating things with
an override setting. The 'override VAR += XXX' might make sense, but even
then you can get the same results by introducing another variable, and it
might be more obvious what's happening that way, but we don't use the += with
override.

(For those of you unfamiliar with GNU make 'override', see
  http://www.gnu.org/software/make/manual/make.html#Override-Directive)

I do know that the name TMPDIR was an issue, but we changed that to TEMPDIR
a long time ago and the override on TEMPDIR is probably not necessary anymore.
(TMPDIR was treated special in Linux or GNU make at some point??? but it's a name
that should be avoided, or at least avoided as your own variable name :^).

But I'm a little nervous about all these Linux variables that use override:

---

override ALT_CODESET_KEY         = _NL_CTYPE_CODESET_NAME
override AWT_RUNPATH             =
override HAVE_ALTZONE            = false
override HAVE_FILIOH             = false
override HAVE_GETHRTIME          = false
override HAVE_GETHRVTIME         = false
override HAVE_SIGIGNORE          = true
override LEX_LIBRARY             = -lfl
ifeq ($(STATIC_CXX),true)
override LIBCXX                  = -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic
else
override LIBCXX                  = -lstdc++
endif
override LIBPOSIX4               =
override LIBSOCKET               =
override LIBTHREAD               =
override MOOT_PRIORITIES         = true
override NO_INTERRUPTIBLE_IO     = true
override OPENWIN_HOME            = /usr/X11R6
ifeq ($(ARCH), amd64)
override OPENWIN_LIB             = $(OPENWIN_HOME)/lib64
else
override OPENWIN_LIB             = $(OPENWIN_HOME)/lib
endif
override OTHER_M4FLAGS           = -D__GLIBC__ -DGNU_ASSEMBLER
override SUN_CMM_SUBDIR          =
override THREADS_FLAG            = native
override USE_GNU_M4              = true
override USING_GNU_TAR           = true
override WRITE_LIBVERSION        = false

# USE_EXECNAME forces the launcher to look up argv[0] on $PATH, and put the
# resulting resolved absolute name of the executable in the environment
# variable EXECNAME.  That executable name is then used that to locate the
# installation area.
override USE_EXECNAME            = true

---

Some I recognize, but every one of these variables would need to be investigated
to see why the override was necessary and if we can safely remove it.
Why not allow someone to set these on the command line if they wanted?

I'm certainly in favor of removing unnecessary override's.

-kto

> Best regards
> 
> Arnd-Hendrik