Okay, I'll go with a stable Clang like v3.3. Have to build it myself,
though, as Debian comes with v3.0.
No, I didn't try using libstdc++. I'll give it a shot.
The machine is going to be turned on 24/7 until it dies from old age, so I
don't know if it is worth scheduling in a special manner. The worst part
is linking as I cannot use Gold because I get an error about an unsupported
relocation time.
-- Mikael
2013/11/18 Shankar Easwaran <shankare at codeaurora.org>
> On 11/18/2013 11:57 AM, Mikael Lyngvig wrote:
>
>> I'm in the process of configuring a Mac Mini G4 (PowerPC,
big-endian) to
>> be
>> an LLD buildbot slave, as there were some who wanted a big-endian
tester
>> of
>> LLD.
>>
>> I have a few quick questions with respect to that:
>>
>> 1. LLD appears to be built using Clang, but Clang is not built as part
of
>> the LLD build. So which version of Clang should I use? v3.3 or any
>> nightly build of Clang. Is it enough that I occasionally build a
Clang,
>> install it, and use that?
>>
> It would be better in my opinion to use a stable clang build. I dont know
> if any other project build uses the clang that was just built ?
>
>> 2. I'm not sure how to test LLD properly. Is the test of LLD
included in
>> the LLVM test suite or how do I ensure that the LLD test suite gets run
on
>> this big-endian setup? (This is the whole point of setting up a
big-endian
>> LLD buildbot slave: To test LLD in a big-endian environment.)
>>
> make check-lld from the lld build would run the lld tests.
>
>> 3. When trying to use a self-built version of Clang, I get an error
about
>> libc++ missing when the buildbot slave tries to build LLD. When I
build
>> and install libc++, I get unresolved symbols (GNU exception handling
>> support routines) of the form "/usr/local/lib/libc++.so: undefined
>> reference to `__cxa_end_catch'".
>>
> Did you try using libstdc++ ?
>
> As far as I am concerned, this build slave is not going be valuable in
>> terms of quickly reporting errors (it is only 1,25 GHz, so it is simply
>> too
>> slow for that), but rather it will serve by testing LLD in a big-endian
>> setting. I do hope that this build slave will reveal a number of
issues
>> in
>> LLD.
>>
> May be the buildslave can be scheduled less often ?
>
> Thanks
>
> Shankar Easwaran
>
> --
> Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted
> by the Linux Foundation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131118/aaf75656/attachment.html>