build 3.3.9-alpha1

[stevengj]

This builds a prerelease FFTW tarball with a new undocumented feature that will hopefully let us easily support partr threads in Julia 1.3 (FFTW/fftw3#175)

[stevengj]

@staticfloat, I'm seeing an odd clang failure on MacOS Travis that I can't replicate on my local machine (with Apple LLVM version 10.0.1 (clang-1001.0.46.4)). Any ideas? It used to build fine, so I'm not sure what changed.

_fftw_rdft_conf_standard in librdft.a(conf.o)
  "_fftw_have_simd_avx2_128", referenced from:
      _fftw_dft_conf_standard in libdft.a(conf.o)
      _fftw_rdft_conf_standard in librdft.a(conf.o)
  "_fftw_have_simd_sse2", referenced from:
      _fftw_dft_conf_standard in libdft.a(conf.o)
      _fftw_rdft_conf_standard in librdft.a(conf.o)
  "_fftw_join_taint", referenced from:
      _fftw_mkproblem_dft in libdft.a(problem.o)
      _fftw_mkproblem_rdft in librdft.a(problem.o)
      _fftw_mkproblem_rdft2 in librdft.a(problem2.o)
  "_fftw_rdft_hb_genus", referenced from:
      _desc in librdft_scalar_r2cb.a(hb_2.o)
      _desc in librdft_scalar_r2cb.a(hb_3.o)
      _desc in librdft_scalar_r2cb.a(hb_4.o)
      _desc in librdft_scalar_r2cb.a(hb_5.o)
      _desc in librdft_scalar_r2cb.a(hb_6.o)
      _desc in librdft_scalar_r2cb.a(hb_7.o)
      _desc in librdft_scalar_r2cb.a(hb_8.o)
      ...
  "_fftw_rdft_hc2cb_genus", referenced from:
      _desc in librdft_scalar_r2cb.a(hc2cb_2.o)
      _desc in librdft_scalar_r2cb.a(hc2cb_4.o)
      _desc in librdft_scalar_r2cb.a(hc2cb_6.o)
      _desc in librdft_scalar_r2cb.a(hc2cb_8.o)
      _desc in librdft_scalar_r2cb.a(hc2cb_10.o)
      _desc in librdft_scalar_r2cb.a(hc2cb_12.o)
      _desc in librdft_scalar_r2cb.a(hc2cb_16.o)
      ...
  "_fftw_rdft_hc2cf_genus", referenced from:
      _desc in librdft_scalar_r2cf.a(hc2cf_2.o)
      _desc in librdft_scalar_r2cf.a(hc2cf_4.o)
      _desc in librdft_scalar_r2cf.a(hc2cf_6.o)
      _desc in librdft_scalar_r2cf.a(hc2cf_8.o)
      _desc in librdft_scalar_r2cf.a(hc2cf_10.o)
      _desc in librdft_scalar_r2cf.a(hc2cf_12.o)
      _desc in librdft_scalar_r2cf.a(hc2cf_16.o)
      ...
  "_fftw_rdft_hf_genus", referenced from:
      _desc in librdft_scalar_r2cf.a(hf_2.o)
      _desc in librdft_scalar_r2cf.a(hf_3.o)
      _desc in librdft_scalar_r2cf.a(hf_4.o)
      _desc in librdft_scalar_r2cf.a(hf_5.o)
      _desc in librdft_scalar_r2cf.a(hf_6.o)
      _desc in librdft_scalar_r2cf.a(hf_7.o)
      _desc in librdft_scalar_r2cf.a(hf_8.o)
      ...
  "_fftw_rdft_r2cbIII_genus", referenced from:
      _desc in librdft_scalar_r2cb.a(r2cbIII_2.o)
      _desc in librdft_scalar_r2cb.a(r2cbIII_3.o)
      _desc in librdft_scalar_r2cb.a(r2cbIII_4.o)
      _desc in librdft_scalar_r2cb.a(r2cbIII_5.o)
      _desc in librdft_scalar_r2cb.a(r2cbIII_6.o)
      _desc in librdft_scalar_r2cb.a(r2cbIII_7.o)
      _desc in librdft_scalar_r2cb.a(r2cbIII_8.o)
      ...
  "_fftw_rdft_r2cb_genus", referenced from:
      _desc in librdft_scalar_r2cb.a(r2cb_2.o)
      _desc in librdft_scalar_r2cb.a(r2cb_3.o)
      _desc in librdft_scalar_r2cb.a(r2cb_4.o)
      _desc in librdft_scalar_r2cb.a(r2cb_5.o)
      _desc in librdft_scalar_r2cb.a(r2cb_6.o)
      _desc in librdft_scalar_r2cb.a(r2cb_7.o)
      _desc in librdft_scalar_r2cb.a(r2cb_8.o)
      ...
  "_fftw_rdft_r2cfII_genus", referenced from:
      _desc in librdft_scalar_r2cf.a(r2cfII_2.o)
      _desc in librdft_scalar_r2cf.a(r2cfII_3.o)
      _desc in librdft_scalar_r2cf.a(r2cfII_4.o)
      _desc in librdft_scalar_r2cf.a(r2cfII_5.o)
      _desc in librdft_scalar_r2cf.a(r2cfII_6.o)
      _desc in librdft_scalar_r2cf.a(r2cfII_7.o)
      _desc in librdft_scalar_r2cf.a(r2cfII_8.o)
      ...
  "_fftw_rdft_r2cf_genus", referenced from:
      _desc in librdft_scalar_r2cf.a(r2cf_2.o)
      _desc in librdft_scalar_r2cf.a(r2cf_3.o)
      _desc in librdft_scalar_r2cf.a(r2cf_4.o)
      _desc in librdft_scalar_r2cf.a(r2cf_5.o)
      _desc in librdft_scalar_r2cf.a(r2cf_6.o)
      _desc in librdft_scalar_r2cf.a(r2cf_7.o)
      _desc in librdft_scalar_r2cf.a(r2cf_8.o)
      ...
  "_fftw_rdft_r2r_genus", referenced from:
      _desc in librdft_scalar_r2r.a(e01_8.o)
      _desc in librdft_scalar_r2r.a(e10_8.o)
  "_fftw_taint", referenced from:
      _mkplan in libdft.a(buffered.o)
      _mkplan in libdft.a(indirect-transpose.o)
      _mkplan in libdft.a(vrank-geq1.o)
      _mkplan in librdft.a(buffered.o)
      _mkcldw in librdft.a(hc2hc-direct.o)
      _mkplan in librdft.a(vrank-geq1.o)
      _mkcldrn_gcd in librdft.a(vrank3-transpose.o)
      ...
ld: symbol(s) not found for architecture x86_64
clang-6.0: error: linker command failed with exit code 1 (use -v to see invocation)
make[1]: *** [Makefile:641: libfftw3.la] Error 1
make[1]: Leaving directory '/workspace/srcdir/fftw-3.3.9-alpha1/double'
make: *** [Makefile:707: install-recursive] Error 1
ERROR: LoadError: Build for FFTW on x86_64-apple-darwin14 did not complete successfully

[StefanKarpinski]

@staticfloat, any ideas?

[staticfloat]

Occasionally, the gnu binutils toolchain on MacOS generates bad stuff. I don't know why, it's a known issue. Luckily, we can use the LLVM toolchain as a drop-in replacement. Put the following before you configure and it should work:

if [[ ${target} == *darwin* ]]; then
    export RANLIB=llvm-ranlib
fi

Why not just always use the LLVM ranlib on MacOS you ask? Well, because it doesn't always work. Although it has improved over time, and since the next version of BB will use LLVM 8 by default, it may be good enough that we can just use it by default.

Also, I suggest doing a make -j${nprocs} before your make install invocations; it speeds things up quite a bit.

[stevengj]

Thanks @staticfloat, I just pushed the patches you suggested.

[stevengj]

It now builds, but is refusing to upload:

Preparing deploy
/home/travis/.rvm/gems/ruby-2.4.1/gems/octokit-4.6.2/lib/octokit/response/raise_error.rb:16:in `on_complete': GET https://api.github.com/user: 401 - Bad credentials // See: https://developer.github.com/v3 (Octokit::Unauthorized)

It used to work — how did I screw this up?

Did BinaryBuilder change how you are supposed to do build in parts (with --part)?

[staticfloat]

Bad credentials sounds like your token is not being picked up. How are you providing the github token, and are you certain it was not deleted from your account?

[stevengj]

I created the token a while back with travis setup releases… it worked for previous releases. Not sure how it could have been deleted?

[stevengj]

Oh !@#$@$ github, I just looked in https://github.com/settings/security and saw a bunch of log messages like:

oauth_authorization.destroy  – Personal access token (automatic releases for JuliaPackaging/CMakeBuilder) deleted automatically (not recently used)

So it looks like I will need to re-create most of my personal access tokens.

Is there a way to prevent them from being deleted just because I haven't used them recently?

[stevengj]

I re-created the travis tokens via travis setup releases and everything looks good. Incorporated into FFTW.jl via JuliaMath/FFTW.jl#105