FFTW doesn't work on arm: libm.so: cannot open shared object file: No such file or directory

[giordano]

See https://cloud.drone.io/giordano/FFTW.jl/3/1/2. @ararslan today told me that probably the builder needs to depend on https://github.com/JuliaMath/OpenlibmBuilder to make sure that OpenLibm is used, instead of looking for system libm.

[ararslan]

We just need a way to guarantee that when FFTW is built, it links to a libm that will definitely be available. Otherwise the shared library will say, "I need libm.so because that's what I linked to when I was built," but won't be able to find it if it isn't within the RPATH set for it by BinaryBuilder.

[ararslan]

That said, it's weird that this isn't happening on other platforms. Ideally it will just be using Julia's libm (openlibm), which should already be loaded. @staticfloat, do you have any sagely guidance for us here as to what we should be looking for to diagnose this?

[staticfloat]

Let's start by looking at what julia (or libjulia) links against for its libm, and then look at what the FFTW binaries are linking against.

[stevengj]

Can this be fixed in BinaryBuilder itself? It would be painful if every package that depends on libm has to jump through a bunch of hoops in its build script.

[staticfloat]

We'll know if it can be fixed once we know what the problem is. It's still unclear to me what is linking against what.

[ararslan]

I don't have access to an ARM machine. @giordano, can you do ldd on the Julia executable or libjulia?

[ararslan]

Also check whether from Julia you can dlopen libfftw.

[giordano]

can you do ldd on the Julia executable or libjulia?

$ ldd $(which julia)
libjulia.so.1 => /usr/local/julia/bin/../lib/libjulia.so.1 (0xf7ca5000)
libdl.so.2 => /lib/arm-linux-gnueabihf/libdl.so.2 (0xf7c92000)
librt.so.1 => /lib/arm-linux-gnueabihf/librt.so.1 (0xf7c7c000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xf7c58000)
libgcc_s.so.1 => /lib/arm-linux-gnueabihf/libgcc_s.so.1 (0xf7c2f000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf7b41000)
libLLVM-6.0.so => /usr/local/julia/bin/../lib/julia/libLLVM-6.0.so (0xf5acf000)
libstdc++.so.6 => /usr/local/julia/bin/../lib/julia/libstdc++.so.6 (0xf5989000)
libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xf5911000)
/lib/ld-linux-armhf.so.3 (0xf7fa1000)

[ararslan]

Can you also check ldd on libfftw?

[staticfloat]

I bet the problem is that libFFTW is looking for libm.so but only libm.so.6 is available.

[giordano]

Also check whether from Julia you can dlopen libfftw.

I don't get any error in the command Libdl.dlopen(FFTW.libfftw3), so I guess it works: https://cloud.drone.io/giordano/FFTW.jl/9/1/2

[giordano]

Can you also check ldd on libfftw?

Output of ldd on FFTW.libfftw3:

libm.so.6 => /lib/arm-linux-gnueabihf/libm.so.6 (0xf7c33000)
libpthread.so.0 => /lib/arm-linux-gnueabihf/libpthread.so.0 (0xf7c0f000)
libc.so.6 => /lib/arm-linux-gnueabihf/libc.so.6 (0xf7b21000)
/lib/ld-linux-armhf.so.3 (0xf7d65000)

https://cloud.drone.io/giordano/FFTW.jl/10/1/2

[giordano]

I bet the problem is that libFFTW is looking for libm.so but only libm.so.6 is available.

It's true that there is only libm.s0.6:

$ find / -name 'libm.so*' 2> /dev/null
/lib/arm-linux-gnueabihf/libm.so.6

https://cloud.drone.io/giordano/FFTW.jl/11/1/2

However, this is true also on arm64, where tests are passing:

$ find / -name 'libm.so*' 2> /dev/null
/lib/aarch64-linux-gnu/libm.so.6

https://cloud.drone.io/giordano/FFTW.jl/11/3/2
But on this system Julia is using libopenlibm, see the output of versioninfo() below in the log, contrary to the arm architecture when libm is used.

[staticfloat]

It looks like we explicitly do not use openlibm on armv7l, but the reason for that may be very outdated. I am checking with Viral to see if we can't just use openlibm everywhere.

[IanButterworth]

Can this be solved? I'm still seeing the issue

x-ref JuliaLang/julia#32257

[giordano]

Fixed in Julia 1.3 by JuliaLang/julia#32803: https://cloud.drone.io/giordano/FFTW.jl/12/1/2