Can't compile hello app on OSX Lion


#1

Hello

Platform: OSX 10.7.4 (Lion)

I 've just installed rust using

curl -sf -L https://static.rust-lang.org/rustup.sh | sh

I saw a message saying “first uninstall rust then reinstall it using rustup-init.sh” so I did it and installed it properly.

I tried to compile geckodriver using

$ cargo build --release

and it stopped with this error:

Updating registry `https://github.com/rust-lang/crates.io-index`
dyld: lazy symbol binding failed: Symbol not found: _regcomp_l
Referenced from: /Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/bin/cargo
Expected in: /usr/lib/libSystem.B.dylib

To check if rust was working properly, I tried a hello application :

$ cargo new --bin hello
$ cd hello
$ cd src
$ cargo run

returned:

Compiling hello v0.1.0 (file:///Users/wanzohanzo/rust/hello)
error: linking with cc failed: exit code: 1
TRUNCATED
collect2: error: ld returned 1 exit status
error: aborting due to previous error
error: Could not compile hello.

On my OSX GCC-5.0.0 20150202 is installed and works fine (I have compiled numerous applications using it)

Can someone please explain why rust can’t even compile the hello application. Thanks.


#2

Nobody’s got no idea?


#3

You’ve truncated the most important part: why this failed. It’s really tough to tell without it.


#4

Thank you for the reply. Actually I did include the whole error message but after I got no comments for 4 days, I decided to shorten my post .Here is the untruncated error message:

Compiling hello v0.1.0 (file:///Users/wanzohanzo/rust/hello)
error: linking with cc failed: exit code: 1
|
= note: “cc” “-m64” “-L” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib” “/Users/wanzohanzo/rust/hello/target/debug/hello.0.o” “-o” “/Users/wanzohanzo/rust/hello/target/debug/hello” “-Wl,-dead_strip” “-nodefaultlibs” “-L” “/Users/wanzohanzo/rust/hello/target/debug/deps” “-L” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libstd-f5a209a9.rlib” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libpanic_unwind-f5a209a9.rlib” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libunwind-f5a209a9.rlib” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librand-f5a209a9.rlib” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcollections-f5a209a9.rlib” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/librustc_unicode-f5a209a9.rlib” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc-f5a209a9.rlib” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liballoc_jemalloc-f5a209a9.rlib” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/liblibc-f5a209a9.rlib” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcore-f5a209a9.rlib” “/Users/wanzohanzo/.rustup/toolchains/stable-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/libcompiler_builtins-f5a209a9.rlib” “-l” “System” “-l” “pthread” “-l” “c” “-l” “m”
= note: Assertion failed: (_mode == modeFinalAddress), function finalAddress, file /SourceCache/ld64/ld64-123.4.1/src/ld/ld.hpp, line 573.
0 0x10b30c641 __assert_rtn + 81
1 0x10b383afc ld::tool::OutputFile::addressOf(ld::Internal const&, ld::Fixup const*, ld::Atom const**) + 172
2 0x10b386562 ld::tool::OutputFile::applyFixUps(ld::Internal&, unsigned long long, ld::Atom const*, unsigned char*) + 4018
3 0x10b382a6a ld::tool::OutputFile::writeOutputFile(ld::Internal&) + 762
4 0x10b37bb19 ld::tool::OutputFile::write(ld::Internal&) + 153
5 0x10b30cba3 main + 1155
6 0x10b2fba04 start + 52
collect2: error: ld returned 1 exit status


#5

This is the big part. I don’t use a Mac, so that’s where my helpfulness ends, unfortuantely; maybe someone else has an idea. Some googling suggests maybe version mis-matches of some kind, i dunno.


#6

Actually it’s not the Mac OSX that is the problem. I think it’s the design of rust causing this error. Rust seems to require a C compiler to compile rust code and on Mac it fails to make use of otherwise correctly working C compiler.


#7

It does not, only to link. You’ll notice that ld was what failed here.


#8

Maybe you can try uninstalling GCC to see if that interferes with the Rust build system. Is it installed through Homebrew?

On my MacBook running macOS Sierra I have Xcode as the default compiler and GCC was installed as a dependency of another package by Homebrew.

I don’t have any issues with the latest stable or nightly Rust toolchains, installed with rustup.

Cheers!


#9

After 6 months, hello!

In order to solve the ‘linker’ problem with rust, I decided to build the latest version of rust from source on the same OSX 10.7.4 computer. After the configure, make went smoothly for about an hour, i.e. majority of the rust compiler has been compiled fine until I got this error, which is very simillar to the one I get with the hello app (code is below)

I guess this problem is more common on BSD Unixes because it’s been reported mainly by the OSX and NetBSD users. Here is a post by a NetBSD user having the same error: https://mail-index.netbsd.org/pkgsrc-users/2016/10/23/msg023868.html They report that the problem’s solved by installing the NetBSD’si C Wrapper package (mk/cwrapper) so it’s very likely that rust 's having difficulty linking C (or C++) libraries of the BSD Unixes.

The error I got as I tried to build latest version of rust on my OSX 10.7.4 is below. Is there a practical way to solve this linking problem on OSX?

Blockquote Error: linking with cc failed: exit code: 1
note: “cc” ‘"-m64"’ ‘"-L"’ ‘"/Users/macmini/rust/rust/x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib"’ ‘"-o"’ ‘“x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib/libstd-4e7c5e5c.dylib”’ ‘“x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib/std-4e7c5e5c.o”’ ‘"-Wl,-force_load,/Users/macmini/rust/rust/x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib/libmorestack.a"’ ‘“x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib/std-4e7c5e5c.metadata.o”’ ‘"-Wl,-dead_strip"’ ‘"-nodefaultlibs"’ ‘"/Users/macmini/rust/rust/x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib/libcollections-4e7c5e5c.rlib"’ ‘"/Users/macmini/rust/rust/x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib/librand-4e7c5e5c.rlib"’ ‘"/Users/macmini/rust/rust/x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib/liballoc-4e7c5e5c.rlib"’ ‘"/Users/macmini/rust/rust/x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib/libunicode-4e7c5e5c.rlib"’ ‘"/Users/macmini/rust/rust/x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib/liblibc-4e7c5e5c.rlib"’ ‘"/Users/macmini/rust/rust/x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib/libcore-4e7c5e5c.rlib"’ ‘"-L"’ ‘“x86_64-apple-darwin/rt”’ ‘"-L"’ ‘"/Users/macmini/rust/rust/x86_64-apple-darwin/llvm/Release+Asserts/lib"’ ‘"-L"’ ‘"."’ ‘"-L"’ ‘"/Users/macmini/rust/rust/x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib"’ ‘"-L"’ ‘"/Users/macmini/rust/rust/.rust/lib/x86_64-apple-darwin"’ ‘"-L"’ ‘"/Users/macmini/rust/rust/lib/x86_64-apple-darwin"’ ‘"-Wl,-force_load,x86_64-apple-darwin/rt/librust_builtin.a"’ ‘"-Wl,-force_load,x86_64-apple-darwin/rt/librustrt_native.a"’ ‘"-lSystem"’ ‘"-lpthread"’ ‘"-lc"’ ‘"-lm"’ ‘"-dynamiclib"’ ‘"-Wl,-dylib"’ '"-lcompiler-rt"'
note: ld: warning: directory not found for option '-L/Users/macmini/rust/rust/.rust/lib/x86_64-apple-darwin’
ld: warning: directory not found for option '-L/Users/macmini/rust/rust/lib/x86_64-apple-darwin’
ld: warning: could not create compact unwind for _stats_arena_print: stack subq instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for _prof_dump: stack subq instruction is too different from dwarf stack size
Assertion failed: (_mode == modeFinalAddress), function finalAddress, file /SourceCache/ld64/ld64-123.4.1/src/ld/ld.hpp, line 573.
0 0x103fb1641 __assert_rtn + 81
1 0x104028afc ld::tool::OutputFile::addressOf(ld::Internal const&, ld::Fixup const*, ld::Atom const**) + 172
2 0x10402b562 ld::tool::OutputFile::applyFixUps(ld::Internal&, unsigned long long, ld::Atom const*, unsigned char*) + 4018
3 0x104027a6a ld::tool::OutputFile::writeOutputFile(ld::Internal&) + 762
4 0x104020b19 ld::tool::OutputFile::write(ld::Internal&) + 153
5 0x103fb1ba3 main + 1155
6 0x103fa0a04 start + 52
collect2: error: ld returned 1 exit status
error: aborting due to previous error
make: *** [x86_64-apple-darwin/stage0/lib/rustlib/x86_64-apple-darwin/lib/stamp.std] Error 101
fulctrums-Mac-mini:rust macmini$


#10

Seems to be the same issue as discussed here, should be fixed in Rust 1.12. Have you tried rustup update?

EDIT: Some other thoughts.

An older version is used to compile current version. However, you should not need to compile Rust yourself for basic use.
Given that not many people are having this issue, this must be unique to your setup.

Can you print outputs of:

Default linker version:

$ ld -v

@(#)PROGRAM:ld  PROJECT:ld64-278.4
configured to support archs: armv6 armv7 armv7s arm64 i386 x86_64 x86_64h armv6m armv7k armv7m armv7em (tvOS)
LTO support using: LLVM version 8.1.0, (clang-802.0.42)
TAPI support using: Apple TAPI version 1.33.11

Rust version:

$ rustc --version

rustc 1.18.0 (03fc9d622 2017-06-06)

C compiler version:

cc --version

Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin

#11

Thank you for the comment. Here are the versions (which I forgot include at the first post)

ld -v
@(#)PROGRAM:ld PROJECT:ld64-123.4.1

rustc --version
rustc 1.14.0 (e8a012324 2016-12-16)

cc --version
cc (GCC) 5.0.0 20150202 (experimental)
Copyright © 2015 Free Software Foundation, Inc.

After I looked at the version of ld, I’ve realized that it’s from Apple’s XCode-4.0 (older version) and promoted it to the version of XCode-4.2.1. Now it’s:

ld -v

@(#)PROGRAM:ld PROJECT:ld64-136
configured to support archs: armv6 armv7 armv7s i386 x86_64
LTO support using: llvm version 3.0svn, from Apple Clang 3.0 (build 209.6)

and after that change, I have rebuilt the hello app and it did start to work! That’s fine. But geckodriver still didn’t get built after I tried with this change; the same error popped up.

I 've taken a look at the bugfix in rust-1.2. Actually I had saw that post the other day as I searched for a solution to my geckodriver build problem. But I don’t know how to apply the workaround they talk about: ‘LDFLAGS="-Wl,-no_compact_unwind" ./mach build’ ; there, mach seems to be a command but it’s not present on my system.

I agree that I should not need to compile Rust to be able to build the geckodriver; especially when I consider that the only problem is a missing dynamic library or rust’s being unable to link them. But I still I have to do something to solve it as I basically use Mac’s only.

I slightly disagree that only few people are having this issue. Yep, the number of people having this issue is low but that’s because the number of people using both BSD Unix and Rust applications for development is low.


#12

Any chance you needed to install xcode first? I know some other languages required me to install xcode before they could compile.


#13

That would be

LDFLAGS="-Wl,-no_compact_unwind" cargo build

I would suggest to try CLANG compiler as default. Many crates invoke C compiler to build C libraries, and they might not be well tested with GCC on OSX. I am not sure how you got GCC there, so I don’t know the exact steps how to remove it, but googling for it might yield some results.


#14

Thank you for the comment and sorry my late reply. XCode is already installed. The Xcode 4.6.2 which is about the maximum version for Lion is installed and clang -v returns:

Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)

Thank you for the comment and sorry my late reply.

I tried that and exactly the same error repeated : ( I tried with the clang-3.2 compiler instead of GCC-5.0 and again the sam error:

dyld: lazy symbol binding failed: Symbol not found: _regcomp_l
Referenced from: /Users/macmini/.rustup/toolchains/stable-x86_64-apple-darwin/bin/cargo
Expected in: /usr/lib/libSystem.B.dylib

having managed to compile the basic hello app, I inspected the libraries it used:

otool -L ./target/debug/hello
./target/debug/hello:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 159.1.0)

it turned out to be the same “libSystem.B.dylib” which caused the problem while compiling the geckodriver. So it looks like this dynamic library of OSX is compatible with the basic hello app but isn’t compatible with the geckodriver.