Build Firefox with clang

RESOLVED DUPLICATE of bug 672210

Status

Release Engineering
General
P5
normal
RESOLVED DUPLICATE of bug 672210
7 years ago
4 years ago

People

(Reporter: espindola, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

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.

Comment 1

7 years ago
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: 574346
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.

Updated

6 years ago
Summary: Add a buildbot running clang → Build Firefox with clang

Updated

6 years ago
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.

Comment 10

6 years ago
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?

Updated

5 years ago
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 672210
(Assignee)

Updated

4 years ago
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.