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.


#15

I believe this is because OSX changed their regular expression libraries somewhere after 10.7, specifically as it relates to the function regcomp() which gained an alternate version, regcomp_l() sometime after 10.7.

Per this link: https://www.unix.com/man-page/osx/3/regcomp/

IMPLEMENTATION CHOICES
The regex implementation in Mac OS X 10.8 and later is based on a heavily modified subset of
TRE (http://laurikari.net/tre/). This provides improved performance, better conformance and
additional features. However, both API and binary compatibility have been maintained with
previous releases, so binaries built on previous releases should work on 10.8 and later, and
binaries built on 10.8 and later should be able to run on previous releases (as long as none
of the new variants or new features are used.

If you look at source code for OSX 10.8, https://opensource.apple.com/release/mac-os-x-1084.html , and download LibC you will find the TRE source code, and regcomp_l is inside of Libc-825.26/regex/TRE/lib/regcomp.c

If you compare this with OSX 10.7 source code, https://opensource.apple.com/release/mac-os-x-1075.html , you will see that 10.7 is just using old fashioned FreeBSD regex, Libc-763.13/regex/regcomp-fbsd.c which does not contain the ‘regcomp_l’ variation.

Now, if you look at the sauce code for rust Cargo, https://github.com/rust-lang/cargo, there is no direct call to regcomp_l or even regcomp so it may be using it inadvertently through a dependency library its using. So I notice it’s using the ‘regex’ crate (i think?) but the https://github.com/rust-lang/regex crate also doesnt call regcomp. Maybe https://github.com/rust-lang/libc ? nope. OK what about https://github.com/rust-lang/regex-syntax ? OK im striking out…

OK so if you actually do something like cd /tmp; git clone https://github.com/rust-lang/cargo ; cd cargo; cargo build ; you can get an idea of all the crates it pulls down. It stores them under $HOME/.cargo/registry/src/github.com-…/ so… if we run

grep -r regcomp_l ~/.cargo/registry/src 

we have a hit

don@oysters:/tmp/cargo$ grep -r regcomp_l  ~/.cargo/registry/src/github.com-1ecc6299db9ec823/
/home/don/.cargo/registry/src/github.com-1ecc6299db9ec823/libgit2-sys-0.7.6/libgit2/src/CMakeLists.txt:CHECK_SYMBOL_EXISTS(regcomp_l "regex.h;xlocale.h" HAVE_REGCOMP_L)
/home/don/.cargo/registry/src/github.com-1ecc6299db9ec823/libgit2-sys-0.7.6/libgit2/src/unix/posix.h:   return regcomp_l(preg, pattern, cflags, (locale_t) 0);

I can cut that down a bit to make it clearer

~$ grep -r regcomp_l  ~/.cargo/registry/src
...libgit2/src/CMakeLists.txt:CHECK_SYMBOL_EXISTS(regcomp_l "regex.h;xlocale.h" HAVE_REGCOMP_L)
...libgit2/src/unix/posix.h:   return regcomp_l(preg, pattern, cflags, (locale_t) 0);

So basically there is one line in one file in one package in this whole tree that is calling regcomp_l, but here is the thing.

its not even using the locale feature. its forcing it to 0

Remember our old friend at unix.com, the manpage for regcomp https://www.unix.com/man-page/osx/3/regcomp/ lets just compare the function signatures of ‘old’ regcomp and ‘new and improved’ regcomp_l

 int regcomp_l(regex_t *restrict preg, 
     const char *restrict pattern,  
     int cflags,
     locale_t restrict);

 int regcomp(regex_t *restrict preg, 
     const char *restrict pattern,
     int cflags);

We can see the only difference in the parameters is ‘locale_t restrict’ which in Cargo’s dependency libgit2-sys is simply being set to 0.

I don’t know enough to say if this call to regcomp_l() can simply be changed to ‘regcomp()’ without any effects, as it would take a good bit of testing, but… lets look at this package in question some more. It is called libgit2-sys. Now lets look at how it builds on linux, ubuntu 18. After running cargo build, i can run a grep:

don@oysters:/tmp/cargo$ grep -ri  regcomp .             

There are a ton of hits, but basically what they are saying is stuff like this, from a CMake error log:

  Determining if the regcomp_l exist failed with the following output:

So on linux ubuntu 18, we apparently are building without regcomp_l ? Like I said it would take a lot more testing to see how much an impact use of regcomp_l actually has on cargo.


#16

Did some more digging. This appears to go back to a bug in libgit2 related to the LC_COLLATE environment variable.

Here is their discussion of the bug on github: https://github.com/libgit2/libgit2/issues/4528

The discussion of ways to fix: https://github.com/libgit2/libgit2/pull/4560

The decision to go with it https://github.com/libgit2/libgit2/issues/4465

Curiously one of the commenters says " Most Linux/Unix based platforms provide regcomp_l" but as far as I can tell, my plain old ubuntu 18 machine does not, through a quick

 grep -r regcomp_l /usr/include

I get zero hits. I’d expect to get one maybe? If it was there and usable?