Closed Bug 629459 Opened 13 years ago Closed 12 years ago

Build Firefox with clang

Categories

(Release Engineering :: General, defect, P5)

x86_64
macOS
defect

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 672210

People

(Reporter: espindola, Unassigned)

References

Details

(Whiteboard: [clang][new type of build])

Once https://bugzilla.mozilla.org/show_bug.cgi?id=574346 is fixed or maybe after all tests pass it would be nice to have an os X bot that uses clang.

I will update this bug once things work out of the box.
Thanks Rafael!
I have added the dependency on the bug.

FTR cland gives compilation improvements (17mins instead of 24mins on Rafael's machine) and it is the future on how to compile on mac if I understood correctly from our conversation.
Depends on: clang-macosx
Priority: -- → P5
Whiteboard: [clang][new type of build]
It is actually better then that :-)

a clang opt is 14m49.258s and a gcc opt is 23m31.229s. The last gcc shipped by Apple is 4.2, so at some point we will have to switch to keep supporting os X.
Clang 2.9 can now build vanilla firefox on OS X.

Our build on OS X currently use the gcc provided by Apple, correct? If so it should be possible to build a clang to use in the bots by downloading

http://llvm.org/releases/2.9/llvm-2.9.tgz

and

http://llvm.org/releases/2.9/clang-2.9.tgz

and running:

$ tar -xf llvm-2.9.tgz
$ tar -xf clang-2.9.tgz
$ mv clang-2.9 llvm-2.9/tools/clang
$ mkdir bulid
$ cd build
$ ../llvm-2.9/configure --enable-optimized --prefix=<inst dir>
$ make -j8
$ make install

You can also just get the compiled one from

http://llvm.org/releases/2.9/clang+llvm-2.9-x86_64-apple-darwin10.tar.gz

Let me know if you need any help.
Summary: Add a buildbot running clang → Build Firefox with clang
Depends on: 655988
I'm wondering if we can get some sort of an ETA here?  A number of developers are switching to clang as their main compiler, and it would be great if patches which break clang builds burn the tree instead of the local checkouts of developers...
Getting builds is relatively easy. Getting unit tests and performance tests on those builds is a whole other problem.

If you just want 64-bit builds for now, we can probably have that done in a week.
(In reply to comment #5)
> Getting builds is relatively easy. Getting unit tests and performance tests on
> those builds is a whole other problem.
> 
> If you just want 64-bit builds for now, we can probably have that done in a
> week.

I think as a first step, we should get builds showing up on TBPL.  Once we have that, we can focus on getting unit tests and performance tests.  FWIW, Rafael is trying out the test results on the try server, but I don't want this to block us from getting builds showing up.

Is this bug the good place to get the builds going?
(In reply to comment #6)
> (In reply to comment #5)
> > Getting builds is relatively easy. Getting unit tests and performance tests on
> > those builds is a whole other problem.
> > 
> > If you just want 64-bit builds for now, we can probably have that done in a
> > week.
> 
> I think as a first step, we should get builds showing up on TBPL.  Once we
> have that, we can focus on getting unit tests and performance tests.  FWIW,
> Rafael is trying out the test results on the try server, but I don't want
> this to block us from getting builds showing up.
> 
> Is this bug the good place to get the builds going?

Yes!
Rafael, have you done any testing with the new clang binaries installed on the slaves?
Yes.

The tests with opt on OS X are all green. With debug, the interpreter uses too much stack space, that has been improved upstream, will try again.

On linux it found problems with using the old system headers in centos. I will send a patch to the spec file so that the new snapshot uses the gcc 4.5 headers.

What I have been trying to do before getting a new snapshot is beat gcc 4.2 on dromaeo at least. That way we can probably get more interesting results when running talus.
The latest git version of clang & llvm work fine with -O3 on Linux.
When I try a -O4 build it fails when linking libxul:

Global is external, but doesn't have external or dllimport or weak linkage!
%"class.IPC::Message.226497"* (%"class.std::map.226896"*, i64*)* @_ZNSt3mapImN3IPC7MessageESt4lessImESaISt4pairIKmS1_EEEixEOm
invalid linkage type for function declaration
%"class.IPC::Message.226497"* (%"class.std::map.226896"*, i64*)* @_ZNSt3mapImN3IPC7MessageESt4lessImESaISt4pairIKmS1_EEEixEOm
Global is external, but doesn't have external or dllimport or weak linkage!
i1 (%"class.mozilla::ipc::RPCChannel.226903"*)* @_ZNK7mozilla3ipc10RPCChannel27ShouldDeferNotifyMaybeErrorEv
invalid linkage type for function declaration
i1 (%"class.mozilla::ipc::RPCChannel.226903"*)* @_ZNK7mozilla3ipc10RPCChannel27ShouldDeferNotifyMaybeErrorEv
Global is external, but doesn't have external or dllimport or weak linkage!
void (%"class.std::deque.16.226889"*, %"class.IPC::Message.226497"*)* @_ZNSt5dequeIN3IPC7MessageESaIS1_EE9push_backERKS1_
invalid linkage type for function declaration
void (%"class.std::deque.16.226889"*, %"class.IPC::Message.226497"*)* @_ZNSt5dequeIN3IPC7MessageESaIS1_EE9push_backERKS1_
invalid linkage type for global declaration
[49 x i8]* @.str53683
invalid linkage type for global declaration
[24 x i8]* @.str153684
invalid linkage type for global declaration
[36 x i8]* @.str253685
invalid linkage type for global declaration
[4 x i8]* @.str353686
invalid linkage type for global declaration
[17 x i8]* @.str453687
invalid linkage type for global declaration
[17 x i8]* @.str553688
invalid linkage type for global declaration
[25 x i8]* @.str653689
...

Any ideas?
I just realized that we probably have duplicated bugs. Should I close this as a dup of 672210?
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.