[cfe-dev] clang packaging question

Michel Alexandre Salim michael.silvanus at gmail.com
Wed Sep 9 08:53:27 PDT 2009

On Wed, Sep 9, 2009 at 4:48 AM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Wed, Sep 9, 2009 at 12:05 AM, Michel Alexandre
> Salim<michael.silvanus at gmail.com> wrote:
>> 1. Noting that clang and clang-cc can currently operate without LLVM
>> installed, would it be better to have the llvm-clang package depend on
>> llvm or not?
> If you're distributing the gold plugin, it would be nice to have once
> it works (see below); otherwise, I don't see any need to drag in the
> other LLVM tools unless the user requests them, at least for the
> moment.
Ah, OK. I'll have to experiment more with the gold plugin.

>> 2. The clang binary's emit-llvm mode currently only works if -S is
>> also supplied; would it eventually automatically invoke the
>> appropriate LLVM tools (as per the clang-cc examples)? In which case,
>> the answer to (1) is obvious.

My mistake; using '-c' also works, though clang should perhaps use .ll
and .bc extensions, rather than .s and .o? With -c, the bitcode file
generated can then be executed using lli. I guess there is no such
thing as a linked bitcode file anyway.

> In theory, it should work with the gold plugin
> (http://llvm.org/docs/GoldPlugin.html), although I don't think clang
> actually passes the right options to the linker at the moment.  There
> have been discussions of other modes, but nothing definite.

The Clang documentation does not specifically mention gold, so I'm a
bit unclear on things -- would gold be just another supported linker,
or would it be required?

Fedora currently does not ship gold with its binutils, but if this
would become a requirement, I could ask to have it added.

> Are you planning to base the release off of LLVM 2.6?  If not, note
> that you should uncomment the USE_PRODUCTION_CLANG define in
> clang/lib/Driver/Driver.cpp.
Ah, good to know. This define is not in the clang-2.6.tar.gz snapshot
that comes with the LLVM 2.6 prerelease, though -- is this something
that is trunk-specific? Would later prereleases, and the final 2.6,
have this define that then has to be taken out?


Michel Alexandre Salim

More information about the cfe-dev mailing list