rust @1.26.0: error: unexpected token in directive

[l2dy (Zero King)]

I updated rust to 1.25.0 and its llvm dependency to llvm-6.0 in [77b2ac31e027672243e78942002737e7185ba125/macports-ports]. However build failed on OS X <= 10.9 on Buildbot with this error:

running: "/usr/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=x86_64-apple-darwin" "-stdlib=libc++" "--target=x86_64-apple-darwin" "-fno-builtin" "-fvisibility=hidden" "-ffreestanding" "-fomit-frame-pointer" "-DVISIBILITY_HIDDEN" "-o" "/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_rust/rust/work/rustc-1.25.0-src/build/x86_64-apple-darwin/stage0-std/x86_64-apple-darwin/release/build/compiler_builtins-1d69f6fbd68a066f/out/../../libcompiler_builtins/compiler-rt/lib/builtins/x86_64/floatundidf.o" "-c" "../../libcompiler_builtins/compiler-rt/lib/builtins/x86_64/floatundidf.S"
cargo:warning=../../libcompiler_builtins/compiler-rt/lib/builtins/x86_64/floatundidf.S:37:11: error: unexpected token in directive
cargo:warning=.balign 4 .subsections_via_symbols ; .globl ___floatundidf ; ; .private_extern ___floatundidf ; ___floatundidf:
cargo:warning=          ^
exit code: 1

I've only tested it on 10.13 and didn't discover this issue. Sorry for pushing the update in a hurry.

[tehcog (tehcog)]

main.log

[pmetzger (Perry E. Metzger)]

Zero King, are you working on this?

[l2dy (Zero King)]

Replying to pmetzger:

Zero King, are you working on this?

No, I don't have an old OS X environment. But I could revert the change for older systems by adding an if block.

[pmetzger (Perry E. Metzger)]

Maybe Ken would be able to help testing on the old environments? He seems to have a bunch of them.

[ryandesign (Ryan Carsten Schmidt)]

The first step is to file a bug report with the developers of rust. Has anybody done that?

[dbevans (David B. Evans)]

In a6c03510bb38fa46bcce7310e66893347b7a686d/macports-ports (master):

librsvg: only build with rust/cargo on 10.10 or better

Rust @1.25.0 fails to build on 10.9 and earlier.

See #56322

[g5pw (Aljaž Srebrnič)]

Does this bug still persist with rust 1.26?

[l2dy (Zero King)]

Replying to g5pw:

Does this bug still persist with rust 1.26?

Yes, see ​https://build.macports.org/builders/ports-10.9_x86_64-builder/builds/56846.

[pmetzger (Perry E. Metzger)]

Perhaps we should change the title to 1.26?

[kencu (Ken)]

This looks like an issue that is likely caused by the older systems using as as the assembler and the newer systems using clang as the assembler.

[kencu (Ken)]

See 37846 for details and how to force clang as the assembler on the older systems.

[g5pw (Aljaž Srebrnič)]

Thanks for the input Ken! Do you have access to a machine running 10.9? I don't really have any system to test that on... :/

[tehcog (tehcog)]

Replying to g5pw:

Thanks for the input Ken! Do you have access to a machine running 10.9? I don't really have any system to test that on... :/

I have mavericks and the same issue:

:info:build running: "/usr/bin/clang" "-O2" "-ffunction-sections" "-fdata-sections" "-fPIC" "-ffunction-sections" "-fdata-sections" "-fPIC" "--target=x86_64-apple-darwin" "-stdlib=libc++" "--target=x86_64-apple-darwin" "-fno-builtin" "-fvisibility=hidden" "-ffreestanding" "-fomit-frame-pointer" "-DVISIBILITY_HIDDEN" "-o" "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_lang_rust/rust/work/rustc-1.26.0-src/build/x86_64-apple-darwin/stage0-std/x86_64-apple-darwin/release/build/compiler_builtins-8bee530f001b77a3/out/../../libcompiler_builtins/compiler-rt/lib/builtins/x86_64/floatundidf.o" "-c" "../../libcompiler_builtins/compiler-rt/lib/builtins/x86_64/floatundidf.S"
:info:build cargo:warning=../../libcompiler_builtins/compiler-rt/lib/builtins/x86_64/floatundidf.S:37:11: error: unexpected token in directive
:info:build cargo:warning=.balign 4 .subsections_via_symbols ; .globl ___floatundidf ; ; .private_extern ___floatundidf ; ___floatundidf:
:info:build cargo:warning=          ^
:info:build exit code: 1

However, I am a little confused as the error is indicating the use of clang. If you tell me what to do, I can test what ever you have for a solution. You will have to assist me though...

Regards,

[kencu (Ken)]

it is compiling with clang, but on 10.9 and below, it is sending the assembly to as to convert into machine code.

the ancient as in cctools doesn't understand new-fangled assembly like .subsections_via_symbols and barfs.

You have to force the assembly to go to llvm's integrated assembler using the tricks in 37846.

At least at this moment I believe that will likely fix this. Can test tomorrow I think.

[kencu (Ken)]

Well, rust is very complicated, isn't it? Good luck to all of you who use it regularly!

I had a HELLUVA time trying to figure out how I would get something like -integrated-as or -Wa,-q or AS_INTEGRATED_ASSEMBER=1 to take purchase without messing up the rustc compiler.

Instead of that, I tried a different approach. At some point, clang switched to making the -integrated-as the default on Darwin. In clang-5.0, there doesn't even seem to be a system version test for it any longer -- all versions of Darwin are instructed to use the -integrated-as by default.

So the simple fix, in the end, appears to be to use a newer version of clang to build rust.

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

and it's building away now, well past the previous errors, on 10.9.

Rust takes hours to build -- I'll report back when it's all done, and hopefully that will be all it takes to make it work.

[kencu (Ken)]

OK - that did it:

$ port -v installed rust
The following ports are currently installed:
  rust @1.26.0_0 (active) platform='darwin 13' archs='x86_64' date='2018-05-17T17:41:46-0700'

just make a dep on cctools, and blacklist clang and all the macports-clang versions below some critical cutoff.

I don't know when it was that they started defaulting to -integrated-as -- clang-5.0 works, and I'd just go with that, unless somebody wants to spend the time to figure it out exactly.

[g5pw (Aljaž Srebrnič)]

Oh, wow, thank you Ken for testing that so thoroughly! 🙂 The "official" requirements state that clang 3.x or later is supported, but I think there's not much harm done if we require clang-5.0.

[nihilus (Markus Gothe)]

This bug kinda pissed me off, and the solution is trivial when one knows the problem. Just set configure.compiler = macports-clang and viola, problem solved. Now I did a selfupdate and I don't see this having been fixed. Instead it is falling back on the default toolchain. See this as a lesson learned for future portfiles.

[kencu (Ken)]

we are waiting for the portfile author to incorporate the fix. In the meantime, you're welcome!

[Ionic (Mihai Moldovan)]

I'd use clang-6.0, since the universal builds already utilize llvm-6.0.

[Ionic (Mihai Moldovan)]

I just noticed that there will be another problem, though: if rust is compiled with a non-default compiler, cargo will use that one, too. So whatever compiler is used to build rust MUST also be added as a build dependency of cargo. Not sure about other dependent ports.

[Ionic (Mihai Moldovan)]

This workaround doesn't allow full package installation as of rust 1.27.0 any longer.

Instead, cargo is now failing with a stack overflow error in main.

So far, I've tried upgrading the external cargo dependency to the newest version (0.28), as well as forcing the system to use the already installed cargo version (naturally we can't do this in general as that would create a dependency loop; I was merely desperate and interested if it would work with that), but all my attempts were futile.

[Ionic (Mihai Moldovan)]

Looks like ​a homebrew user also ran into this problem, so this seems to be something common with rust 1.27.0 (ignore everything but the original post for now).

Sadly, this report isn't helpful - only reiterating what I've been seeing.

[Chessax]

I'm having the same (similar?) issue but I'm on OS X 10.10.5, see main.2.log

[Chessax]

OS X 10.10.5

[raimue (Rainer Müller)]

You are on OS X 10.10, but are still using Xcode 6.2. Even for Xcode 6.x that is outdated and according to XcodeVersionInfo, you should be able to upgrade to Xcode 7.

[kencu (Ken)]

There is much information by following the link to the homebrew issue in <​https://trac.macports.org/ticket/56322#comment:26>. Looks like Ionic has a patch that he uses in his own repo that can fix it. AFAICT, upstream is pondering reverting the commits that caused this (a not-very-portable stack protector mechanism for Rust).

[Chessax]

Replying to raimue:

You are on OS X 10.10, but are still using Xcode 6.2. Even for Xcode 6.x that is outdated and according to XcodeVersionInfo, you should be able to upgrade to Xcode 7.

Just came from OS X 10.9 (yeah I know I'm way behind, but got a bunch of shit that's been horrendous to install and didn't want to break it if I didn't have to), that's why it's 6.2, but I thought App Store would bump me up, after all I got version 7.2 of Command Line Tools updated via the App Store the other day, isn't that the important part? I don't really use XCode.app very much, but maybe I need to head over to developer downloads and get an updated version.

Anyway, I managed to get everything (seemingly) working via installing an old version of librsvg (which was the port I was having trouble with) that doesn't have rust as a dependency.

[kencu (Ken)]

perhaps we need to bump this test in the librsvg Portfile up to 10.10 then:

if {${os.platform} eq "darwin" && ${os.major} < 14} {
    # revert to latest pre-cargo version
    version         2.40.20
    epoch           1

    checksums       rmd160  e697e1220779f77e81a890718ef5cda5b5e6b740 \
                    sha256  cff4dd3c3b78bfe99d8fcfad3b8ba1eee3289a0823c0e118d78106be6b84c92b \
                    size    1796376
} else {

[Chessax]

Replying to kencu:

perhaps we need to bump this test in the librsvg Portfile up to 10.10 then:

That's exactly what I did, maybe I'm an outlier but it did "solve" my problem(s) (also casually tried updating XCode.app via app store, but it just kept spinning, with no error)

[nihilus (Markus Gothe)]

Replying to nihilus:

This bug kinda pissed me off, and the solution is trivial when one knows the problem. Just set configure.compiler = macports-clang and viola, problem solved. Now I did a selfupdate and I don't see this having been fixed. Instead it is falling back on the default toolchain. See this as a lesson learned for future portfiles.

For every one, this is the solution that works so please fix this upstream.

[g5pw (Aljaž Srebrnič)]

Is this fixed in latest rust?

[kencu (Ken)]

our cctools port now installs as in such a way that it defaults to use clang as the assembler. So this particular exact issue should not be happening any more (although there are plenty of other issues with rust on anything but a fairly current MacOS version that might cause trouble).