b31 multiple build failures on x86 Linux

[Jeffrey Baker]

On Tue, Jul 22, 2008 at 12:17 PM, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
> Jeffrey Baker wrote:
>>
>> I noted multiple build failures on x86 Linux (Ubuntu 8.04) using the
>> b31 source archive, building the fastdebug_build target.
>>
>> The first failure occurs due to -Werror.  There are a number of unsafe
>> casts of char * in hotspot, and these cause the build to fail with
>> -Werror.  I worked around this by removing -Werror from a variety of
>> Makefiles.  Aside: why isn't this propagated from the top-level
>> Makefile?  I had to grep around in the tree to find the right one.
>
> The hotspot sources have traditionally been built by a handful of
> compilers with all known warnings fixed. When you start using a newer
> compiler with newer warnings, you need to either fix the warnings or
> turn off the -Werror option.
> If you supply WARNINGS_ARE_ERRORS=  on the make command line so that you
> empty out this variable that normally has -Werror in it, that should work.
> You should not have to edit the Makefiles, so if
>   make WARNINGS_ARE_ERRORS=
> does not work, let me know.
> You cannot set this as an environment variable and we never use the
> 'make -e' option. When make is run in the Makefiles, it should use
> $(MAKE) which should propagate the command line options.
> Again, if this is not the case, let me know.

Noted.

>> Second problem: the build dumped core in test_gamma with an error in
>> ciTypeFlow.hpp:395.  I filed this bug at sun.com with Review ID
>> 1299675.  I worked around this by exiting the test_gamma script early.
>
> Since you are using a newer gcc compiler, it's quite possible you have
> found a bug of some kind, in gcc or in hotspot or somewhere in between.
> You may want to see about trying a different gcc to isolate what the issue
> might be.

What is the officially blessed compiler?  This one appears to be gcc
4.2.3, but I have numerous other revisions of gcc kicking around,
including 4.1 and 4.2.

>> Third problem: fastdebug_build target doesn't seem to propagate the -g
>> flag.  All of hotspot was built with -fPIC -fno-rtti -fno-exceptions
>> -fcheck-new -m32 -march=i586 -pipe -O3 -fno-strict-aliasing
>> -Wpointer-arith -Wconversion -Wsign-compare, i.e. without -g.  I
>> thought the point of the fastdebug target was to build with -g -O.
>
> Yes, it should have. That's a new one on me.
> I see that the debug build seems to use -gstabs, but it looks
> like linux/makefiles/fastdebug.make forgot to add -gstabs to CFLAGS.
> It's possible that they removed it with 64bit mode because of the
> size problems with Dwarf2 debug format, and accidently removed it for
> 32bit too. :^(   Sounds like a bug to me.

Looking into that further, it seems that very little is propagated
from the top level Makefile down to the hotspot build.  I tried
altering DEBUG_FLAG in jdk/make/common/Defs-linux.gmk but my changes
were lost by the time the build descended to hotspot.  I also tried
using OTHER_CFLAGS, OTHER_CXXFLAGS, and OTHER_LDFLAGS on the make
command line, but that too was lost.  Setting CFLAGS itself on the
make command line doesn't work because it clobbers the rest of the
flags.

I eventually edited hotspot/make/linux/makefiles/gcc.make to add -pg,
but while poking around in there I saw profiled.make.  I see that
"profiled" is a valid target in hotspot, but it's not exposed at the
top level build.  Therefore I set HOTSPOT_TARGET = profiled.
Unfortunately that did not work either.

What is the official way to build openjdk with profiling?

> The build does not require bash, it requires an 'sh' that works properly.
> Some change in dash caused this problem. These sh scripts have not changed
> for ages.

Ok.  I didn't mean to accuse anyone of anything here.  I never heard
of "dash" until today so I did not hesitate when I removed it from my
system.

Thanks a lot for your helpful reply.

-jwb