Last Comment Bug 629459 - Build Firefox with clang
: Build Firefox with clang
Status: RESOLVED DUPLICATE of bug 672210
[clang][new type of build]
:
Product: Release Engineering
Classification: Other
Component: Other (show other bugs)
: other
: x86_64 Mac OS X
: P5 normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: clang 655988
Blocks:
  Show dependency treegraph
 
Reported: 2011-01-27 11:30 PST by Rafael Ávila de Espíndola (:espindola) (not reading bugmail)
Modified: 2013-08-12 21:54 PDT (History)
15 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Rafael Ávila de Espíndola (:espindola) (not reading bugmail) 2011-01-27 11:30:16 PST
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 Zambrano [:armenzg] - Engineering productivity 2011-01-27 12:05:36 PST
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) 2011-01-27 13:27:38 PST
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) 2011-05-06 14:56:42 PDT
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 :Ehsan Akhgari (busy, don't ask for review please) 2011-05-10 11:50:35 PDT
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] 2011-05-10 18:15:06 PDT
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 :Ehsan Akhgari (busy, don't ask for review please) 2011-05-11 14:28:44 PDT
(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] 2011-05-11 15:31:04 PDT
(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 :Ehsan Akhgari (busy, don't ask for review please) 2011-06-13 13:50:29 PDT
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) 2011-06-13 14:51:18 PDT
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 2011-11-02 13:43:37 PDT
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) 2011-12-08 16:21:58 PST
I just realized that we probably have duplicated bugs. Should I close this as a dup of 672210?
Comment 12 Chris Cooper [:coop] 2012-03-22 13:58:36 PDT

*** This bug has been marked as a duplicate of bug 672210 ***

Note You need to log in before you can comment on or make changes to this bug.