Package Details: rust-git 3:1.0.0.beta.2833.gb850046-3

Git Clone URL: (read-only)
Package Base: rust-git
Description: Systems programming language focused on safety, speed and concurrency
Upstream URL:
Keywords: mozilla rust
Licenses: MIT, Apache
Conflicts: rust
Provides: rust
Submitter: mrshpot
Maintainer: spider-mario
Last Packager: spider-mario
Votes: 26
Popularity: 0.061146
First Submitted: 2012-01-21 11:30
Last Updated: 2017-03-12 13:30

Required by (74)

Sources (11)

Latest Comments

ishitatsuyuki commented on 2017-03-20 01:31

It's stored in a folder with the name of host triple, which can't be easily determined by the script. Moving them out is very tricky, and that's why I'm trying to avoid it.

spider-mario commented on 2017-03-19 16:46

How easy would you say it is to split it? If it’s significantly easier to build just one package, 4MB doesn’t seem a very big price to pay.

ishitatsuyuki commented on 2017-03-13 04:06

Please cast an opinion on adding analysis as a separate package or not.

I have already managed to build one with the analysis data (available with the latest package on my server). They're about 4M in package size. Should I split them? It's necessary for RLS, but their characteristics are like debug symbols.

spider-mario commented on 2017-03-12 13:32

@intelfx, I am not sure that I understand all your issues. Let me try to clarify a few things:

- pkgver() (the function) does increase monotonically. I do not change the variable because I want to let users choose when to rebuild (especially as it is an expensive process), and for the most part, changes to the PKGBUILD are merely so that it keeps building—if you weren’t going to rebuild the package to start with, you won’t necessarily want to update just because I fixed building against, say, revision 5e9149d7. (Unless you were actively waiting for the fix, probably.)

- submodules in the source array are just for caching between runs of makepkg. If a submodule is absent from the array, it will be fetched normally by the configure script. It is a bit suboptimal bandwidth-wise but it should not break the build. It seems that the build was indeed broken recently, but for another reason: Apparently, it can be fixed either by running `make dist` after `make` (as in Gentoo’s ebuild) or by passing `--disable-dist-src` to configure (as in ishitatsuyuki’s PKGBUILD—I have backported this fix, thanks).

Do you still get an error with the fix (or with ishitatsuyuki’s PKGBUILD)?

ishitatsuyuki commented on 2017-03-09 08:36

@intelfx - please try my personal PKGBUILD -

The downloads directory on my server is also regularly updated, once a week or two.

intelfx commented on 2017-03-08 03:58

BTW, the thing does not build -- submodules are not registered nor checked out, and at least the submodule at tools/cargo is missing from source=() altogether.

intelfx commented on 2017-03-08 03:55

Is it possible to make pkgver increase monotonically? Right now there is no way to tell from within an AUR helper whether to rebuild this package.

ishitatsuyuki commented on 2017-02-09 13:17

Can reproduce. Will investigate.

Random note: I will update the package a few times a week on my server. (This is NOT a pacman repository but simple file server)

intelfx commented on 2017-02-09 10:18

This package builds rust twice again for me.

ishitatsuyuki commented on 2017-02-09 03:49

These flags are an exact copy of the repo version.

spider-mario commented on 2017-02-09 00:24

rustbuild adopted, thanks for your contributions (both here and upstream).

--enable-ninja should not be necessary since its documentation states: “build LLVM using the Ninja generator”, but we skip that step entirely (thanks for that as well).

What was the rationale behind --disable-codegen-tests? Do those tests break anything?

ishitatsuyuki commented on 2017-02-08 10:22

Makefiles are removed. Please adopt the latest changes from my gist (including the flags, and pkgver()).

spider-mario commented on 2017-02-03 23:53

My bad, I had not realized that the build system does not necessarily update all the submodules that it sets up.

Indeed, rustbuild will probably be usable soon (once your report is resolved), but I would rather wait until it is before adopting it. I hope this is fine.

ishitatsuyuki commented on 2017-02-03 23:44

You'd better not include redundant submodules that are useless for build; cloning LLVM is a great pain.

Rustbuild will be usable soon (my PR is waiting for the auto test & merge), so please adopt it (it builds less stages).

spider-mario commented on 2017-02-03 23:42

And, I forgot to add: of course, thank you for the contribution. :)

spider-mario commented on 2017-02-03 23:40

Sorry about the delay, I was quite busy these past few days, and it also took me a little while to review the changes. The PKGBUILD has been updated.

ishitatsuyuki commented on 2017-02-03 03:29

@spider-mario Can you adopt the new PKGBUILD? This one is building LLVM from scratch.

By the way, if you don't respond in one week, I would submit an orphan request.

ishitatsuyuki commented on 2017-01-28 07:48

This is a brand new PKGBUILD based on the one in official repo, please adopt if it looks good. This is tested anyway.

ishitatsuyuki commented on 2017-01-20 07:41

It would be good to see rust-src-git together.

spider-mario commented on 2017-01-07 14:03

It appears to be an upstream bug in rustbuild:

I have temporarily disabled rustbuild, as there is also this bug: , which breaks the build. fixes it but it has not been merged in master yet. (The PKGBUILD could cherry-pick it, but disabling rustbuild altogether solves both problems.)

intelfx commented on 2016-12-25 23:49

Somewhy this package builds Rust twice for me: once in build(), then once again from scratch(!) in package(). Can anyone confirm this?

crazedpsyc commented on 2016-10-19 10:27

It looks like cmake should be a build dependency.

c4757p commented on 2016-10-05 22:12

Sweet, thanks - works for me.

spider-mario commented on 2016-10-02 20:50

It seems to be a known bug:

I have applied a temporary fix (reverting 5e9149d as suggested by cesarb), but it will likely break when the issue is fixed upstream. I will probably need to be reminded to remove the patch then.

c4757p commented on 2016-10-01 02:55

install: error: Option '--docdir=/home/cmp/src/rust-git/pkg/rust-git/usr/share/doc/rust' is not recognized


eduardosm commented on 2016-07-01 10:46

rust.nanorc has been moved to the upstream nano package and it's been removed from rust/nano-config, so you should remove the lines

install --directory "$pkgdir"/usr/share/nano/
cp -a "$srcdir"/nano-config/*.nanorc "$pkgdir"/usr/share/nano/

(and "git+" from source too)


spider-mario commented on 2016-03-26 23:22

This should be fixed, thanks.

intelfx commented on 2016-03-26 14:50

> file owned by 'gtksourceview3' and 'rust-git': 'usr/share/gtksourceview/3.0/language-specs/rust.lang'

So, please, don't clone & package gedit-config.

spider-mario commented on 2015-03-11 06:23

I think makepkg is slightly confused by the fact that this is a split package where both packages don’t have the same architecture… (rust-doc-git is an “any” package.)

I suppose a workaround would be to make rust-doc-git arch-specific, even though it’s not. Would that seem acceptable?

MusicidalOtaku commented on 2015-03-10 22:31

After the build process pacman complains it can't find the package file... It succeeded before...
Installing with pacaur.

spider-mario commented on 2015-02-02 09:52

Thanks, I will fix it as soon as I can.

A build-time dependency on perl is not needed, however, as perl is not only part of the base group, but needed by git as well.

gbs commented on 2015-02-02 03:12

As of, editor files are not on the main rust repo anymore. See issue for new locations.

This should list perl on makedepends, since it's used on prepare(). Or replace that with, removing the noextract=(…) line:
git submodule init
for repo in compiler-rt jemalloc llvm hoedown; do
git config submodule.src/${repo}.url "$srcdir/$repo"
git submodule update
rust-doc package is missing the license files (and btw, 'MIT' does not need 'custom:').

The files "$pkgdir"/usr/lib/rustlib/{components,manifest-{rustc,rust-docs},rust-installer-version} are only used by rust-installer, and can be removed. They would conflict if something using the installer was already installed.

And just a cosmetic change, the rust repo is not in mozilla/rust anymore, but in rust-lang/rust (even though it redirects to the right place).

spider-mario commented on 2015-01-05 08:10

It works for me, I suspect it has been fixed upstream.

If not, could you perhaps upload the entire build log to some pastebin, please?

heinrich5991 commented on 2015-01-04 18:47

@Foucault Same thing happens to me.

Foucault commented on 2015-01-02 11:34

Has anyone managed to build the latest "master". It always fails for me late into build with the following error

gen-install-script: processing /home/build/abs/rust-git/src/rust/src/rust-installer/ args
gen-install-script: CFG_PRODUCT_NAME := Rust
gen-install-script: CFG_VERIFY_BIN := rustc
gen-install-script: CFG_REL_MANIFEST_DIR := rustlib
gen-install-script: CFG_SUCCESS_MESSAGE := Rust-is-ready-to-roll.
gen-install-script: CFG_OUTPUT_SCRIPT := tmp/dist/rust-0.13.0-dev-x86_64-unk ...
gen-install-script: CFG_LEGACY_MANIFEST_DIRS := rustlib,cargo
gen-install-script: validating /home/build/abs/rust-git/src/rust/src/rust-installer/ args
make[1]: Leaving directory '/home/build/abs/rust-git/src/rust'
sh: ../../tmp/dist/rust-docs-0.13.0-dev-x86_64-unknown-linux-gnu/ No such file or directory
/home/build/abs/rust-git/src/rust/mk/ recipe for target 'install' failed
make: *** [install] Error 127

spider-mario commented on 2014-10-22 06:33

Thanks a lot for your feedback, $SRCDEST indeed appears to be the right variable to use.

abandonedaccount commented on 2014-10-22 05:16

@spider-mario very nice, using the info you provided, replacing $startdir with $SRCDEST works as intended; maybe worth noting what's my env:
and $startdir is /home/emacs/build/rust-git

spider-mario commented on 2014-10-20 18:20

@Svenstaro: I can’t reproduce the issue. What are your MAKEFLAGS? Perhaps we should go back to `options=(!makeflags)`.

@emanueLczirai: weird, it works for me. :/ The way the script works is that for each line in .gitmodules that looks like “$url = (...)/$submodule[.git]”, if $startdir/$submodule/ is an existing directory then the line is replaced with “$url = $startdir/$submodule/”.

abandonedaccount commented on 2014-10-20 11:25

The perl script in prepare() doesn't seem to modify .gitmodules anymore and they are downloaded/cloned by the ./configure instead of using the repos that pacman already downloaded/cloned. I've no idea how to fix it currently because I don't know perl. Someone please look into it? Thanks.

Svenstaro commented on 2014-10-17 23:05

For some reason, I end up with an empty package after making this. spider-mario, please look into it.

Binero commented on 2014-07-09 09:50

This package seems to 'make clean' automatically. Rather annoying due to the time it consumes compiling.

gsnedders commented on 2014-06-10 13:29

Bah, I must be blind! I had a quick look at options and managed to glaze over the "!" and got slightly confused but moved on. But yes — parallel builds appear to work now.

heinrich5991 commented on 2014-06-09 22:47

Maybe you could make a blacklist isntead of a whitelist. Also note that it currently misses all files directly in the doc directory (not the subfolders).

spider-mario commented on 2014-06-09 21:58

The goal was to avoid copying useless .aux, .log and .out files, but indeed, missing useful files is worse.

heinrich5991 commented on 2014-06-09 20:36

The docs are not properly copied, it misses the JS files at least. Why does it make a selection based on file extension?

spider-mario commented on 2014-06-03 16:41

It’s ignored because of '!makeflags' in the `options` array. I think that I added that option because parallel builds didn’t seem to work.

If they work now, I’ll happily remove it. :)

gsnedders commented on 2014-06-03 16:35

MAKEFLAGS seems to be ignored, though I can't immediately see why. Having to do non-parallel builds makes it a lot slower. :(

spider-mario commented on 2014-04-05 07:48

I think I’ll just make the package provide `rust` now. Its version format sufficiently resembles that of `rust` in [community] now that makepkg natively supports VCS packages and let them have a pkgver() function.

spider-mario commented on 2014-04-04 20:22

Actually, I think I’ll just make the package provide `rust` now. Its version format sufficiently resembles that of `rust` in [community] now that makepkg natively supports VCS packages and let them have a pkgver() function.

spider-mario commented on 2014-04-04 20:15

Actually, the out-of-date notification comes from someone else (H3g3m0n), and it’s justified since 0.10 is out, which means that the `provides` field of this package should be updated. (I’m working on it.)

Thanks for explaining the point of VCS packages to Apes, though.

thestinger commented on 2014-04-04 19:50

Also, please only use out-of-date flags when something needs to be updated to a new release. It shouldn't be used whenever there is a problem with the package.

thestinger commented on 2014-04-04 19:49

Grabbing the HEAD of the master branch is what a VCS package is for in the first place. If you want the tagged release, use the rust package in [community].

Apes commented on 2014-04-04 19:47

The PKGBUILD just grabs whatever is on the HEAD of the master branch of the rust git project. It would be better to grab the tarball for one of the releases, or at the very least use a specific commit or tag.

spider-mario commented on 2014-03-30 12:40

Done, thank you.

spider-mario commented on 2014-03-30 10:34

There’s already a call to chrpath (I think I added it before e715cdba31ae2bfee603cfe0c56260390ec36f1c) but --disable-rpath would, indeed, avoid an unnecessary step, as well as remove a build-time dependency on chrpath.

thestinger commented on 2014-03-30 04:56

This should pass --disable-rpath --disable-verify-install, to avoid adding incorrect runpaths and to disable the newly added installation verification.

thestinger commented on 2014-03-09 00:31

@HalosGhost: It's intended to be that way. Git has a `describe` command and versions are described as `${last_tag}-${commits_since_last_tag}-g${commit_id}`.

HalosGhost commented on 2014-03-09 00:24

Perhaps it is just me, but I find it odd that the pkgver reports this as being based on 0.9.

All the best,

thestinger commented on 2014-02-07 00:01

The nightly build will be fixed after lands. It passes `--disable-rpath` to configure and this option broke a few days ago.

colemickens commented on 2014-02-06 01:19

Sorry, I'd unflag this if I could. I accidentally flagged this when thinking of thestinger's binary repo being out-of-date. My mistake.

thestinger commented on 2013-11-16 22:43

It needs to be updated to include `options=(staticlibs)` since the default is now to remove them:

Note that there's a nightly repository you can use instead of building yourself:

thestinger commented on 2013-11-16 22:41

It needs to be updated to flip off removing static libraries:

idupree commented on 2013-11-16 20:02

The `rustc` from this PKGBUILD is giving me an error when used on a "hello world" program. rustc built manually by "git clone; ./configure --prefix=/home/me/inst; make; make install" works fine.

% rustc
error: linking with `cc` failed: exit code: 1
note: cc arguments: -L/usr/lib/rustc/x86_64-unknown-linux-gnu/lib -m64 -o hello hello.o -L/usr/lib/rustc/x86_64-unknown-linux-gnu/lib -lstd-6425b930ca146ae9-0.9-pre -L/usr/lib/rustc/x86_64-unknown-linux-gnu/lib -lrustuv-a13edc95d75df17-0.9-pre -L/Users/me/programming/rust/.rust -L/Users/me/programming/rust -lrt -ldl -lm -lmorestack -lrustrt -Wl,-rpath,$ORIGIN/../../../../usr/lib/rustc/x86_64-unknown-linux-gnu/lib -Wl,-rpath,/usr/lib/rustc/x86_64-unknown-linux-gnu/lib
note: /usr/bin/ld: cannot find -lmorestack
collect2: error: ld returned 1 exit status

mindcat commented on 2013-11-01 07:33

lines 39: make DESTDIR="$pkgdir" install
Please change to this.
lines 39: make DESTDIR="$pkgdir" CFG_MANDIR="$pkgdir/usr/share/man" install

or this error.

thestinger commented on 2013-09-22 17:37

It's a known issue and fixing it by making a new snapshot is in-progress.

LeonidasXIV commented on 2013-09-22 12:09

Todays build fails:

x86_64-unknown-linux-gnu/stage0/bin/rustc: error while loading shared libraries: cannot open shared object file: No such file or directory
make: *** [x86_64-unknown-linux-gnu/stage0/lib/rustc/x86_64-unknown-linux-gnu/lib/] Error 127

spider-mario commented on 2013-09-08 10:57

Appearently, the reason why the patch doesn’t apply anymore is that the problem has been fixed upstream:


thestinger commented on 2013-09-07 22:02

It has make dependencies on both python2 and python by default. I work around this with `sed` in the PKGBUILD I use for the nightly build repository:

LeonidasXIV commented on 2013-09-07 21:54

Thanks for looking into it, I appreciate it. Unfortunately, it fails even earlier now:

==> Starting prepare()...
error: patch failed: mk/
Falling back to three-way merge...
Applied patch to 'mk/' with conflicts.
U mk/
==> ERROR: A failure occurred in prepare().

spider-mario commented on 2013-09-07 14:36

Thanks, it should be fixed now. Please let me know whether it works.

LeonidasXIV commented on 2013-09-07 11:50

Looks like it uses Python 3 somewhere where Python 2 is expected:

(cd /tmp/yaourt-tmp-leonidas/aur-rust-git/src/rust/src/libuv/ && ./gyp_uv -f make -Dtarget_arch=x64 -D ninja -Goutput_dir=/tmp/yaourt-tmp-leonidas/aur-rust-git/src/rust/x86_64-unknown-linux-gnu/rt/stage0/libuv --generator-output /tmp/yaourt-tmp-leonidas/aur-rust-git/src/rust/x86_64-unknown-linux-gnu/rt/stage0/libuv)
File "./gyp_uv", line 44
print 'Error running GYP'
SyntaxError: invalid syntax

spider-mario commented on 2013-09-05 16:35

Fixed, thanks! :)

draven commented on 2013-09-05 14:20


At the very end the command
if which emacs 2> /dev/null; then make; fi
fails for me complaining there is no Makefile.

Perhaps using
emacs --eval '(byte-recompile-directory "/the/directory")' -Q --batch
would do the trick

thestinger commented on 2013-06-21 04:13

By the way, I have daily builds of rust-git in a repository:

SigLevel = Optional
Server =$arch

spider-mario commented on 2013-05-01 21:39

Applied, thanks. :)

thestinger commented on 2013-05-01 21:34

The llnextgen/naturaldocs optdepends can be removed now, and the pandoc one should be changed to haskell-pandoc.

thestinger commented on 2013-01-30 00:35

@ackalker: It's reported upstream already and is harmless (just annoying), which is why it hasn't gotten any attention yet.

ackalker commented on 2013-01-30 00:31

s/hear/here/ # ;(

ackalker commented on 2013-01-30 00:30

After building and installing this package, and every time something runs 'ldconfig', I get these warnings:

ldconfig: File /usr/lib/ is empty, not checked.
ldconfig: File /usr/lib/ is empty, not checked.
ldconfig: File /usr/lib/ is empty, not checked.
ldconfig: File /usr/lib/ is empty, not checked.

Probably an upstream bug, but posted hear just FYI.

thestinger commented on 2013-01-03 07:27

Would be nice if this included provides=(rust) and conflicts=(rust). Thanks!

Anonymous comment on 2012-12-23 20:40

ah, ok, that makes sense. But you certainly want to avoid copying the Makefile don't you?

It *did* work, btw. :) Thanks!

spider-mario commented on 2012-12-23 19:35

The thing is, if the .el files are copied too, then the user can install emacs after building the package and still be able to use the mode (though it will be slower than if it has been precompiled). That is the reason why only the call to make is in the if.

Anonymous comment on 2012-12-23 19:03

I'm trying it out now, but I made the following modifications:

cp -a *.elc "$pkgdir/usr/share/emacs/site-lisp/" # copy just the .elc files

It also might be useful to wrap this whole section in the if:

if which emacs > /dev/null;
cd src/etc/emacs;
install --directory "$pkgdir/usr/share/emacs/site-lisp/";
cp -a *.elc "$pkgdir/usr/share/emacs/site-lisp/"
echo "enable rust-mode in emacs by adding (require 'rust-mode) to your ~/.emacs file"

Something along these lines perhaps.

spider-mario commented on 2012-12-23 18:04

I’ve just given it a try, please let me know whether it works.

Anonymous comment on 2012-12-23 17:43

For emacs, you need to first build the files in the emacs directory. I'm not sure what the pre-reqs for this are (you at least need emacs installed though).

the emacs files are in src/etc/emacs. You need to run make from this directory. Then you copy all the .elc files from there to /usr/share/emacs/site-lisp/

After that you need to add (require 'rust-mode) to your ~/.emacs file (This can probably just be some post-install output for the user to act on). I'm not sure how to do all this in the PKGBUILD right now. I'll look into (and I'm testing some stuff now) and I'll hopefully get back to you with a patched PKGBUILD, but if anyone can do this quickly off the top of their head, that'd be great too :)

spider-mario commented on 2012-12-10 19:23

Done for Vim, thanks!

Unfortunately, I don’t use Emacs either, so even if I tried to do the same for the Emacs files, I wouldn’t be able to check that it works.

If someone can make it work, I’ll be glad to add it to the PKGBUILD.

thestinger commented on 2012-12-10 14:40

It would be great if you could install the Vim and Emacs files that ship with the rust source. For vim, you just need this:

mkdir -p "$pkgdir/usr/share/vim"
cp -a src/etc/vim "$pkgdir/usr/share/vim/vimfiles"

I'm unsure about what to do with the Emacs files + Makefile though, so an Emacs user will have to step forward with that info :).

mrshpot commented on 2012-10-19 07:00

Sorry, due to lack of time I'm disowning it so somebody can actually fix it.

Svenstaro commented on 2012-10-12 16:48

This PKGBUILD has a bunch of problems.

1) You are not using a packaging() function
2) You are still using || return 1
3) You are using the wrong DESTDIR
4) You are not using Maintainer or Contributor in the comment but your custom "Author"
5) You don't need the python hack anymore
6) You shouldn't manually have to copy docs (did you make an upstream bug report?)

Anonymous comment on 2012-10-12 16:06

Files are being installed in the wrong directory (/usr/usr instead of just /usr), fixed PKGBUILD: (only changes the DESTDIR= line).

Anonymous comment on 2012-10-12 11:39

Anybody with problems on x86_64, if so what did you do to solve this?

I am working with the official repos and python2, but at the end of the build I
have problems with packaging the documentation which kill the whole build. I've tried
modifiying the PKGBUILD with no success, any ideas?

thanks for the PKGBUILD though

mrshpot commented on 2012-01-21 15:06

llvm-build (src/llvm/llvm-build/llvm-build) breaks with python3 [1].
I saw those errors during the LLVM build and figured it would be best to roll back to python2.
The carpet-bomb replacement might really be overkill, though -- the LLVM build takes a long time on my machine and I wanted to have rust working ASAP.
If the thing builds properly with python3 for everything except llvm-build, let me know (or I'll try that later myself).

$ pwd

$ python llvm-build
Traceback (most recent call last):
File "llvm-build", line 3, in <module>
import llvmbuild
File "/home/mrshpot/build/rust-git/src/llvm/utils/llvm-build/llvmbuild/", line 1, in <module>
from main import main
ImportError: No module named main

$ python2 llvm-build
# runs with no errors

spider-mario commented on 2012-01-21 12:04

Are you sure you need to replace “python” with “python2”?

This page:
suggests that Python 3 should be used.