I get the following compile-time error when building Firefox trunk on Linux with the profiledbuild target: nsHttpHeaderArray.cpp: In member function `nsresult nsHttpHeaderArray::SetHeader(nsHttpAtom, const nsACString&, int)': nsHttpHeaderArray.cpp:94: <http://tinderbox.mozilla.org/bonsai/cvsguess.cgi?file=nsHttpHeaderArray.cpp&rev=HEAD&mark=94#84> error: corrupted profile info: prob for 0-1 thought to be 10001 Build logs can be found at: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1114722180.12463.gz&fulltext=1 http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1114733520.12946.gz&fulltext=1 Compiler used is the same gcc-3.3.2rh that is used on ocean. The system is a dual Xeon processor Red Hat Enterprise Linux AS 3.0 operating system that had all of its OS updates as of 2005/04/28. Since this system is our solution to enabling SVG in our Linux builds, this most likely blocks fully enabling SVG for 1.1 alpha.

rpm -q binutils ocean: binutils-2.15.90.0.3-5 prometheus: binutils-2.14.90.0.4-35

I reconfigured the gcc-3.3.2rh source tree on prometheus, rebuilt, and reinstalled. The resulting Firefox build failed with a variation of the earlier error: nsHttpHeaderArray.cpp: In member function `nsresult nsHttpHeaderArray::SetHeader(nsHttpAtom, const nsACString&, int)': nsHttpHeaderArray.cpp:94: <http://tinderbox.mozilla.org/bonsai/cvsguess.cgi?file=nsHttpHeaderArray.cpp&rev=HEAD&mark=94#84> error: corrupted profile info: prob for 36--2 thought to be -7 error: corrupted profile info: prob for 36-37 thought to be 10008

What distrib does ocean run?

ocean is based on Red Hat 8.0.

(In reply to comment #1) > rpm -q binutils > > ocean: binutils-2.15.90.0.3-5 > prometheus: binutils-2.14.90.0.4-35 I upgraded prometheus to binutils-2.15.90.0.3-5 using the binary package that was on ocean. I started with a new obj directory in the gcc-3.3.2rh directory, rebuilt and reinstalled the compiler. My profiled build of Firefox failed with a variation of the "corrupted profile info" error as before. Build log can be found at: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTest/1114812660.17836.gz&fulltext=1

We have been running builds on prometheus since 2005/04/29 using the standard non-profiled build target in lieu of the profiled build target not building correctly. If there was some way to overcome the build error listed below I would use the profiled build target again for Linux trunk builds. Unfortunately, my searches only turn up the profiling source code, nor have bryner's. No one else appears to have suggestions on this at the moment.

Chase or bryner, what are your feelings about the liklihood of this being fixed for the upcoming release?

Unlikely if those in charge of the product for 1.1 don't agree that profiled optimizations on Linux are required to ship. bryner doesn't have time to look into it but he's stated that he wants to see us ship 1.1 with it. ccooper or polvi could be our saving grace. I'm under the impression that we're "good enough" on Linux right now but I'll ping them again in a last ditch effort. (Not to devalue your contribution here, bryner, or dbaron's for 1.0.) I haven't worked on this in a while. Reassigning to nobody@m.o.

cbeard wants info from Red Hat and Novell whether they can do profiled builds currently and if they do those from source snapshots. I will seek people out for that info.

I don't think we do profiled builds but let's ask Wolfgang.

We don't do profiled builds. (hmm, I even don't know how to do it at all). Sorry.

Red Hat does not do profiled builds. Hadn't heard of it until just now. The problem with it though is that a working X server seems required to do profiled builds. That is not guaranteed on all dedicated build environments.

Paul, could you take a look at this bug and let me know what you think?

I've been playing around with this, and after some searching around, found the following (interesting) bugs: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1831 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18152 I also got some semblance of a build semi-working, but it required turning off all optimizations and adding a couple of flags in the configure script. It also didn't completely solve the problem, it just allowed the compile to get further. I'm curious what the original mozconfig was; I just grabbed a standard one and tweaked it.

*Some* good news on this: I was able to create profiled builds using gcc 3.3.6 and binutils 2.15. It looks like gcc 3.2.x and binutils 2.14 don't get along. I'm going to try this out on RHEL4, but it's unlikely to work, since they use GCC 3.4.x and binutils 2.15 (which might work, except its seemingly blocked by 240267).

Update on this: The logs below are long gone, so I can't confirm what did or didn't work, but from investigation and testing: Known bad combinations are: binutils <= 2.14 or gcc <= 3.1. This precludes use of RHEL3uX, as their binutils RPM is 2.14.x Known good combinations are: binutils = 2.15.92.x + gcc 3.3.6 binutils = 2.16.1 + gcc 3.4.4 (with the patch from bug 240267) Unknown combinations: binutils >= 2.15 + gcc = 3.2.x; according to previous reports, that does *not* work, but it may have been due to mixing RPMs from different RedHat distro versions. Not sure what the "pristine" sources for GCC/binutils would do. (To clarify, "work" is defined as "finishing a build with the existence of gcno/.da files.) Question now is are there any needs for profiled builds on the 1_8_0 branch and/or trunk, and if so, do we want to move the reference platform to support them (or not move the reference platform, and just use a different platform for profiled builds). I would suggest that moving the ref-platform (to RHEL4, I guess) for the trunk is probably OK, but we probably don't want to do that for 1.8.0.x builds at this point in the game. Taking this bug...

Reassigning bugs I'm not actively working on back into the triage pool.

Marking WONTFIX; this should actually work with the new ref platforms we have based on CentOS4.4/CentOS5.