Package Details: rust-git 3:1.25.0.r74258.39abcc0413-1

Git Clone URL: https://aur.archlinux.org/rust-git.git (read-only, click to copy)
Package Base: rust-git
Description: Systems programming language focused on safety, speed and concurrency
Upstream URL: https://www.rust-lang.org/
Keywords: mozilla rust
Licenses: MIT, Apache
Conflicts: rust
Provides: rust
Submitter: mrshpot
Maintainer: spider-mario (ishitatsuyuki)
Last Packager: ishitatsuyuki
Votes: 28
Popularity: 0.29
First Submitted: 2012-01-21 11:30 (UTC)
Last Updated: 2018-02-11 11:49 (UTC)

Required by (1199)

Sources (2)

Pinned Comments

ishitatsuyuki commented on 2019-10-21 06:32 (UTC) (edited on 2021-09-08 09:28 (UTC) by ishitatsuyuki)

I'm not actively maintaining this package at this moment. If you want to contribute a PKGBUILD or other change, let me know.

Latest Comments

moormaster commented on 2022-04-29 05:23 (UTC) (edited on 2022-04-29 05:24 (UTC) by moormaster)

It builds for me only if I use the config.toml.example file from the rust git repository to create a config.toml. This can be achieved by changing the following line from PKGBUILD in the build() function

from cp -a "$srcdir/config.toml" .

to cp config.toml.example config.toml

beroal commented on 2021-09-08 11:38 (UTC)

There was an error that src/rust/src/llvm-project/libunwind doesn't exit. I just created this directory by hand.

beroal commented on 2021-09-08 10:08 (UTC)

@weltio I solved your error by changing the profiler parameter in the build section of config.toml from true to false. I have no idea what it does.

beroal commented on 2021-09-08 09:25 (UTC)

Okay, I solved the error by commenting use-jemalloc = false in the [rust] section in config.toml. Why is it not fixed for two years? config.toml belongs to this AUR package, not to Rust.

beroal commented on 2021-09-07 11:52 (UTC)

I'm getting the old error about use-jemalloc. Is it that I'm using an old rust compiler?

$ pacman -Q rust
rust 1:1.54.0-1

weltio commented on 2021-08-29 10:19 (UTC) (edited on 2021-08-29 11:20 (UTC) by weltio)

even with the config.toml change the build fails

The following warnings were emitted during compilation:

warning: ar: '/tmp/build/rust-git/src/rust/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/build/profiler_builtins-7817b886aecb3253/out/libprofiler-rt.a': No such file

error: failed to run custom build command for `profiler_builtins v0.0.0 (/tmp/build/rust-git/src/rust/library/profiler_builtins)`

Caused by:
  process didn't exit successfully: `/tmp/build/rust-git/src/rust/build/x86_64-unknown-linux-gnu/stage0-std/release/build/profiler_builtins-92fefc3e82530248/build-script-build` (exit status: 1)
  --- stdout
  TARGET = Some("x86_64-unknown-linux-gnu")
  HOST = Some("x86_64-unknown-linux-gnu")
  AR_x86_64-unknown-linux-gnu = Some("ar")
  running: "ar" "s" "/tmp/build/rust-git/src/rust/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/build/profiler_builtins-7817b886aecb3253/out/libprofiler-rt.a"
  cargo:warning=ar: '/tmp/build/rust-git/src/rust/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/build/profiler_builtins-7817b886aecb3253/out/libprofiler-rt.a': No such file
  exit status: 1

  --- stderr


  error occurred: Command "ar" "s" "/tmp/build/rust-git/src/rust/build/x86_64-unknown-linux-gnu/stage0-std/x86_64-unknown-linux-gnu/release/build/profiler_builtins-7817b886aecb3253/out/libprofiler-rt.a" with args "ar" did not execute successfully (status code exit status: 1).


warning: build failed, waiting for other jobs to finish...
error: build failed
Build completed unsuccessfully in 0:00:02

Could you elaborate your config.toml? With the rust-git example it builds it seems and the differences are manyfold (maybe also due to and old base for the supplied config.toml)

ishitatsuyuki commented on 2021-05-18 04:45 (UTC)

This packages provides (used to provide) the tools directly from the submodule checkouts in the rustc repo. It matches how the official binary artifacts are built.

You can totally build tools like RLS out-of-tree if you want.

groctel commented on 2021-05-12 12:43 (UTC)

Why does this package install unnecessary rust-*-git dependencies by building them instead of relying on actual AUR dependencies? This package should just provide the rust language server.

A.J commented on 2020-02-03 23:51 (UTC) (edited on 2020-02-04 00:14 (UTC) by A.J)

build fails with the following error : 

error: failed to run custom build command for profiler_builtins v0.0.0 (/home/aj/Downloads/rust-git/src/rust/src/libprofiler_builtins)


Caused by:
  process didn't exit successfully: /home/aj/Downloads/rust-git/src/rust/build/x86_64-unknown-linux-gnu/stage0-std/release/build/profiler_builtins-1d8d0e4ced679e9e/build-script-build (exit code: 101)
--- stderr
thread 'main' panicked at 'called Option::unwrap() on a None value', /rustc/eb3f7c2d3aec576f47eba854cfbd3c1187b8a2a0/src/libcore/macros/mod.rs:15:40
note: run with RUST_BACKTRACE=1 environment variable to display a backtrace.


warning: build failed, waiting for other jobs to finish...
error: build failed

spider-mario commented on 2019-10-21 08:11 (UTC) (edited on 2019-10-21 08:11 (UTC) by spider-mario)

I will look into it soon-ish, but presumably, commenting out (or removing) the use-jemalloc line should do it. Thanks for the notice.

ishitatsuyuki commented on 2019-10-21 06:32 (UTC) (edited on 2021-09-08 09:28 (UTC) by ishitatsuyuki)

I'm not actively maintaining this package at this moment. If you want to contribute a PKGBUILD or other change, let me know.

theYinYeti commented on 2019-10-20 18:35 (UTC)

Build fails in rust:

failed to parse TOML configuration 'config.toml': unknown field `use-jemalloc`, expected one of `optimize`, `codegen-units`, `codegen-units-std`, `debug-assertions`, `debuginfo-level`, `debuginfo-level-rustc`, `debuginfo-level-std`, `debuginfo-level-tools`, `debuginfo-level-tests`, `parallel-compiler`, `backtrace`, `default-linker`, `channel`, `musl-root`, `rpath`, `optimize-tests`, `codegen-tests`, `ignore-git`, `debug`, `dist-src`, `verbose-tests`, `incremental`, `save-toolstates`, `codegen-backends`, `codegen-backends-dir`, `lld`, `lldb`, `llvm-tools`, `deny-warnings`, `backtrace-on-ice`, `verify-llvm-ir`, `remap-debuginfo`, `jemalloc`, `test-compare-mode`, `llvm-libunwind` for key `rust` at line 356 column 1
failed to run: /home/ME/.cache/yay/rust-git/src/rust/build/bootstrap/debug/bootstrap dist

ishitatsuyuki commented on 2017-10-09 04:21 (UTC)

The build failure is known. Basically https://github.com/rust-lang/rust/issues/44421. Downgrade your glibc if you really want to build.

haawda commented on 2017-10-08 15:32 (UTC)

Fails to build for me: See http://dpaste.com/15FW5ZW

ishitatsuyuki commented on 2017-07-23 02:50 (UTC)

I have disabled the pkgver hack.

SolarAquarion commented on 2017-07-20 14:48 (UTC) (edited on 2017-07-20 14:49 (UTC) by SolarAquarion)

cargo-git-0.21.0.r4496.f709c35a.rust.1.20.0.r65762.9d54ebe550-1-x86_64.pkg.tar.xz PKGBUILD rls-git-0.1.0.r534.618f802.rust.1.20.0.r65762.9d54ebe550-1-x86_64.pkg.tar.xz rust rust-analysis-git-1.20.0.r65762.9d54ebe550-1-x86_64.pkg.tar.xz rust-docs-git-1.20.0.r65762.9d54ebe550-1-any.pkg.tar.xz rust-git-1.20.0.r65762.9d54ebe550-1-x86_64.pkg.tar.xz rust-src-git-1.20.0.r65762.9d54ebe550-1-any.pkg.tar.xz Not all the pkgver's are "1.20"

SolarAquarion commented on 2017-07-20 13:55 (UTC)

@ishitatsuyuki shouldn't it be possible to set llvm to 4.0 or earlier and then remove the epoch? Because isn't that why the epoch is there or not?

SolarAquarion commented on 2017-07-19 19:15 (UTC)

ishitatsuyuki it seems that "rls-git" is the problem for some reason. I even have the problem with it via pacaur.

ishitatsuyuki commented on 2017-07-18 11:36 (UTC)

SolarAquarion: it's your helper's fault. Ignore in the config in the case.

SolarAquarion commented on 2017-07-18 11:22 (UTC)

@ishitatsuyuki Well, bauerbill is telling me to continually update rust-git. Instead of stopping the package automatically, the AUR helper is doing it for me. Like it is trying to get up to "3:...."

ishitatsuyuki commented on 2017-07-18 04:06 (UTC)

@SolarAquarion: no. It effectively prevents anyone from upgrading the package automatically.

SolarAquarion commented on 2017-07-18 03:26 (UTC)

Can you please remove the epoch? @ishitatsuyuki

ishitatsuyuki commented on 2017-05-20 05:24 (UTC)

@spider-mario, would you mind transferring this package to me? Currently the PKGBUILD of mine and you diverges quite much, and I'd like to bring my own improvements to more AUR users.

ishitatsuyuki commented on 2017-04-22 14:49 (UTC)

LLVM 4.0 is now in main repository, I have confirmed that Rust works with that. Sorry for advertising here, but I have also added clippy packages to [rust-git].

ishitatsuyuki commented on 2017-04-19 11:45 (UTC)

LLVM 4.0 is in [testing]. DO NOT UPGRADE.

ishitatsuyuki commented on 2017-04-17 07:40 (UTC)

Checkout my unsigned repository for packages built with my own, diverged PKGBUILD: https://wiki.archlinux.org/index.php/Unofficial_user_repositories#rust-git This is updated on a best effort basis. Normally I rebuild every week, but sometimes I could be busy. Feel free to mail me to request an update. You're welcome to use this for reference: https://gist.github.com/ishitatsuyuki/956152c9ee2562e949f55c0181a0c5ee

ishitatsuyuki commented on 2017-03-31 02:53 (UTC)

I have upgraded my PKGBUILD. No more build twice problems, and it now splits things by dist packages. https://gist.github.com/ishitatsuyuki/956152c9ee2562e949f55c0181a0c5ee

ishitatsuyuki commented on 2017-03-20 01:31 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

@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: https://github.com/rust-lang/rust/issues/40228. 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 (UTC)

@intelfx - please try my personal PKGBUILD - https://gist.github.com/ishitatsuyuki/956152c9ee2562e949f55c0181a0c5ee The downloads directory on my server is also regularly updated, once a week or two.

intelfx commented on 2017-03-08 03:58 (UTC)

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 (UTC)

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 (UTC)

Can reproduce. Will investigate. Random note: I will update the package a few times a week on my server. https://tatsuyuki.kdns.info/downloads/ (This is NOT a pacman repository but simple file server)

intelfx commented on 2017-02-09 10:18 (UTC)

This package builds rust twice again for me.

ishitatsuyuki commented on 2017-02-09 03:49 (UTC)

These flags are an exact copy of the repo version.

spider-mario commented on 2017-02-09 00:24 (UTC)

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 (UTC)

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 (UTC) (edited on 2017-02-03 23:53 (UTC) by spider-mario)

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 https://github.com/rust-lang/rust/issues/39215 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 (UTC)

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 (UTC)

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

spider-mario commented on 2017-02-03 23:40 (UTC)

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 (UTC)

@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 (UTC) (edited on 2017-01-28 07:48 (UTC) by ishitatsuyuki)

This is a brand new PKGBUILD based on the one in official repo, please adopt if it looks good. This is tested anyway. https://gist.github.com/ishitatsuyuki/956152c9ee2562e949f55c0181a0c5ee

ishitatsuyuki commented on 2017-01-20 07:41 (UTC)

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

spider-mario commented on 2017-01-07 14:03 (UTC) (edited on 2017-01-07 14:06 (UTC) by spider-mario)

It appears to be an upstream bug in rustbuild: https://github.com/rust-lang/rust/issues/38547 I have temporarily disabled rustbuild, as there is also this bug: https://github.com/rust-lang/rust/issues/38441 , which breaks the build. https://github.com/alexcrichton/rust/commit/16f8372e0895107ce594ffb111732e48ee35fe86 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 (UTC)

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 (UTC)

It looks like cmake should be a build dependency.

c4757p commented on 2016-10-05 22:12 (UTC)

Sweet, thanks - works for me.

spider-mario commented on 2016-10-02 20:50 (UTC)

It seems to be a known bug: https://github.com/rust-lang/rust/issues/36451 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 (UTC)

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 (UTC)

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+https://github.com/rust-lang/nano-config.git" from source too) See: https://github.com/rust-lang/nano-config/blob/master/README.md

spider-mario commented on 2016-03-26 23:22 (UTC)

This should be fixed, thanks.

intelfx commented on 2016-03-26 14:50 (UTC) (edited on 2016-03-26 14:51 (UTC) by intelfx)

> 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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

As of https://github.com/rust-lang/rust/pull/21738, 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" done 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 (UTC)

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 (UTC)

@Foucault Same thing happens to me.

Foucault commented on 2015-01-02 11:34 (UTC)

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/gen-install-script.sh args gen-install-script: 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: gen-install-script: validating /home/build/abs/rust-git/src/rust/src/rust-installer/gen-install-script.sh args gen-install-script: 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/install.sh: No such file or directory /home/build/abs/rust-git/src/rust/mk/install.mk:22: recipe for target 'install' failed make: *** [install] Error 127

spider-mario commented on 2014-10-22 06:33 (UTC)

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

abandonedaccount commented on 2014-10-22 05:16 (UTC)

@spider-mario very nice, using the info you provided, replacing $startdir with $SRCDEST works as intended; maybe worth noting what's my env: PKGDEST=/tmp/packages SRCDEST=/tmp/sources SRCPKGDEST=/tmp/srcpackages BUILDDIR=/tmp/makepkg and $startdir is /home/emacs/build/rust-git Thanks.

spider-mario commented on 2014-10-20 18:20 (UTC)

@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 (UTC)

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 (UTC)

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 (UTC)

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

gsnedders commented on 2014-06-10 13:29 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

Done, thank you.

spider-mario commented on 2014-03-30 10:34 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

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 (UTC)

The nightly build will be fixed after https://github.com/mozilla/rust/pull/12076 lands. It passes `--disable-rpath` to configure and this option broke a few days ago.

colemickens commented on 2014-02-06 01:19 (UTC)

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 (UTC)

It needs to be updated to include `options=(staticlibs)` since the default is now to remove them: https://github.com/thestinger/packages/tree/master/rust-git Note that there's a nightly repository you can use instead of building yourself: http://pkgbuild.com/~thestinger/repo/

idupree commented on 2013-11-16 20:02 (UTC)

The `rustc` from this PKGBUILD is giving me an error when used on a "hello world" program. rustc built manually by "git clone https://github.com/mozilla/rust; ./configure --prefix=/home/me/inst; make; make install" works fine. % rustc hello.rs 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 (UTC)

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. http://paste.ubuntu.com/6339858/

thestinger commented on 2013-09-22 17:37 (UTC)

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

LeonidasXIV commented on 2013-09-22 12:09 (UTC)

Todays build fails: x86_64-unknown-linux-gnu/stage0/bin/rustc: error while loading shared libraries: libtinfo.so.5: 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/libstd.so] Error 127

spider-mario commented on 2013-09-08 10:57 (UTC)

Appearently, the reason why the patch doesn’t apply anymore is that the problem has been fixed upstream: https://github.com/mozilla/rust/commit/75afcffc2ffdbac1d0a837d8407ae5720dce9631 \o/

thestinger commented on 2013-09-07 22:02 (UTC)

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: https://github.com/thestinger/packages/blob/master/rust-git/PKGBUILD http://pkgbuild.com/~thestinger/repo/

LeonidasXIV commented on 2013-09-07 21:54 (UTC)

Thanks for looking into it, I appreciate it. Unfortunately, it fails even earlier now: ==> Starting prepare()... error: patch failed: mk/rt.mk:178 Falling back to three-way merge... Applied patch to 'mk/rt.mk' with conflicts. U mk/rt.mk ==> ERROR: A failure occurred in prepare(). Aborting...

spider-mario commented on 2013-09-07 14:36 (UTC)

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

LeonidasXIV commented on 2013-09-07 11:50 (UTC)

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 (UTC)

Fixed, thanks! :)

draven commented on 2013-09-05 14:20 (UTC)

Hi! 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 (UTC)

By the way, I have daily builds of rust-git in a repository: [thestinger] SigLevel = Optional Server = http://pkgbuild.com/~thestinger/repo/$arch

spider-mario commented on 2013-05-01 21:39 (UTC)

Applied, thanks. :)

thestinger commented on 2013-05-01 21:34 (UTC)

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 (UTC)

@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 (UTC)

s/hear/here/ # ;(

ackalker commented on 2013-01-30 00:30 (UTC)

After building and installing this package, and every time something runs 'ldconfig', I get these warnings: ldconfig: File /usr/lib/libcargo.so is empty, not checked. ldconfig: File /usr/lib/librusti.so is empty, not checked. ldconfig: File /usr/lib/librustdoc.so is empty, not checked. ldconfig: File /usr/lib/librustc.so is empty, not checked. Probably an upstream bug, but posted hear just FYI.

thestinger commented on 2013-01-03 07:27 (UTC)

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

commented on 2012-12-23 20:40 (UTC)

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 (UTC)

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.

commented on 2012-12-23 19:03 (UTC)

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; make; 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" fi Something along these lines perhaps.

spider-mario commented on 2012-12-23 18:04 (UTC)

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

commented on 2012-12-23 17:43 (UTC)

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 (UTC)

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 (UTC)

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 (UTC)

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

Svenstaro commented on 2012-10-12 16:48 (UTC)

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?)

commented on 2012-10-12 16:06 (UTC)

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

commented on 2012-10-12 11:39 (UTC)

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 (UTC)

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). [1]: $ pwd /home/mrshpot/build/rust-git/src/llvm/utils/llvm-build $ 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/__init__.py", 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 (UTC)

Are you sure you need to replace “python” with “python2”? This page: https://github.com/graydon/rust/wiki/Doc-getting-started suggests that Python 3 should be used.