On Tue, Jul 22, 2008 at 12:17 PM, Kelly O'Hair <[EMAIL PROTECTED]> 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
