llvm-8.0 fails to build on older sytems (darwin 13 and less) when go is installed, as it tries to build the go bindings but go needs special attention to work on these systems

[iefdev (Eric F)]

A few weeks ago, when gcc9 dropped in a new version when I was updating my ports. So it started to download and build llvm-7.0, and it failed. Left it there hoping it was fixing it self over the next days or so. But then all my installed clang/llvm's showed up and needed an update - and now it wants to start building with llvm-8.0. And it fails to. So, I can't get anywhere from now. I guess you've made a bigger change somewhere.

Logfile says:

:info:build # command-line-arguments
:info:build /opt/local/lib/go/pkg/tool/darwin_amd64/link: running /opt/local/bin/clang-mp-5.0 failed: exit status 1
:info:build Undefined symbols for architecture x86_64:
:info:build   "_fstatat64", referenced from:
:info:build       syscall.libc_fstatat64_trampoline in go.o
:info:build   "_openat", referenced from:
:info:build       syscall.libc_openat_trampoline in go.o
:info:build   "_unlinkat", referenced from:
:info:build       syscall.libc_unlinkat_trampoline in go.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make[2]: *** [bin/llvm-go] Error 2
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-8.0/llvm-8.0/work/build'
:info:build make[1]: *** [tools/llvm-go/CMakeFiles/llvm-go.dir/all] Error 2
:info:build make[1]: *** Waiting for unfinished jobs....

// ... //

:error:build Failed to build llvm-8.0: command execution failed
:debug:build Error code: CHILDSTATUS 8539 2
:debug:build Backtrace: command execution failed
:debug:build     while executing
:debug:build "system {*}$notty {*}$nice $fullcmdstring"
:debug:build     invoked from within
:debug:build "command_exec build"
:debug:build     (procedure "portbuild::build_main" line 8)
:debug:build     invoked from within
:debug:build "$procedure $targetname"
:error:build See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_llvm-8.0/llvm-8.0/main.log for details.

I see that go is involved. I just noticed the other week it was possible to install in Lion again, so I did. Perhaps that's was causing it?

---

I use the ​LibcxxOnOlderSystems#LionandMountainLion, with clang-5.0 as the default.

cxx_stdlib         libc++

default_compilers   macports-clang-5.0 macports-clang-4.0 macports-clang-3.9 macports-clang-3.7 gcc-4.2 llvm-gcc-4.2 apple-gcc-4.2

[kencu (Ken)]

I think you've run into this: 58592

[iEFdev]

Replying to kencu:

I think you've run into this: 58592

Yes, looks like it… So, uninstall go (for now)?

I was maybe thinking my install isn't good. Looking further down in ​LibcxxOnOlderSystems for (Snow) Loeopard, I noticed a linker fix there. And when checking on my computer - I've kind of having the same thing. cctools and ld64-latest have +llvm34, and not +llvm50 (port installed name:^cc name:^ld).

[OT] I've started doing that curl-bootstrapped version you mentioned (thanks for the guide for that). I'm halfway through, but before I finish it I need to ask you a few things. Can I do it here, or send you an email?

[jmroot (Joshua Root)]

I notice LLVM 8.0.1 is available upstream, so updating the port is probably the first thing to do.

[kencu (Ken)]

Yes, until someone figures out how to get legacysupport to link in with it, we're no-go for go on the failing systems.

[kencu (Ken)]

Replying to jmroot:

I notice LLVM 8.0.1 is available upstream, so updating the port is probably the first thing to do.

Oh, thanks for noticing that. I should have checked before I just revbumped the beans out of everyone :> Perhaps, given that, I'll give them a few weeks grace before we push that update through ;>

[kencu (Ken)]

Replying to iEFdev:

[OT] I've started doing that curl-bootstrapped version you mentioned (thanks for the guide for that). I'm halfway through, but before I finish it I need to ask you a few things. Can I do it here, or send you an email?

An email at my @macports.org address would work, or if it's of general interest, the mailing list would be appropriate too.

[iEFdev]

Replying to kencu:

An email at my @macports.org address would work, or if it's of general interest, the mailing list would be appropriate too.

Thanks, I'll do. 👍

[iEFdev]

I deactivated go, and it seems like its building again, and I can activate it again when I'm done.

I don't know how many who installs go use it to build stuff, or just be able to run go programs. Perhaps make a variant of it? When deactivating go llvm says: :info:configure -- Go bindings disabled. With a variant one could use +go_bindings or something like that, if one need them. Just a thought…

---

While writing this… Seems like llvm/clang-8.0 installed fine. So did llvm-7.0, but not clang-7.0:

llvm-7.0.1.src/projects/libcxx/include/type_traits:740:56: error: _Float16 is not supported on this target
:info:build template <>          struct __libcpp_is_floating_point<_Float16>    : public true_type {};
:info:build                                             

[kencu (Ken)]

We have noticed that clang-7.0 doesn't seem happy to build with clang-8.0, probably due to the ever-increasing pickiness of newer compilers.

If you try to build clang-7.0 with something a bit older, like clang-5.0, you should have no troubles. If that works, please report back success

sudo port -v install clang-7.0 configure.compiler=macports-clang-5.0

[iEFdev]

Replying to kencu:

If you try to build clang-7.0 with something a bit older, like clang-5.0, you should have no troubles. If that works, please report back success

clang-5.0 upgraded… with clang-8.0 as build dep.

Looks like both built fine…

sudo port -v install llvm-7.0 configure.compiler=macports-clang-5.0   # √
sudo port -v install clang-7.0 configure.compiler=macports-clang-5.0  # √

If clang6 fails, I'll try the same thing with that one to.

[iEFdev]

clang-6.0 built fine.

[kencu (Ken)]

looks like llvm added an option to disable the bindings <​https://reviews.llvm.org/rL332816> and <​https://reviews.llvm.org/D42026> that we can use to turn them off.

LLVM_ENABLE_BINDINGS=OFF

It would seem most consistent to turn them off across the board (they are not built in the buildbot versions of these ports, as the system tests for go and ocaml to see if the bindings should be built, and the buildbots don't have these installed during their clean builds.

I have to figure out which versions of llvm support this configure flag to turn the go bindings off. Unfortunately not all of them, no doubt, so there will be some inconsistency in the llvm ports wherever this break comes.

I don't know if there is anyone out there who would expect the bindings to be built. That would require new dependencies for llvm on go and ocaml, but only on 10.10 and up where go works correctly -- I hate to bring in yet another variant to these ports, as they have too many variants already.

[kencu (Ken)]

in addition, we'll need to blacklist clang-8.0 (and newer?) from building clang-7.0 (and older?) due to the other error noted in this ticket, which is a different issue:

error: _Float16 is not supported on this target

That also needs some prospecting to see just how far back the build failure goes in the clang versions, and whether the newer version of clang-8.0 might have fixed it.

[iEFdev]

Replying to kencu:

looks like llvm added an option to disable the bindings <​https://reviews.llvm.org/rL332816> and <​https://reviews.llvm.org/D42026> that we can use to turn them off.

LLVM_ENABLE_BINDINGS=OFF

If you want/need some feedback… I'm just upgrading llvm/clang -> 8.0.1. I added that one, like:

    // ...
    -DLLVM_ENABLE_FFI=ON \
    -DLLVM_ENABLE_BINDINGS=OFF \
    -DLLVM_BINDINGS_LIST=none \
    // ...

…and -- Go bindings disabled. showed up. (go is installed, and active.)_

[kencu (Ken)]

This one is not doing anything I guess :

-DLLVM_BINDINGS_LIST=none

[iEFdev]

I guess it's just all the defaults. It's from the first set of all the args…

configure.args-append \
    -DLLVM_LINK_LLVM_DYLIB=ON \
    -DLLVM_ENABLE_ASSERTIONS=OFF \
    -DLLVM_ENABLE_RTTI=ON \
    -DLLVM_INCLUDE_TESTS=OFF \
    -DLLVM_INCLUDE_EXAMPLES=OFF \
    -DLLVM_ENABLE_FFI=ON \
    -DLLVM_ENABLE_BINDINGS=OFF \
    -DLLVM_BINDINGS_LIST=none \
    -DFFI_INCLUDE_DIR=`pkg-config --cflags-only-I libffi | sed 's/-I//'` \
    -DFFI_LIBRARY_DIR=${prefix}/lib

…and later down at ocaml:

    variant ocaml description {Enable generation of OCaml binding} {
        depends_lib-append   port:ocaml

        configure.args-delete -DLLVM_BINDINGS_LIST=none
        configure.args-append -DLLVM_BINDINGS_LIST=ocaml

Wonder if there's one specific for go? like: -DLLVM_BINDINGS_LIST=go

[kencu (Ken)]

Yes, you would have thought that setting -DLLVM_BINDINGS_LIST=none would have turned off the go bindings too. I'll get to this, eventually, unless someone else does first :>

[kencu (Ken)]

This switch is in the current tree <​https://reviews.llvm.org/D42026>.

Looks like you can turn them all off with -DLLVM_ENABLE_BINDINGS=OFF.

If you leave them on (the default) then llvm/trunk/cmake/config-ix.cmake will set up the bindings list depending on whether go and ocaml are found by cmake, adding them automatically to LLVM_BINDINGS.

1. I'm not sure at this moment if you can pass in -DLLVM_BINDINGS=XYZ and specify just one of them.
2. I see there are also python bindings. I guess they are not included in the bindings being built.

There is also this mysterious block in the top level CMakeLists.txt

foreach( binding ${LLVM_BINDINGS_LIST} )
  if( EXISTS "${LLVM_MAIN_SRC_DIR}/bindings/${binding}/CMakeLists.txt" )
    add_subdirectory(bindings/${binding})
  endif()
endforeach()

and I am not sure if that is doing anything much useful.

[iEFdev]

Replying to kencu:

This switch is in the current tree <​https://reviews.llvm.org/D42026>.

Looks like you can turn them all off with -DLLVM_ENABLE_BINDINGS=OFF.

Yes, that's the switch I used (from: comment:13).

Wonder if it will get applied to all (incl older) versions? As of now, it's just in llvm-{7..8}.0 when I multifile searched th sources the other week.

[iEFdev]

Replying to kencu:

I have to figure out which versions of llvm support this configure flag to turn the go bindings off. Unfortunately not all of them, no doubt, so there will be some inconsistency in the llvm ports wherever this break comes.

You can add llvm9 to the list.

:info:build # command-line-arguments
:info:build /opt/local/lib/go/pkg/tool/darwin_amd64/link: running /opt/local/bin/clang-mp-5.0 failed: exit status 1
:info:build Undefined symbols for architecture x86_64:
:info:build   "_fstatat64", referenced from:
:info:build       syscall.libc_fstatat64_trampoline in go.o
:info:build   "_openat", referenced from:
:info:build       syscall.libc_openat_trampoline in go.o
:info:build   "_unlinkat", referenced from:
:info:build       syscall.libc_unlinkat_trampoline in go.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make[2]: *** [bin/llvm-go] Error 2
:info:build make[2]: Leaving directory 

---

And it (re)installed everything with +universal tonight when I upgraded. Was that supposed to happen? It's never done that before.

I got clang_select+ a few others, and the it wanted to reinstall som 10+15 programs - and all had the universal variant selected. Now, since the install break, I reverted them back… (uninstalling + activating the one I hade before). I thought I had -universal in variants.conf, but appearently I didn't. I'll try to reinstall everything now with the -DLLVM_ENABLE_BINDINGS=OFF added.

Adding the log incase you want/need that one

[kencu (Ken)]

The problem I have here is trying to sort out when the ocaml bindings should or should not be available, and does anyone ever want to be able to turn them on?

It's easy to turn all the bindings off.

It's not simple to turn on just the ocaml bindings, and not the go bindings, especially with the go bindings being pretty much broken on < 10.9.

So trying to sort out just how we might smoothly do that.

I guess we could make the bindings variant only available on 10.9 and up (or wherever that broken go cutoff exactly is).

And -- most everyone gets their clang from the buildbot anyway, so the number of people trying to build clang from scratch on a system with a broken go installed is -- so far -- only you! (I'm sure there are others..)

[iEFdev]

Replying to kencu:

And -- most everyone gets their clang from the buildbot anyway, so the number of people trying to build clang from scratch on a system with a broken go installed is -- so far -- only you! (I'm sure there are others..)

Well, that was not my intention now. I've reverted all the changes (2.6.0+) so most stuff comes from the buildbot. If I'm not wrong… I got clang/llvm-9 yesterday, and it didn't build, just installed when I upgraded something. It was now it started to (re)build from source.

Hopefully the go port gets done soon. I saw you've done a lot of things over there (#58935). :+1:

Wonder why my update wanted to add universal to all programs. If 1 or 2 programs uses that as default… That's ok, but adding it in bulk like that. Hm…

 

edit: It might have been libomp that caused it, since it have +universal as default for older systems. When upgrading the “outdated” with -universal it chose the buildbot version of clang - and no additional rebuilds.