threads test failure on llvm-svn bot

[yuyichao]

It seems that the llvm-svn bot cannot find the __atomic_* symbols for Int128 atomics. This should have been fixed by https://github.com/JuliaLang/julia/pull/16066 so I'm guessing if libatomic1 is not installed on the buildbot. (If it is installed, then it would be helpful to see why can't julia find it or why can't the symbol be loaded from the lib)

As @tkelman pointed out, it is a little annoy to add another dependency that requires root (shipping this lib ourselves is possible but technically invalid, only one copy of this lib should exist at runtime since there's shared global state (lock)). So maybe we can throw a better error if the symbol is not found instead of letting llvm exit. It's still better to make the test pass on the buildbot though.

[yuyichao]

@staticfloat

[tkelman]

is it under an soname?

[yuyichao]

By default, yes, but I'm using the function that should check the soname.

[tkelman]

I'm using the function that should check the soname.

You sure dlopen does that?

[staticfloat]

We’re using GCC 4.8:

$ gcc --version
gcc (Ubuntu 4.8.4-2ubuntu1~14.04.1) 4.8.4

And it looks like we have a libatomic:

$ ldconfig -p | grep atom
        libatomic.so.1 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libatomic.so.1
$ file /usr/lib/x86_64-linux-gnu/libatomic.so.1.0.0
/usr/lib/x86_64-linux-gnu/libatomic.so.1.0.0: ELF 64-bit LSB  shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=8833bf8f9b567574b05494bded7f64d037b09bed, stripped

The julia being built by the llvm-svn seems to dlopen() it just fine, and it can find the __atomic_store symbol:

julia> Libdl.dlpath(Libdl.dlopen("libatomic"))
"/usr/lib/x86_64-linux-gnu/libatomic.so.1"

julia> Libdl.dlsym(Libdl.dlopen("libatomic"), :__atomic_store)
Ptr{Void} @0x00007f3fd21ede50

So I'm not sure what to say here except that there must be something weird in the test code? PM me on slack if you want to SSH in and poke around yourself.

[yuyichao]

You sure dlopen does that?

No, but I think I'm using jl_load_dynamic_library_e which should.

[tkelman]

I just looked a few levels in and that function seemed to be a pretty basic wrapper around dlopen?

[tkelman]

  | | |_| | | | (_| |  |  Version 0.4.5 (2016-03-18 00:58 UTC)
 _/ |\__'_|_|_|\__'_|  |  Official http://julialang.org release
|__/                   |  x86_64-linux-gnu

julia> Libdl.dlpath(Libdl.dlopen("libatomic.so"))
ERROR: could not load library "libatomic.so"
libatomic.so: cannot open shared object file: No such file or directory
 in dlopen at ./libdl.jl:36
 in dlopen at libdl.jl:36

julia> Libdl.dlpath(Libdl.dlopen("libatomic.so.1"))
"/usr/bin/../lib/x86_64-linux-gnu/libatomic.so.1"

julia> Libdl.dlpath(Libdl.dlopen("libatomic"))
"/usr/bin/../lib/x86_64-linux-gnu/libatomic.so.1"

[staticfloat]

Yeah, in general, you shouldn't put extensions on library names when using dlopen(), because otherwise it messes up soversion searching, and doesn't generalize across platforms.

[yuyichao]

Ah, This is linux only so I included the .so. I didn't realize that it breaks the soname lookup though....