Issues when building swift using GNU 2.26 related to protected symbols

Development Compiler
1

Hi,

I was running some tests using newer GNU ld, and I hit this issue:

/usr/bin/ld: stdlib/public/core/linux/x86_64/Swift.o: relocation
R_X86_64_PC32 against protected symbol
`_Tvs19_emptyStringStorageVs6UInt32' can not be used when making a
shared object

I could work around that issue by moving the definition into a C++
file, but that didn't get me far -- I got the same error, but about
'_TMPSa' (generic type metadata pattern for Swift.Array).

Does it seem like a bug in LLVM codegen or another bug in GNU ld that
was introduced recently?

This issue will prevent Swift from compiling on Ubuntu 16.04 or a recent Debian.

Dmitri

···

--
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>*/

2

Smells like a GNU ld bug to me. That relocation ought to be resolvable within the dynamic library, unless for some reason _Tvs19_emptyStringStorageVs6UInt32 is not defined in the standard library or runtime.

-Joe

···

On Feb 20, 2016, at 8:06 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

Hi,

I was running some tests using newer GNU ld, and I hit this issue:

/usr/bin/ld: stdlib/public/core/linux/x86_64/Swift.o: relocation
R_X86_64_PC32 against protected symbol
`_Tvs19_emptyStringStorageVs6UInt32' can not be used when making a
shared object

I could work around that issue by moving the definition into a C++
file, but that didn't get me far -- I got the same error, but about
'_TMPSa' (generic type metadata pattern for Swift.Array).

Does it seem like a bug in LLVM codegen or another bug in GNU ld that
was introduced recently?

This issue will prevent Swift from compiling on Ubuntu 16.04 or a recent Debian.

3

OK. So what's the way forward? Obviously, we can't leave Swift
broken on Ubuntu 16.04.

Dmitri

···

On Mon, Feb 22, 2016 at 9:07 AM, Joe Groff <jgroff@apple.com> wrote:

On Feb 20, 2016, at 8:06 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

Hi,

I was running some tests using newer GNU ld, and I hit this issue:

/usr/bin/ld: stdlib/public/core/linux/x86_64/Swift.o: relocation
R_X86_64_PC32 against protected symbol
`_Tvs19_emptyStringStorageVs6UInt32' can not be used when making a
shared object

I could work around that issue by moving the definition into a C++
file, but that didn't get me far -- I got the same error, but about
'_TMPSa' (generic type metadata pattern for Swift.Array).

Does it seem like a bug in LLVM codegen or another bug in GNU ld that
was introduced recently?

This issue will prevent Swift from compiling on Ubuntu 16.04 or a recent Debian.

Smells like a GNU ld bug to me. That relocation ought to be resolvable within the dynamic library, unless for some reason _Tvs19_emptyStringStorageVs6UInt32 is not defined in the standard library or runtime.

--
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>*/

4

Let's make sure it isn't our bug first. Is _Tvs19_emptyStringStorageVs6UInt32 defined in any of the .o or .a files that get linked into the core?

-Joe

···

On Feb 22, 2016, at 9:28 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Feb 22, 2016 at 9:07 AM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Feb 20, 2016, at 8:06 PM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

Hi,

I was running some tests using newer GNU ld, and I hit this issue:

/usr/bin/ld: stdlib/public/core/linux/x86_64/Swift.o: relocation
R_X86_64_PC32 against protected symbol
`_Tvs19_emptyStringStorageVs6UInt32' can not be used when making a
shared object

I could work around that issue by moving the definition into a C++
file, but that didn't get me far -- I got the same error, but about
'_TMPSa' (generic type metadata pattern for Swift.Array).

Does it seem like a bug in LLVM codegen or another bug in GNU ld that
was introduced recently?

This issue will prevent Swift from compiling on Ubuntu 16.04 or a recent Debian.

Smells like a GNU ld bug to me. That relocation ought to be resolvable within the dynamic library, unless for some reason _Tvs19_emptyStringStorageVs6UInt32 is not defined in the standard library or runtime.

OK. So what's the way forward? Obviously, we can't leave Swift
broken on Ubuntu 16.04.

5

Yes, it is there:

$ nm stdlib/public/core/linux/x86_64/Swift.o | grep
_Tvs19_emptyStringStorageVs6UInt32
0000000000000020 B _Tvs19_emptyStringStorageVs6UInt32

Dmitri

···

On Mon, Feb 22, 2016 at 9:30 AM, Joe Groff <jgroff@apple.com> wrote:

Let's make sure it isn't our bug first. Is
_Tvs19_emptyStringStorageVs6UInt32 defined in any of the .o or .a files that
get linked into the core?

--
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>*/

6

Does it only fail with GNU ld on 16.04? Does it work on older Ubuntus, or with gold?

-Joe

···

On Feb 22, 2016, at 10:21 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Feb 22, 2016 at 9:30 AM, Joe Groff <jgroff@apple.com> wrote:

Let's make sure it isn't our bug first. Is
_Tvs19_emptyStringStorageVs6UInt32 defined in any of the .o or .a files that
get linked into the core?

Yes, it is there:

$ nm stdlib/public/core/linux/x86_64/Swift.o | grep
_Tvs19_emptyStringStorageVs6UInt32
0000000000000020 B _Tvs19_emptyStringStorageVs6UInt32

7

It works with GNU ld 2.24 (on Ubuntu 14.04), and with gold on current Debian.

Dmitri

···

On Mon, Feb 22, 2016 at 10:23 AM, Joe Groff <jgroff@apple.com> wrote:

On Feb 22, 2016, at 10:21 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Feb 22, 2016 at 9:30 AM, Joe Groff <jgroff@apple.com> wrote:

Let's make sure it isn't our bug first. Is
_Tvs19_emptyStringStorageVs6UInt32 defined in any of the .o or .a files that
get linked into the core?

Yes, it is there:

$ nm stdlib/public/core/linux/x86_64/Swift.o | grep
_Tvs19_emptyStringStorageVs6UInt32
0000000000000020 B _Tvs19_emptyStringStorageVs6UInt32

Does it only fail with GNU ld on 16.04? Does it work on older Ubuntus, or with gold?

--
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>*/

8

is there a reliable way to trigger the error? I haven’t seen this on any of my machines (all Ubuntu 14.04 or 15.<whatever>)

- Will

···

On Feb 22, 2016, at 10:23 AM, Joe Groff via swift-dev <swift-dev@swift.org> wrote:

On Feb 22, 2016, at 10:21 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Feb 22, 2016 at 9:30 AM, Joe Groff <jgroff@apple.com> wrote:

Let's make sure it isn't our bug first. Is
_Tvs19_emptyStringStorageVs6UInt32 defined in any of the .o or .a files that
get linked into the core?

Yes, it is there:

$ nm stdlib/public/core/linux/x86_64/Swift.o | grep
_Tvs19_emptyStringStorageVs6UInt32
0000000000000020 B _Tvs19_emptyStringStorageVs6UInt32

Does it only fail with GNU ld on 16.04? Does it work on older Ubuntus, or with gold?

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

9

Does linking with -Bsymbolic work around the bug? `protected` is supposed to make that unnecessary, but maybe they regressed.

-Joe

···

On Feb 22, 2016, at 10:25 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Feb 22, 2016 at 10:23 AM, Joe Groff <jgroff@apple.com <mailto:jgroff@apple.com>> wrote:

On Feb 22, 2016, at 10:21 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Feb 22, 2016 at 9:30 AM, Joe Groff <jgroff@apple.com> wrote:

Let's make sure it isn't our bug first. Is
_Tvs19_emptyStringStorageVs6UInt32 defined in any of the .o or .a files that
get linked into the core?

Yes, it is there:

$ nm stdlib/public/core/linux/x86_64/Swift.o | grep
_Tvs19_emptyStringStorageVs6UInt32
0000000000000020 B _Tvs19_emptyStringStorageVs6UInt32

Does it only fail with GNU ld on 16.04? Does it work on older Ubuntus, or with gold?

It works with GNU ld 2.24 (on Ubuntu 14.04), and with gold on current Debian.

10

Try building on Ubuntu 16.04 or Debian Sid.

Dmitri

···

On Mon, Feb 22, 2016 at 10:27 AM, William Dillon <william@housedillon.com> wrote:

is there a reliable way to trigger the error? I haven’t seen this on any of my machines (all Ubuntu 14.04 or 15.<whatever>)

--
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>*/

11

16.04 isn't released till April, right? Any chance we can report this problem to them and hopefully get a fix before then?

-Joe

···

On Feb 22, 2016, at 10:33 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Feb 22, 2016 at 10:27 AM, William Dillon > <william@housedillon.com> wrote:

is there a reliable way to trigger the error? I haven’t seen this on any of my machines (all Ubuntu 14.04 or 15.<whatever>)

Try building on Ubuntu 16.04 or Debian Sid.

12

is there a reliable way to trigger the error? I haven’t seen this on any of my machines (all Ubuntu 14.04 or 15.<whatever>)

Try building on Ubuntu 16.04 or Debian Sid.

16.04 isn't released till April, right?

Right.

Any chance we can report this problem to them and hopefully get a fix before then?

Possibly. Someone other than me should do this, though. William, if
you are interested, could you do this? It would be best if we could
create a simple example that demonstrates the issue.

Dmitri

···

On Mon, Feb 22, 2016 at 10:39 AM, Joe Groff <jgroff@apple.com> wrote:

On Feb 22, 2016, at 10:33 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:
On Mon, Feb 22, 2016 at 10:27 AM, William Dillon >> <william@housedillon.com> wrote:

--
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>*/

13

I’ll see what I can find. I’m bringing up a VM.

···

On Feb 22, 2016, at 10:58 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Feb 22, 2016 at 10:39 AM, Joe Groff <jgroff@apple.com> wrote:

On Feb 22, 2016, at 10:33 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Feb 22, 2016 at 10:27 AM, William Dillon >>> <william@housedillon.com> wrote:

is there a reliable way to trigger the error? I haven’t seen this on any of my machines (all Ubuntu 14.04 or 15.<whatever>)

Try building on Ubuntu 16.04 or Debian Sid.

16.04 isn't released till April, right?

Right.

Any chance we can report this problem to them and hopefully get a fix before then?

Possibly. Someone other than me should do this, though. William, if
you are interested, could you do this? It would be best if we could
create a simple example that demonstrates the issue.

Dmitri

--
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>*/

14

Possibly. Someone other than me should do this, though. William, if

you are interested, could you do this? It would be best if we could
create a simple example that demonstrates the issue.

Not sure if this is known (I don't see mention of it on list), but there is
an
upstream LLVM bug for this issue:

https://llvm.org/bugs/show_bug.cgi?id=26580

-- Meador

···

On Mon, Feb 22, 2016 at 12:58 PM, Dmitri Gribenko via swift-dev < swift-dev@swift.org> wrote:

15

Geez, VMs are slow… :)

So, I was able to reproduce Dmitri’s error on 16.04. Adding -Bsymbolic to the linker arguments in cmake/modules/AddSwift.cmake makes it go away. Of course, it is unsatisfying to have this regression after Joe’s excellent work making them obsolete.

- Will

···

On Feb 22, 2016, at 11:11 AM, William Dillon via swift-dev <swift-dev@swift.org> wrote:

I’ll see what I can find. I’m bringing up a VM.

On Feb 22, 2016, at 10:58 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Feb 22, 2016 at 10:39 AM, Joe Groff <jgroff@apple.com> wrote:

On Feb 22, 2016, at 10:33 AM, Dmitri Gribenko <gribozavr@gmail.com> wrote:

On Mon, Feb 22, 2016 at 10:27 AM, William Dillon >>>> <william@housedillon.com> wrote:

is there a reliable way to trigger the error? I haven’t seen this on any of my machines (all Ubuntu 14.04 or 15.<whatever>)

Try building on Ubuntu 16.04 or Debian Sid.

16.04 isn't released till April, right?

Right.

Any chance we can report this problem to them and hopefully get a fix before then?

Possibly. Someone other than me should do this, though. William, if
you are interested, could you do this? It would be best if we could
create a simple example that demonstrates the issue.

Dmitri

--
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>*/

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

16

Thanks for trying it out, Will. I agree that requiring -Bsymbolic is unfortunate, but it's good to know we have a workaround in case this can't be fixed in time for 16.04.

-Joe

···

On Feb 23, 2016, at 8:31 AM, William Dillon via swift-dev <swift-dev@swift.org> wrote:

Geez, VMs are slow… :)

So, I was able to reproduce Dmitri’s error on 16.04. Adding -Bsymbolic to the linker arguments in cmake/modules/AddSwift.cmake makes it go away. Of course, it is unsatisfying to have this regression after Joe’s excellent work making them obsolete.