octave @4.2.1 build failure on SnowLeopard with clang-3.9 due to malformed object error, but succeeds with clang-3.8

[kencu (Ken)]

During a revbump of octave, with my default compiler now set to clang-3.9, this failure occurs:

/opt/local/bin/ranlib: file: .libs/libgnu.a(unistd.o) has no symbols
/opt/local/bin/ranlib: file: .libs/libgnu.a(wctype-h.o) has no symbols
/opt/local/bin/ranlib: file: .libs/libgnu.a(xsize.o) has no symbols
  GEN      liboctave/operators/mx-ui64nda-i16nda.h
  GEN      liboctave/operators/mx-ui64nda-ui16nda.h
/usr/bin/ranlib: object: .libs/libgnu.a(strftime.o) malformed object (unknown load command 2)
make[3]: *** [libgnu.la] Error 1
make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_octave/octave/work/octave-4.2.1/libgnu'
make[2]: *** [all-recursive] Error 1

with clang-3.8, the build goes past this point without trouble, and ultimately succeeds.

/opt/local/bin/ranlib: file: .libs/libgnu.a(unistd.o) has no symbols
/opt/local/bin/ranlib: file: .libs/libgnu.a(wctype-h.o) has no symbols
/opt/local/bin/ranlib: file: .libs/libgnu.a(xsize.o) has no symbols
  GEN      liboctave/operators/mx-ui16nda-ui64nda.h
/usr/bin/ranlib: file: .libs/libgnu.a(bitrotate.o) has no symbols
/usr/bin/ranlib: file: .libs/libgnu.a(c-ctype.o) has no symbols
/usr/bin/ranlib: file: .libs/libgnu.a(fd-hook.o) has no symbols
/usr/bin/ranlib: file: .libs/libgnu.a(getprogname.o) has no symbols

I note /usr/bin/ranlib slips in there, instead of /opt/local/bin/ranlib, and I *think* this error occurs because the default /usr/bin/ranlib on 10.6 can handle the objects from clang-3.8, but can't handle the objects from clang-3.9, but I note that the troublesome object that causes the failure .libs/libgnu.a(strftime.o) malformed object never appears in the build log during the clang-3.8 build, for some reason.

During the clang-3.9 build, this appears:

ld: warning: target OS does not support re-exporting symbol _av_bprint_strftime from libavutil/libavutil.dylib

Whereas during the clang-3.8 build, it looks like this:

  CC       liboctave/wrappers/liboctave_wrappers_libwrappers_la-strftime-wrapper.lo

so there is some difference in the way octave builds on these two systems as well.

[kencu (Ken)]

FWIW, this 10.6.8 system is set up using LibcxxOnOlderSystems, if that has anything to do with it.

[gnw3]

On A Snow Leopard system that uses libstdc++ as the default C++ runtime, building with configure.compiler=macports-clang-3.9 gives the same "malformed object" error. I also have:

$ port log octave | grep RANLIB 
DEBUG: RANLIB='/usr/bin/ranlib'
configure: defining MKOCTFILE_RANLIB to be /usr/bin/ranlib

In the Portfile there is:

# avoid depends_build-append port:cctools
configure.env-append RANLIB=/usr/bin/ranlib

After editing the portfile to use RANLIB=${port}/bin/ranlib, the build proceeds further, but fails on:

clang: error: invalid library name in argument '-stdlib=macports-libstdc++'

The log shows that this comes from CXXFLAGS:

DEBUG: CXXFLAGS='-pipe -Os -D_GLIBCXX_USE_CXX11_ABI=0 -stdlib=macports-libstdc++ -arch x86_64'

[kencu (Ken)]

Ah, looks like that RANLIB fix should work, I think. Apparently there was some dependency on cctools that was to be avoided -- not sure why that would be.

That -stdlib=macports-libstdc++ error comes because Marcus' patch is not a default on clang-3.9 (it probably should be). You'll need to reinstall clang-3.9 with the proper variant manually for now, and enable the libstdcxx variant.

$ port variants clang-3.9
clang-3.9 has the variants:
[+]analyzer: Install clang static analyzer
   assertions: Enable assertions for error detection (has performance impacts,
               especially on JIT)
   debug: Enable debug binaries
   libstdcxx: -stdlib=macports-libstdc++ searches for MacPorts libstdc++
   universal: Build for multiple architectures

Or switch to clang-4.0, where libstdcxx is the default (If you do that, note that there is a math problem on 10.6.8 with clang-4.0 that needs a tiny manual patch for now -- there is another open ticket for that 54135).

[kencu (Ken)]

This ranlib issue still occurs with the last update to octave as well, of course. This fix is easy enough in the portfile. Change this:

# avoid depends_build-append port:cctools
configure.env-append RANLIB=/usr/bin/ranlib

to this:

# avoid depends_build-append port:cctools
configure.env-append RANLIB=${prefix}/bin/ranlib

It appears it's now inevitable that we need to use cctools, at least on systems of a certain vintage.

[kencu (Ken)]

looking at <​http://packages.macports.org/octave/> it appears that the buildbots are failing to build recent octave versions on darwin 12 and lower. So if we don't want to just change RANLIB across the board for all darwin versions, at least we could do it for darwin 12 and less. I'll make a PR for that.

[kencu (Ken)]

The last couple of updates of octave are building on darwin 11 and up. darwin 10 still fails due to the RANLIB issue, so I'll change the test to only that level, and submit the PR for Marcus to look at.

[kencu (Ken)]

In c1b73de65c83605b5ef22fbd787195d64e9b0b19/macports-ports:

octave: needs newer RANLIB on snowleopard

closes: #54228