Build failure? "LLVM ERROR: Cannot represent a subtraction with a weak symbol"

Development Compiler
1

Hello all!

I'm encountering a build failure when compiling the stdlib, using the tip
of master as of this morning (d44d6e). I'm running Ubuntu 15.10 on a x86_64
machine.

Here are my build logs:
https://gist.github.com/modocache/a85851a53b570d5fca47\. The logs show that
I remove my build directory completely, before starting a clean build with
`utils/build-script -R`.

I was surprised to see a build failure, so I tried a bisect to narrow down
what may have caused it. Here's the log from the bisect, which I made
between master (d44d6e) and a known good commit (061c77):

The bisect points to commit 638e4b, "IRGen/Runtime: Use relative addresses
in nominal type descriptors". But I'm skeptical: that commit is weeks old,
and was even included in swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a. I very
much doubt it introduced a build failure.

I tried building swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a, and even *that*
doesn't build on my system!! I assume this snapshot has passed CI, so I
thought there must be something wrong with my system. But William Dillion
tells me he's experiencing the same error (
https://twitter.com/hpux735/status/692758868670058496\).

William and I are both working on armv7 ports, so perhaps both of our build
machines are similarly broken. But I'm curious if anyone has any ideas on
what the problem might be, or if this build error reproduces for anyone
else building on Linux. Thoughts?

- Brian Gesiak

2

Hi, Brian. This required an update to LLVM as well, which Lang Hames should have cherry-picked to the stable branch. Are your LLVM and Clang fully up to date?

Jordan

···

On Jan 28, 2016, at 9:44 , Brian Gesiak via swift-dev <swift-dev@swift.org> wrote:

Hello all!

I'm encountering a build failure when compiling the stdlib, using the tip of master as of this morning (d44d6e). I'm running Ubuntu 15.10 on a x86_64 machine.

Here are my build logs: https://gist.github.com/modocache/a85851a53b570d5fca47\. The logs show that I remove my build directory completely, before starting a clean build with `utils/build-script -R`.

I was surprised to see a build failure, so I tried a bisect to narrow down what may have caused it. Here's the log from the bisect, which I made between master (d44d6e) and a known good commit (061c77): gist:89c347a3c50767eee7eb · GitHub

The bisect points to commit 638e4b, "IRGen/Runtime: Use relative addresses in nominal type descriptors". But I'm skeptical: that commit is weeks old, and was even included in swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a. I very much doubt it introduced a build failure.

I tried building swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a, and even *that* doesn't build on my system!! I assume this snapshot has passed CI, so I thought there must be something wrong with my system. But William Dillion tells me he's experiencing the same error (https://twitter.com/hpux735/status/692758868670058496\).

William and I are both working on armv7 ports, so perhaps both of our build machines are similarly broken. But I'm curious if anyone has any ideas on what the problem might be, or if this build error reproduces for anyone else building on Linux. Thoughts?

- Brian Gesiak
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

3

Thanks, Jordan!

I had thought they were, since I recall running `utils/update-checkout`
soon after encountering the error. I just tried a `git pull --rebase origin
stable` from within my `llvm` directory, though, and that pulled in 249898
"[RuntimeDyld] Fix a class of arithmetic errors introduced in r253918".
Sounds very relevant to my problem! :)

I'm building again now after pulling in the changes--if you don't hear from
me assume that everything works now. Thanks again for your help!

- Brian Gesiak

···

On Thu, Jan 28, 2016 at 1:09 PM, Jordan Rose <jordan_rose@apple.com> wrote:

Hi, Brian. This required an update to LLVM as well, which Lang Hames
should have cherry-picked to the stable branch. Are your LLVM and Clang
fully up to date?

Jordan

On Jan 28, 2016, at 9:44 , Brian Gesiak via swift-dev <swift-dev@swift.org> > wrote:

Hello all!

I'm encountering a build failure when compiling the stdlib, using the tip
of master as of this morning (d44d6e). I'm running Ubuntu 15.10 on a x86_64
machine.

Here are my build logs:
https://gist.github.com/modocache/a85851a53b570d5fca47\. The logs show
that I remove my build directory completely, before starting a clean build
with `utils/build-script -R`.

I was surprised to see a build failure, so I tried a bisect to narrow down
what may have caused it. Here's the log from the bisect, which I made
between master (d44d6e) and a known good commit (061c77):
gist:89c347a3c50767eee7eb · GitHub

The bisect points to commit 638e4b, "IRGen/Runtime: Use relative addresses
in nominal type descriptors". But I'm skeptical: that commit is weeks old,
and was even included in swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a. I very
much doubt it introduced a build failure.

I tried building swift-DEVELOPMENT-SNAPSHOT-2016-01-25-a, and even *that*
doesn't build on my system!! I assume this snapshot has passed CI, so I
thought there must be something wrong with my system. But William Dillion
tells me he's experiencing the same error (
https://twitter.com/hpux735/status/692758868670058496\).

William and I are both working on armv7 ports, so perhaps both of our
build machines are similarly broken. But I'm curious if anyone has any
ideas on what the problem might be, or if this build error reproduces for
anyone else building on Linux. Thoughts?

- Brian Gesiak
_______________________________________________
swift-dev mailing list
swift-dev@swift.org
https://lists.swift.org/mailman/listinfo/swift-dev

4

Did you do `update-checkout -a` ? The default option set only updates swift.

Dmitri

···

On Thu, Jan 28, 2016 at 10:28 AM, Brian Gesiak via swift-dev <swift-dev@swift.org> wrote:

Thanks, Jordan!

I had thought they were, since I recall running `utils/update-checkout` soon
after encountering the error.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

5

This probably predates having a stable branch for LLVM and Clang; maybe we should just remove it.

Jordan

···

On Jan 28, 2016, at 10:31, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Thu, Jan 28, 2016 at 10:28 AM, Brian Gesiak via swift-dev > <swift-dev@swift.org> wrote:

Thanks, Jordan!

I had thought they were, since I recall running `utils/update-checkout` soon
after encountering the error.

Did you do `update-checkout -a` ? The default option set only updates swift.

6

Well, updating all repositories serially as we do it now takes quite
some time. If we could do it in parallel...

Dmitri

···

On Thu, Jan 28, 2016 at 10:32 AM, Jordan Rose <jordan_rose@apple.com> wrote:

On Jan 28, 2016, at 10:31, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Thu, Jan 28, 2016 at 10:28 AM, Brian Gesiak via swift-dev >> <swift-dev@swift.org> wrote:

Thanks, Jordan!

I had thought they were, since I recall running `utils/update-checkout` soon
after encountering the error.

Did you do `update-checkout -a` ? The default option set only updates swift.

This probably predates having a stable branch for LLVM and Clang; maybe we should just remove it.

--
main(i,j){for(i=2;;i++){for(j=2;j<i;j++){if(!(i%j)){j=0;break;}}if
(j){printf("%d\n",i);}}} /*Dmitri Gribenko <gribozavr@gmail.com>*/

7

I always assumed the limiting factor was the network. If that's not the case, then sure!

Jordan

···

On Jan 28, 2016, at 10:34, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Thu, Jan 28, 2016 at 10:32 AM, Jordan Rose <jordan_rose@apple.com> wrote:

On Jan 28, 2016, at 10:31, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Thu, Jan 28, 2016 at 10:28 AM, Brian Gesiak via swift-dev >>> <swift-dev@swift.org> wrote:

Thanks, Jordan!

I had thought they were, since I recall running `utils/update-checkout` soon
after encountering the error.

Did you do `update-checkout -a` ? The default option set only updates swift.

This probably predates having a stable branch for LLVM and Clang; maybe we should just remove it.

Well, updating all repositories serially as we do it now takes quite
some time. If we could do it in parallel...