Package Details: arm-linux-gnueabihf-binutils 2.42-1

Git Clone URL: https://aur.archlinux.org/arm-linux-gnueabihf-binutils.git (read-only, click to copy)
Package Base: arm-linux-gnueabihf-binutils
Description: A set of programs to assemble and manipulate binary and object files
Upstream URL: https://www.gnu.org/software/binutils/
Licenses: GPL
Submitter: tavianator
Maintainer: wgottwalt
Last Packager: wgottwalt
Votes: 62
Popularity: 0.63
First Submitted: 2015-09-14 15:26 (UTC)
Last Updated: 2024-02-11 05:18 (UTC)

Latest Comments

« First ‹ Previous 1 2

zyeri commented on 2017-08-14 23:40 (UTC)

Build is failing: error states that a directory (src/binutils-build) already exists.

rpodgorny commented on 2017-03-11 23:32 (UTC) (edited on 2017-03-11 23:33 (UTC) by rpodgorny)

@kevr: base-devel dep is implicit (next time at least read other comments ;-) )

kevr commented on 2017-03-11 23:27 (UTC) (edited on 2017-03-11 23:28 (UTC) by kevr)

@tavianator Please include bison and other development dependencies in makedepends; it is not okay to assume that everybody has bison, and finding out that you need it after the entire compilation is pretty lame.

tavianator commented on 2016-03-24 20:58 (UTC)

@kralyk: bison is part of base-devel, which you should have installed if you're building packages.

vojtechkral commented on 2016-03-20 09:32 (UTC)

There's a missing makedepend: bison

tavianator commented on 2016-02-29 16:51 (UTC)

@pmattern: The new PKGBUILD doesn't use the git repo any more. Instead it downloads the tarball and patches it.

tavianator commented on 2015-09-22 01:52 (UTC)

@pmattern: binutils in [core] uses this git repo instead of a release tarball because "bug fix releases are rare". I wanted this package to be exactly the same binutils version as in [core], hence the git repo. For future updates, you won't need to re-clone the repo, so it won't be as bad. https://projects.archlinux.org/svntogit/packages.git/tree/binutils/trunk/PKGBUILD#n6

pmattern commented on 2015-09-20 17:26 (UTC)

PKGBUILD is stating two sources of the actual code which is confusing and should be avoided. Regarding the choice I'm not sure whether using a VCS checkout is the best for this package providing a release after all. The download is about 250MB vs. 23MB. These sizes may assimilate if the VCS checkouts gets re-used but I don't know to what degree this is common practice. More importantly the Git repo cannot get downloaded via secure connections while the release archives come with PGP signatures. Couldn't see any problems using the release archive instead of a Git checkout here. One of the tests in check() is failing. Just saying, no idea whether or not this is meaningful.

« First ‹ Previous 1 2