llvm-5.0 does not build on 10.6 because of missing thread_local support (fix available)

[devernay (Frédéric Devernay)]

The full description, as well as the fix that patches lib/Fuzzer/CMakeLists.txt, are available upstream: ​https://reviews.llvm.org/D32312

A backport would be nice, if maintainers agree

[devernay (Frédéric Devernay)]

that fix is actually already in llvm-5.0, but does not work, because of issing OS support:

/opt/local-libc++/var/macports/build/_opt_local-libc++_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_llvm-5.0/llvm-5.0/work/llvm-5.0.0.src/lib/Fuzzer/FuzzerInternal.h:138:10: error: thread-local storage is not
      supported for the current target
  static thread_local bool IsMyThread;
         ^
<command line>:8:22: note: expanded from here
#define thread_local __thread

preparing a fix...

[devernay (Frédéric Devernay)]

note that llvm-5.0 also uses memmem(), so I will add PortGroup snowleopard_fixes 1.0 to the Portfile

[mf2k (Frank Schima)]

In the future, please Cc the port maintainers (port info --maintainers llvm-5.0), if any.

[kencu (Ken)]

this might turn out to be a hard one. I have not managed to get thread local storage working on 10.6 so far with clang ; it works with gcc6/gcc7 though. I tried the libcxx version but could not yet make that work either.

would be pleased to find out there is a way...there are other ports that need it too.

gcc does some kind of trickery to make it work on old systems...I think TLS is a kernel thing. It _is_ pretty easy to build llvm with gcc, though...hmmm.

[devernay (Frédéric Devernay)]

Actually, thread_local in libFuzzer is only used to check if this is the "master thread", so storing the master thread id instead of a thread_local bool should work. I mentionned that to the author: ​https://reviews.llvm.org/D32312

[kencu (Ken)]

That might work - your skills in that area are beyond mine.

But I suspect in the end this will most likely be resolved by turning off the libfuzzer build on SnowLeopard. Usually stuff like that is done with a cmake variable without too much trouble, and there are other examples in the llvm/clang Portfile of similar.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Attached is a patch that seems to allow llvm-5.0 to build on Mac OS 10.6.
As mentioned in comment:7, it attempts to turn off ​libFuzzer for ${os.major} <= 10.
The fixes from #54985 are also included to allow a successful build.

[jeremyhu (Jeremy Huddleston Sequoia)]

Thanks. Go ahead and land this without the llvm-bin-compat bits. Ken is close to landing that.

[kencu (Ken)]

Thanks Jeremy and Marcus. I'm fine with incorporating both these fixes in one big commit, as Marcus has outlined it here. I think I can close off 54985 as superseded by this, and bundle it all in here.

Marcus -- Jeremy also recommends revbumping llvm and lldb at the same time.

Thanks to both of you for keeping 10.6 going. I think there are quite a few who appreciate it!

[jeremyhu (Jeremy Huddleston Sequoia)]

You're the one doing the work here. I'm just trying to find scraps of time to look in and give you an ack ;)

[kencu (Ken)]

I have this building away on my primary 10.6.8 machine at present. I'll report back in a day or so with outcomes.

[kencu (Ken)]

Looks good.

$ port -v installed clang-5.0 llvm-5.0
The following ports are currently installed:
  clang-5.0 @5.0.0_3+analyzer+libstdcxx (active) platform='darwin 10' archs='x86_64' date='2017-10-18T21:08:53-0700'
  llvm-5.0 @5.0.0_1 (active) platform='darwin 10' archs='x86_64' date='2017-10-18T19:15:58-0700'

and it was successful at building my favourite c++11 test port, aria2, although admittedly with lots more warnings than I'm used to seeing (building against libc++):

In file included from /opt/local/libexec/llvm-5.0/include/c++/v1/set:389:
/opt/local/libexec/llvm-5.0/include/c++/v1/__tree:1819:22: warning: the specified comparator type does not provide a const call operator [-Wuser-defined-warnings]
                     __trigger_diagnostics()), "");
                     ^
/opt/local/libexec/llvm-5.0/include/c++/v1/__tree:876:70: note: in instantiation of member function 'std::__1::__tree<std::__1::shared_ptr<aria2::DHTPeerAnnounceEntry>, aria2::DHTPeerAnnounceStorage::InfoHashLess, std::__1::allocator<std::__1::shared_ptr<aria2::DHTPeerAnnounceEntry> > >::~__tree' requested here
    template <class, class, class> friend class _LIBCPP_TEMPLATE_VIS set;
                                                                     ^
/opt/local/libexec/llvm-5.0/include/c++/v1/memory:2546:7: note: in instantiation of member function 'std::__1::default_delete<aria2::DHTPeerAnnounceStorage>::operator()' requested here
      __ptr_.second()(__tmp);
      ^
/opt/local/libexec/llvm-5.0/include/c++/v1/memory:2500:19: note: in instantiation of member function 'std::__1::unique_ptr<aria2::DHTPeerAnnounceStorage, std::__1::default_delete<aria2::DHTPeerAnnounceStorage> >::reset' requested here
  ~unique_ptr() { reset(); }
                  ^
./DHTRegistry.h:77:5: note: in instantiation of member function 'std::__1::unique_ptr<aria2::DHTPeerAnnounceStorage, std::__1::default_delete<aria2::DHTPeerAnnounceStorage> >::~unique_ptr' requested here
    Data() : initialized(false) {}
    ^
/opt/local/libexec/llvm-5.0/include/c++/v1/__tree:970:7: note: from 'diagnose_if' attribute on '__trigger_diagnostics':
      _LIBCPP_DIAGNOSE_WARNING(!__invokable<_Compare const&, _Tp const&, _Tp const&>::value,
      ^                        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/opt/local/libexec/llvm-5.0/include/c++/v1/__config:1095:20: note: expanded from macro '_LIBCPP_DIAGNOSE_WARNING'
    __attribute__((diagnose_if(__VA_ARGS__, "warning")))
                   ^           ~~~~~~~~~~~

[kencu (Ken)]

Marcus - Jeremy recommended setting the xcodeversion test to the version that is confirmed to work on 10.7, ie 4.6.3.

The other clangs 3.9+ need the same llvm-bin-compat patch applied.

A revbump of llvm and lldb was also recommended - now I'll admit I'm not 100% sure why, as the only thing that changes on clang 3.9 and 4.0 is the clang wrapper on 10.6.8, but OK with me.

I take it you'll be doing those things? If you want me to do it, let me know. -- K

[jeremyhu (Jeremy Huddleston Sequoia)]

The reason for the llvm and clang revbumps is because that wrapper is used for the executables of all of the ports, not just clang. Eg:

$ cat /opt/local/bin/lldb-mp-5.0 
#!/bin/bash

if [ -x /usr/bin/xcrun ] ; then
    exec /usr/bin/xcrun /opt/local/libexec/llvm-5.0/bin/lldb "${@}"
else
    exec /opt/local/libexec/llvm-5.0/bin/lldb "${@}"
fi

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In 5994792d350762e10a3762c11bb782acb4e60fcb/macports-ports:

llvm-5.0: disable libFuzzer on older systems

No revbump because the port either builds successfully or not at all.
Fixes #54996