629459 - Build Firefox with clang

Status: RESOLVED DUPLICATE of bug 672210

(Release Engineering :: General, defect, P5)

Description

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

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.

Comment 1

[Armen [:armenzg]]

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.

Comment 2

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

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.

Comment 3

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

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.

Comment 4

[(no longer active)]

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

Comment 5

[Chris AtLee [:catlee]]

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.

Comment 6

[(no longer active)]

(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?

Comment 7

[Chris AtLee [:catlee]]

(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!

Comment 8

[(no longer active)]

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

Comment 9

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

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.

Comment 10

[Octoploid]

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?

Comment 11

[Rafael Ávila de Espíndola (:espindola) (not reading bugmail)]

I just realized that we probably have duplicated bugs. Should I close this as a dup of 672210?