summaryrefslogtreecommitdiff
path: root/var/spack/repos/builtin/packages/binutils
AgeCommit message (Collapse)AuthorFilesLines
2024-01-02Update copyright year to 2024 (#41919)Todd Gamblin1-1/+1
It was time to run `spack license update-copyright-year` again.
2023-12-27directives: add `checked_by` field to `license()`, add some license checksTodd Gamblin1-1/+4
Add a "checked_by" field to the `license()` directive so that we can track who verified the license for a project. also check the license of 18 or so projects and mark them checked.
2023-12-27Initial License CheckinAiden Grossman1-0/+2
This patch adds license information for about 5,300 packages from automated sources. The license information was obtained from Alpine Linux and PyPI and processed using tooling available in https://github.com/boomanaiden154/spack-license-utils. The license field was added in after all other directives in an automated fashion. Note that while this license information is probably fairly accurate, it is not guaranteed to be accurate. In addition some of the license strings from Alpine Linux might not be valid SPDX license strings. Invalid SPDX identifiers can be picked up and fixed once we have validation/parsing infrastructure in place for the solver, and issues can be fixed as they come up.
2023-10-03Fix binutils regression on +gas~ld fix (#40292)Jordan Galby1-7/+9
2023-09-12binutils: add v2.41 (#39483)Massimiliano Culpo1-0/+1
2023-08-09zlib-api: new virtual with zlib/zlib-ng as providers (#37372)Harmen Stoppels1-1/+1
Introduces a new virtual zlib-api, which replaces zlib in most packages. This allows users to switch to zlib-ng by default for better performance.
2023-05-29binutils: convert to new stand-alone test process (#37690)Tamara Dahlgren1-25/+31
2023-05-05binutils: enable debug section compression with zlib by default (#37359)Harmen Stoppels1-0/+16
2023-05-02libintl, iconv, gettext: account for libc provider and externals (#35450)Chris Green1-6/+9
* libiconv can be provided by libc, so update packages which depend on libiconv to require the iconv virtual instead * Many packages need special consideration when locating iconv depending on whether it is provided by libc (no prefix provided) or the libiconv package (in that case we want to provide a prefix) * It was also noticed that when an iconv external was provided, that there was interference with linking (this should generally be handled by Spack's compiler wrappers and bears further investigation) * Like iconv, libintl can be provided by libc or another package, namely gettext. It is not converted to a provider like libiconv because it provides additional routines. The logic is similar to that of iconv but instead of checking the provider, we check whether the gettext installation includes libintl.
2023-04-05binutils: deprecate old version, build static on darwin (#36646)Massimiliano Culpo1-10/+51
The issue comes from libctf.
2023-04-03binutils 2.40: add missing zstd dep (#36598)Harmen Stoppels1-0/+5
2023-02-16Style: black 23, skip magic trailing comma (#35351)Adam J. Stewart1-5/+1
* Style: black 23, skip magic trailing commas * isort should use same line length as black * Fix unused import * Update version of black used in CI * Update new packages * Update new packages
2023-02-01Use the `maintainers` directive in all packages (#35201)Massimiliano Culpo1-1/+1
2023-01-26binutils: v2.30, 2.39, 2.40 (#35128)Harmen Stoppels1-17/+59
- Add `binutils +pgo` - Add dejagnu build dep and fix its deps - Default to -O3 -g0 when using gcc/clang to make binutils faster and smaller
2023-01-18license year bump (#34921)Harmen Stoppels1-1/+1
* license bump year * fix black issues of modified files * mypy * fix 2021 -> 2023
2022-12-08Add texinfo dependency for binutils through version 2.38. (#34173)Jon Rood1-5/+2
2022-10-26Allow for packages with multiple build-systems (#30738)Massimiliano Culpo1-73/+63
This commit extends the DSL that can be used in packages to allow declaring that a package uses different build-systems under different conditions. It requires each spec to have a `build_system` single valued variant. The variant can be used in many context to query, manipulate or select the build system associated with a concrete spec. The knowledge to build a package has been moved out of the PackageBase hierarchy, into a new Builder hierarchy. Customization of the default behavior for a given builder can be obtained by coding a new derived builder in package.py. The "run_after" and "run_before" decorators are now applied to methods on the builder. They can also incorporate a "when=" argument to specify that a method is run only when certain conditions apply. For packages that do not define their own builder, forwarding logic is added between the builder and package (methods not found in one will be retrieved from the other); this PR is expected to be fully backwards compatible with unmodified packages that use a single build system.
2022-07-31black: reformat entire repository with blackTodd Gamblin1-117/+117
2022-05-28refactor: packages import `spack.package` explicitly (#30404)Tom Scogland1-0/+2
Explicitly import package utilities in all packages, and corresponding fallout. This includes: * rename `spack.package` to `spack.package_base` * rename `spack.pkgkit` to `spack.package` * update all packages in builtin, builtin_mock and tutorials to include `from spack.package import *` * update spack style * ensure packages include the import * automatically add the new import and remove any/all imports of `spack` and `spack.pkgkit` from packages when using `--fix` * add support for type-checking packages with mypy when SPACK_MYPY_CHECK_PACKAGES is set in the environment * fix all type checking errors in packages in spack upstream * update spack create to include the new imports * update spack repo to inject the new import, injection persists to allow for a deprecation period Original message below: As requested @adamjstewart, update all packages to use pkgkit. I ended up using isort to do this, so repro is easy: ```console $ isort -a 'from spack.pkgkit import *' --rm 'spack' ./var/spack/repos/builtin/packages/*/package.py $ spack style --fix ``` There were several line spacing fixups caused either by space manipulation in isort or by packages that haven't been touched since we added requirements, but there are no functional changes in here. * [x] add config to isort to make sure this is maintained going forward
2022-05-02binutils@2.38 %gcc: add -fPIC -fcommon -Wl,-z,notext (#30345)eugeneswalker1-5/+6
2022-04-29CrayPE_binutils package fix for CCE (#30338)luker1-0/+5
2022-04-27Add fix for binutils 2.38 +gas makeinfo issue (#30209)Derek Ryan Strong1-0/+3
Co-authored-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
2022-02-24Adjust binutils detection (#29188)Glenn Johnson1-2/+2
The `spack external find binutils` command was failing to find my system binutils because the regex was not matching. The name of the executable follows the string 'GNU' that I tested with three different installations so I changed the regex to look for that. On my CentOS-7 system, the version had the RPM details so I set the version to capture the first three parts of the version.
2022-02-19binutils: add v2.38 (#29067)Harmen Stoppels1-0/+1
2022-02-18spack external find: change default behavior (#29031)Massimiliano Culpo1-0/+2
See https://github.com/spack/spack/issues/25353#issuecomment-1041868116 This commit changes the default behavior of ``` $ spack external find ``` from searching all the possible packages Spack knows about to search only for the ones tagged as being a "build-tool". It also introduces a `--all` option to restore the old behavior.
2022-02-17binutils: add external detection (#29022)Tom Scogland1-0/+9
2022-01-14Update copyright year to 2022Todd Gamblin1-1/+1
2021-10-12binutils: fix parallel make for version 2.36 (#26611)Mark W. Krentel2-7/+57
There was a bug in 2.36.* of missing Makefile dependencies. The previous workaround was to require 2.36 to be built serially. This is now fixed upstream in 2.37 and this PR adds the patch to restore parallel make to 2.36.
2021-10-03Remove .99 from version ranges (#26422)Harmen Stoppels1-2/+2
In most cases, .99 can be omitted thanks to #26402 .
2021-09-02start of work to add spack audit packages-https checker (#25670)Vanessasaurus1-1/+1
This PR will add a new audit, specifically for spack package homepage urls (and eventually other kinds I suspect) to see if there is an http address that can be changed to https. Usage is as follows: ```bash $ spack audit packages-https <package> ``` And in list view: ```bash $ spack audit list generic: Generic checks relying on global variables configs: Sanity checks on compilers.yaml Sanity checks on packages.yaml packages: Sanity checks on specs used in directives packages-https: Sanity checks on https checks of package urls, etc. ``` I think it would be unwise to include with packages, because when run for all, since we do requests it takes a long time. I also like the idea of more well scoped checks - likely there will be other addresses for http/https within a package that we eventually check. For now, there are two error cases - one is when an https url is tried but there is some SSL error (or other error that means we cannot update to https): ```bash $ spack audit packages-https zoltan PKG-HTTPS-DIRECTIVES: 1 issue found 1. Error with attempting https for "zoltan": <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for 'www.cs.sandia.gov'. (_ssl.c:1125)> ``` This is either not fixable, or could be fixed with a change to the url or (better) contacting the site owners to ask about some certificate or similar. The second case is when there is an http that needs to be https, which is a huge issue now, but hopefully not after this spack PR. ```bash $ spack audit packages-https xman Package "xman" uses http but has a valid https endpoint. ``` And then when a package is fixed: ```bash $ spack audit packages-https zlib PKG-HTTPS-DIRECTIVES: 0 issues found. ``` And that's mostly it. :) Signed-off-by: vsoch <vsoch@users.noreply.github.com> Co-authored-by: vsoch <vsoch@users.noreply.github.com>
2021-08-11binutils: add v2.37 (#25356)Massimiliano Culpo1-0/+3
2021-05-18binutils: fix NameError from commit de8027 (#23715)eugeneswalker1-1/+1
2021-05-17CrayPE fix for binutils (#23500)lukebroskop1-1/+8
Allow for multiple definitions at link time (for CrayPE) Co-authored-by: Tamara Dahlgren <35777542+tldahlgren@users.noreply.github.com> Co-authored-by: Harmen Stoppels <harmenstoppels@gmail.com>
2021-05-12lzo, lz4, xz, binutils: add libs multi-valued variant (#23474)Harmen Stoppels1-1/+3
2021-05-10binutils: Improve flag_handler (#22642)Michael Kuhn1-3/+6
`flag_handler` currently passes all flags via injection. This makes it impossible to override the default flags provided by autotools (for instance, `binutils cflags='-O2'` will still build with `-O2 -g`). Instead, use injection for our workaround flags and pass other flags to the build system.
2021-05-02Another binutils fix (#23337)Harmen Stoppels1-3/+5
* Building binutils with gold implies building ld * add +ld to llvm to make the old concretizer happy and add +gas to gcc since that's used in the package.py * Remove sys
2021-04-28binutils: default to +plugins (#23309)Harmen Stoppels1-1/+1
2021-04-20binutils: drop overly strict conflicts for assembler/linker (#23122)Harmen Stoppels1-8/+7
This has been checked with gcc on ubuntu 16.04, which ships binutils 2.26 by default, using spack's binutils 2.36. Only the combination +gas and ~ld seems to trigger this incompatibility with debug symbols (gcc -g -O2 main.c fails with the error in the comment above the conflict)
2021-04-19binutils: add option for assembler, constrain 'as' and 'ld' variants (#23065)Harmen Stoppels1-0/+11
Avoid that the user builds the assembler without the linker, because you may run into problems when the host linker is old: https://wiki.gentoo.org/wiki/Binutils_2.32_upgrade_notes/elfutils_0.175:_unable_to_initialize_decompress_status_for_section_.debug_info
2021-04-13Fix issue where binutils builds ld with ~ld (#22959)Harmen Stoppels1-21/+14
Let's be very explicit and always add --enable or --disable.
2021-03-01binutils: add versions 2.35.2 and 2.36.1 (#22019)Mark W. Krentel1-0/+9
Starting with 2.36, the Makefiles are missing some dependencies for linking libctf and thus require serial make install.
2021-01-02copyrights: update all files with license headers for 2021Todd Gamblin1-1/+1
- [x] add `concretize.lp`, `spack.yaml`, etc. to licensed files - [x] update all licensed files to say 2013-2021 using `spack license update-copyright-year` - [x] appease mypy with some additions to package.py that needed for oneapi.py
2020-11-18spack test (#15702)Greg Becker1-0/+26
Users can add test() methods to their packages to run smoke tests on installations with the new `spack test` command (the old `spack test` is now `spack unit-test`). spack test is environment-aware, so you can `spack install` an environment and then run `spack test run` to run smoke tests on all of its packages. Historical test logs can be perused with `spack test results`. Generic smoke tests for MPI implementations, C, C++, and Fortran compilers as well as specific smoke tests for 18 packages. Inside the test method, individual tests can be run separately (and continue to run best-effort after a test failure) using the `run_test` method. The `run_test` method encapsulates finding test executables, running and checking return codes, checking output, and error handling. This handles the following trickier aspects of testing with direct support in Spack's package API: - [x] Caching source or intermediate build files at build time for use at test time. - [x] Test dependencies, - [x] packages that require a compiler for testing (such as library only packages). See the packaging guide for more details on using Spack testing support. Included is support for package.py files for virtual packages. This does not change the Spack interface, but is a major change in internals. Co-authored-by: Tamara Dahlgren <dahlgren1@llnl.gov> Co-authored-by: wspear <wjspear@gmail.com> Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
2020-11-13binutils: Fix checksum for 2.35.1 (#19901)fodinabor1-1/+1
As noted in #19899 and introduced by #19827
2020-11-12binutils: add version 2.35.1 (#19827)Tim Haines1-0/+1
2020-09-03install/install_tree: glob support (#18376)Adam J. Stewart1-5/+2
* install/install_tree: glob support * Add unit tests * Update existing packages * Raise error if glob finds no files, document function raises
2020-08-28binutils: add build dep: diffutils (provides `cmp`) (#18361)eugeneswalker1-0/+1
2020-08-26binutils: add version 2.35 (#18291)eugeneswalker1-0/+1
2020-06-25Separate Apple Clang from LLVM Clang (#17110)Massimiliano Culpo1-3/+4
* Separate Apple Clang from LLVM Clang Apple Clang is a compiler of its own. All places referring to "-apple" suffix have been updated. * Hack to use a dash in 'apple-clang' To be able to use autodoc from Sphinx we need a valid Python name for the module that contains Apple's Clang code. * Updated packages to account for the existence of apple-clang Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com> * Added unit test for XCode related functions Co-authored-by: Gregory Becker <becker33@llnl.gov> Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
2020-05-15binutils: fix build with gcc@10: (#16661)Michael Kuhn1-0/+3
The issue seems to be fixed in the development version already.