b31 multiple build failures on x86 Linux

[Kelly O'Hair]

Jeffrey Baker wrote:
> On Tue, Jul 22, 2008 at 12:17 PM, Kelly O'Hair <Kelly.Ohair at sun.com> wrote:
>> Jeffrey Baker wrote:
[snip]
> 
>>> 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.

You won't like this, but it's 3.2.
We get gcc from the Linux system, and unfortunately we haven't upgraded
the official Linux systems for JDK7, yet.
I know people have used gcc4, but I don't know what the exact version is.

Maybe someone from one of the linux distros and speak up on this topic??

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

For multiple reasons, you cannot modify makefiles in the jdk and expect
hotspot to see anything. If you want variables propagated through the
build, they must be on the 'make' command line.

Hotspot makefiles are independent from the jdk makefiles and have their
own origins, style, structure, and conventions.
The hotspot makefiles will not read makefiles outside their repository,
they are completely independent makefiles.
I didn't invent it, I just know about it. ;^)

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

We don't generate a "profiled" jdk, so this makes no sense.
I'm sure you could build a profiled hotspot VM and plug it in to
a jdk image, but you won't get any help in the jdk makefiles.
Also, even if you did get it to work, using a profiled VM to build
the JDK would probably be a bit slow, and serve little purpose.

Treat hotspot separate, build it the way you want, and plug it into
the jdk image you want to use. Your builds will be faster and you
can avoid building lots of jdk code you don't need to repeatedly rebuild.

> 
> What is the official way to build openjdk with profiling?

As far as I know, there is none. It's just not something that is done
much anymore.

When we are doing profiling we use tools like the Sun Studio Analyzer
or the NetBeans profiler, where we really don't need to build the image
in any special way. Sun Studio 12 is available on Linux, with the Analyzer,
but I have never used it.

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

No problem, it's just been a bit of a thorn in our sides of late. :^(

As I understand it, Ubuntu knowingly shipped with a dash bug that breaks
our shell scripts. I don't have any other details.
You might be able to 'make SH=/bin/bash' to get around this, but it's
just a guess.

-kto

> 
> Thanks a lot for your helpful reply.
> 
> -jwb