b31 multiple build failures on x86 Linux

[Jeffrey Baker]

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.

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.

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.
Should I have built with the plain debug_build target instead?

Fourth problem:
/home/jwb/jdk-src/openjdk/build/linux-i586-fastdebug/gensrc/java/nio/charset/CharsetEncoder.java:142:
cannot find symbol
symbol  : class $replType$
location: class java.nio.charset.CharsetEncoder
    private $replType$ replacement;

This is evidently caused by /bin/sh being dash instead of bash.  If
the build requires bash, why doesn't it invoke bash?  Relying on sh ==
bash is fragile and confusing.

Regards,
jwb

[kelly.ohair]

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.

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

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

> Should I have built with the plain debug_build target instead?

No, you should not have to.

>
> Fourth problem:
> /home/jwb/jdk-src/openjdk/build/linux-i586-fastdebug/gensrc/java/nio/charset/CharsetEncoder.java:142:
> cannot find symbol
> symbol  : class $replType$
> location: class java.nio.charset.CharsetEncoder
>     private $replType$ replacement;
>
> This is evidently caused by /bin/sh being dash instead of bash.  If
> the build requires bash, why doesn't it invoke bash?  Relying on sh ==
> bash is fragile and confusing.

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.

-kto

>
> Regards,
> jwb

[Jeffrey Baker]

On Tue, Jul 22, 2008 at 12:17 PM, Kelly O'Hair <Kelly.Ohair@...> 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

[kelly.ohair]

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

[Andrew Haley]

Kelly O'Hair wrote:

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

We have used 4.1 and 4.3.  We don't much like 4.2 so we're not going to
use it.

Andrew.

[kelly.ohair]

Should I add a warning message that says:
   "You are using gcc 4.2, we don't like it very much, you should use 4.1 or 4.3."
:^)

-kto


Andrew Haley wrote:

> Kelly O'Hair wrote:
>>
>> Jeffrey Baker wrote:
>>> On Tue, Jul 22, 2008 at 12:17 PM, Kelly O'Hair <Kelly.Ohair@...>
>>> 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??
>
> We have used 4.1 and 4.3.  We don't much like 4.2 so we're not going to
> use it.
>
> Andrew.

[Jeffrey Baker]

On Tue, Jul 22, 2008 at 1:53 PM, Kelly O'Hair <Kelly.Ohair@...> wrote:
> Jeffrey Baker wrote:
>> 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.

That is a bit inconvenient.  Ubuntu provides 3.3 and 3.4, but not 3.2.
 Nevertheless, I'm sure I can find the source somewhere.

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

In the beginning, I could not get anything to work aside from the top
level build system.  Now I appear to be suitably equipped to type
'make' in hotspot/make, which is an improvement.  Still, 'make
profiled' is not valid, and 'make help' does not offer any advice on
the topic.  I am taunted by the 'profiled' target in the linux
Makefile!

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

Which explains at least the difficulty of doing so ...

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

That's an idea.  I think I might try SS12 for a bit.

-jwb

[kelly.ohair]

Jeffrey Baker wrote:
> On Tue, Jul 22, 2008 at 1:53 PM, Kelly O'Hair <Kelly.Ohair@...> wrote:
>> Jeffrey Baker wrote:
>>> 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.
>
> That is a bit inconvenient.  Ubuntu provides 3.3 and 3.4, but not 3.2.
>  Nevertheless, I'm sure I can find the source somewhere.

It sounds like 4.2 might have problems, you might just try 4.1.
We are trying to upgrade our official Linux systems, but it's taking
longer than expected.

>
>> 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.
>
> In the beginning, I could not get anything to work aside from the top
> level build system.  Now I appear to be suitably equipped to type
> 'make' in hotspot/make, which is an improvement.  Still, 'make
> profiled' is not valid, and 'make help' does not offer any advice on
> the topic.  I am taunted by the 'profiled' target in the linux
> Makefile!

The top level hotspot/make/Makefile was originally written by me.
The other makefiles have a more colorful history. ;^)
Try mimic'ing the use of the "jvmg" target in the hotspot/make/Makefile,
I'm sure you could create a set of rules that would result in doing
a "profiled" build, but you are on your own with this.
I only added selected build targets to the top level Makefile,
which wasn't really for developers as much as for the overall builds
and release engineering.

>
>>> 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.
>
> Which explains at least the difficulty of doing so ...
>
>> 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.
>
> That's an idea.  I think I might try SS12 for a bit.

Have fun.

-kto

>
> -jwb

[David Holmes - Sun Microsystems]

Kelly O'Hair said the following on 07/23/08 05:17:

> Jeffrey Baker wrote:
>> 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.

The debug flags are handled in gcc.make:

hypert /scratch/mirrors/ws-mirrors/java7/open/hotspot/make > tail -15
linux/makefiles/gcc.make
#------------------------------------------------------------------------
# Debug flags

# Use the stabs format for debugging information (this is the default
# on gcc-2.91). It's good enough, has all the information about line
# numbers and local variables, and libjvm_g.so is only about 16M.
# Change this back to "-g" if you want the most expressive format.
# (warning: that could easily inflate libjvm_g.so to 150M!)
# Note: The Itanium gcc compiler crashes when using -gstabs.
DEBUG_CFLAGS/ia64  = -g
DEBUG_CFLAGS/amd64 = -g
DEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH))
ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),)
DEBUG_CFLAGS += -gstabs
endif

See also bug 6485088

Cheers,
David Holmes

[Rob Ross-3]

Would getting the hotspot "project" to compile be a good first step  
at porting the JDK to a new platform? I'm still trying to find the  
entry point to this long road. If not hotspot, what else would be a  
good first effort at porting something?

Also, on a quick perusal, it sure seems like there's a lot of  
assembly-related files in this project. I suppose that's the end  
result of lots of evolution and performance enhancing. But for a  
newbie to this project it can sure seem daunting :)


Rob Ross, Lead Software Engineer
E! Networks

---------------------------------------------------
"Beware of he who would deny you access to information, for in his  
heart he dreams himself your master." -- Commissioner Pravin Lal



On Jul 22, 2008, at 4:43 PM, Kelly O'Hair wrote:

>
>
> Jeffrey Baker wrote:
>> On Tue, Jul 22, 2008 at 1:53 PM, Kelly O'Hair  
>> <Kelly.Ohair@...> wrote:
>>> Jeffrey Baker wrote:
>>>> 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.
>> That is a bit inconvenient.  Ubuntu provides 3.3 and 3.4, but not  
>> 3.2.
>>  Nevertheless, I'm sure I can find the source somewhere.
>
> It sounds like 4.2 might have problems, you might just try 4.1.
> We are trying to upgrade our official Linux systems, but it's taking
> longer than expected.
>
>>> 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.
>> In the beginning, I could not get anything to work aside from the top
>> level build system.  Now I appear to be suitably equipped to type
>> 'make' in hotspot/make, which is an improvement.  Still, 'make
>> profiled' is not valid, and 'make help' does not offer any advice on
>> the topic.  I am taunted by the 'profiled' target in the linux
>> Makefile!
>
> The top level hotspot/make/Makefile was originally written by me.
> The other makefiles have a more colorful history. ;^)
> Try mimic'ing the use of the "jvmg" target in the hotspot/make/
> Makefile,
> I'm sure you could create a set of rules that would result in doing
> a "profiled" build, but you are on your own with this.
> I only added selected build targets to the top level Makefile,
> which wasn't really for developers as much as for the overall builds
> and release engineering.
>
>>>> 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.
>> Which explains at least the difficulty of doing so ...
>>> 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.
>> That's an idea.  I think I might try SS12 for a bit.
>
> Have fun.
>
> -kto
>
>> -jwb

[kelly.ohair]

Looking at fastdebug build log files, no -g or -gstabs is provided on
any linux builds as far as I can see.

I suspect that hotspot/make/linux/makefiles/fastdebug.make is missing
the addition of this DEBUG_CFLAGS variable to CFLAGS like the jvmg.make
and debug.make files. Adding it to CFLAGS adds it to all compile lines.

The gcc.make file does not add the DEBUG_CFLAGS to CFLAGS.

-kto

David Holmes - Sun Microsystems wrote:

> Kelly O'Hair said the following on 07/23/08 05:17:
>> Jeffrey Baker wrote:
>>> 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.
>
> The debug flags are handled in gcc.make:
>
> hypert /scratch/mirrors/ws-mirrors/java7/open/hotspot/make > tail -15
> linux/makefiles/gcc.make
> #------------------------------------------------------------------------
> # Debug flags
>
> # Use the stabs format for debugging information (this is the default
> # on gcc-2.91). It's good enough, has all the information about line
> # numbers and local variables, and libjvm_g.so is only about 16M.
> # Change this back to "-g" if you want the most expressive format.
> # (warning: that could easily inflate libjvm_g.so to 150M!)
> # Note: The Itanium gcc compiler crashes when using -gstabs.
> DEBUG_CFLAGS/ia64  = -g
> DEBUG_CFLAGS/amd64 = -g
> DEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH))
> ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),)
> DEBUG_CFLAGS += -gstabs
> endif
>
> See also bug 6485088
>
> Cheers,
> David Holmes

[David Holmes - Sun Microsystems]

Sorry - you're right Kelly. On Solaris fastdebug.make has been using
DEBUG_CFLAGS since 2000, but on linux it has never had it!

That said perhaps the "fast" in "fastdebug" was actually intended to
address this ie perhaps the linux makefile is "correct" ? I've never
really understood the detailed difference between a debug and fastdebug
build.

Cheers,
David Holmes

Kelly O'Hair said the following on 07/24/08 01:03:

> Looking at fastdebug build log files, no -g or -gstabs is provided on
> any linux builds as far as I can see.
>
> I suspect that hotspot/make/linux/makefiles/fastdebug.make is missing
> the addition of this DEBUG_CFLAGS variable to CFLAGS like the jvmg.make
> and debug.make files. Adding it to CFLAGS adds it to all compile lines.
>
> The gcc.make file does not add the DEBUG_CFLAGS to CFLAGS.
>
> -kto
>
> David Holmes - Sun Microsystems wrote:
>> Kelly O'Hair said the following on 07/23/08 05:17:
>>> Jeffrey Baker wrote:
>>>> 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.
>>
>> The debug flags are handled in gcc.make:
>>
>> hypert /scratch/mirrors/ws-mirrors/java7/open/hotspot/make > tail -15
>> linux/makefiles/gcc.make
>> #------------------------------------------------------------------------
>> # Debug flags
>>
>> # Use the stabs format for debugging information (this is the default
>> # on gcc-2.91). It's good enough, has all the information about line
>> # numbers and local variables, and libjvm_g.so is only about 16M.
>> # Change this back to "-g" if you want the most expressive format.
>> # (warning: that could easily inflate libjvm_g.so to 150M!)
>> # Note: The Itanium gcc compiler crashes when using -gstabs.
>> DEBUG_CFLAGS/ia64  = -g
>> DEBUG_CFLAGS/amd64 = -g
>> DEBUG_CFLAGS += $(DEBUG_CFLAGS/$(BUILDARCH))
>> ifeq ($(DEBUG_CFLAGS/$(BUILDARCH)),)
>> DEBUG_CFLAGS += -gstabs
>> endif
>>
>> See also bug 6485088
>>
>> Cheers,
>> David Holmes

[Jesse Glick]

Kelly O'Hair wrote:
> You might be able to 'make SH=/bin/bash' to get around this, but it's
> just a guess.

What works for me (Ubuntu 8.04 w/ all updates):

export SPP_CMD='/bin/bash spp.sh'
make

Cf.

http://bugs.sun.com/view_bug.do?bug_id=6681798

[Alan Bateman]

Jesse Glick wrote:
> :
> http://bugs.sun.com/view_bug.do?bug_id=6681798
Sherman has changes in the pipe that replaces the current sed based
pre-processor. That will avoid these shell/escaping problems.

-Alan.

[kelly.ohair]

Great!  Good news...

-kto

Alan Bateman wrote:
> Jesse Glick wrote:
>> :
>> http://bugs.sun.com/view_bug.do?bug_id=6681798
> Sherman has changes in the pipe that replaces the current sed based
> pre-processor. That will avoid these shell/escaping problems.
>
> -Alan.
>

[gnu_andrew]

On 22/07/2008, Andrew Haley <aph@...> wrote:

> Kelly O'Hair wrote:
>  >
>  >
>  > Jeffrey Baker wrote:
>  >> On Tue, Jul 22, 2008 at 12:17 PM, Kelly O'Hair <Kelly.Ohair@...>
>  >> 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??
>
>
> We have used 4.1 and 4.3.  We don't much like 4.2 so we're not going to
>  use it.
>
>
>  Andrew.
>

I've successfully built b31 with gcc 4.3.1 via IcedTea7:

./openjdk/build/linux-amd64/bin/java -version
java version "1.7.0_0"
IcedTea Runtime Environment (build 1.7.0_0-b31)
OpenJDK 64-Bit Server VM (build 1.7.0_0-b31, mixed mode)

Notably, we were able to drop a patch from IcedTea that removes the
-Werror flag because the gcc 4.3 problems have been fixed:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6718830
--
Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK
http://www.gnu.org/software/classpath
http://openjdk.java.net

PGP Key: 94EFD9D8 (http://subkeys.pgp.net)
Fingerprint: F8EF F1EA 401E 2E60 15FA  7927 142C 2591 94EF D9D8