Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aarch64: ZHF for aarch64 (1/??) #51813

Merged
merged 18 commits into from Dec 21, 2018

Conversation

samueldr
Copy link
Member

@samueldr samueldr commented Dec 10, 2018

Motivation for this change

Reduce the amount of failures for aarch64. This is done mainly through disabling builds for packages which cannot build on aarch64. I have skipped over some packages which could realistically be built, with effort. Most of those disabled here use x86_64 features pretty explicitly.

There is either a comment preceding the badPlatforms property with details, or a detailed explanation in the commit message.


Some additional notes:

aerospike has been disabled again on aarch64-linux, this time it's been removed as a default for aarch64 in the module, making it not fail uselessly in Hydra. I'm thinking the entire module could also be conditional on valid platforms for the package, but it would stop end-users from using it with a fork for fixing it :/. (With defaultText it's not as much an issue. No hairy conditional.) cc @kalbasit

boost 1.55 was previously flagged as not building on aarch64-linux for versions preceding 1.59, but the semantics of platforms changed, re-adding the failing build.

openbabel is given a patch from upstream to fix its build. This additional patch will be removed once they release another version including the change.

Anything else is trivial.

Things done
  • ✔️ Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • ✔️ NixOS
    • ⬜ macOS
    • ⬜ other Linux distributions
  • ⬜ Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • ⬜ Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • ⬜ Tested execution of all binary files (usually in ./result/bin/)
  • ⬜ Determined the impact on package closure size (by running nix path-info -S before and after)
  • ✔️ Assured whether relevant documentation is up to date
  • ✔️ Fits CONTRIBUTING.md.

@kalbasit
Copy link
Member

for aerospike, it LGTM.

@@ -107,5 +107,7 @@ stdenv.mkDerivation rec {
license = licenses.lgpl21Plus;
maintainers = with maintainers; [ artuuge zimbatm ];
platforms = platforms.linux;
# Requires libdrm_intel
badPlatforms = [ "aarch64-linux" ];
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What is the semantics of badPlatforms?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, I don't that described or even affecting any processing in nixpkgs.

Copy link
Member Author

@samueldr samueldr Dec 10, 2018

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See b048224, platforms used are, simplified, platforms - badplatforms. Current implementation.

For beignet specifically, I would have preferred having a way to compose linux × [i686, x86_64], but I don't think it's possible with how the platforms work currently.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK this is the last remaining open "issue" about this PR. Anything required to change about the use of badPlatforms? Any better way to semantically say "x86-based platforms only" while still allowing to say "and linux" or "and either linux or darwin"?

The issue with its inclusion in the manual has been side-stepped by
matching on the platforms in supports.
It looks like it would be a trivial fix with
`-Wno-shift-negative-value`, but in the end it fails with:

```
[100%] Linking C executable aften
libaften_static.a(a52enc.o): In function `aften_encode_init':
a52enc.c:(.text+0x303c): undefined reference to `apply_simd_restrictions'
collect2: error: ld returned 1 exit status
```

So it looks like it's not simply a warning issue.
 * https://hydra.nixos.org/build/84910540

```
Making check in eigen
make[1]: Entering directory '/build/gsl-1.16/eigen'
make  test
make[2]: Entering directory '/build/gsl-1.16/eigen'
gcc -DHAVE_CONFIG_H -I. -I.. -I..    -g -O2 -c test.c
/nix/store/bsb6596kk4fp20hyl9yl55xwv1ax4b6s-bash-4.4-p23/bin/bash ../libtool  --tag=CC   --mode=link gcc  -g -O2   -o test test.o libgsleigen.la  ../test/libgsltest.la ../linalg/libgsllinalg.la ../permutation/libgslpermutation.la ../blas/libgslblas.la ../cblas/libgslcblas.la ../matrix/libgslmatrix.la ../vector/libgslvector.la ../block/libgslblock.la  ../complex/libgslcomplex.la ../ieee-utils/libgslieeeutils.la ../sys/libgslsys.la ../err/libgslerr.la ../utils/libutils.la ../rng/libgslrng.la ../sort/libgslsort.la -lm
libtool: link: gcc -g -O2 -o .libs/test test.o  ./.libs/libgsleigen.a ../test/.libs/libgsltest.a ../linalg/.libs/libgsllinalg.a ../permutation/.libs/libgslpermutation.a ../blas/.libs/libgslblas.a ../cblas/.libs/libgslcblas.so ../matrix/.libs/libgslmatrix.a ../vector/.libs/libgslvector.a ../block/.libs/libgslblock.a ../complex/.libs/libgslcomplex.a ../ieee-utils/.libs/libgslieeeutils.a ../sys/.libs/libgslsys.a ../err/.libs/libgslerr.a ../utils/.libs/libutils.a ../rng/.libs/libgslrng.a ../sort/.libs/libgslsort.a -lm -Wl,-rpath -Wl,/nix/store/rz7sjaxwm3qf6nk9kk90v1qf81y1s62v-gsl-1.16/lib
make[2]: Leaving directory '/build/gsl-1.16/eigen'
make  check-TESTS
make[2]: Entering directory '/build/gsl-1.16/eigen'
make[3]: Entering directory '/build/gsl-1.16/eigen'
FAIL: test
make[4]: Entering directory '/build/gsl-1.16/eigen'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/build/gsl-1.16/eigen'
====================================
   gsl 1.16: eigen/test-suite.log
====================================

.. contents:: :depth: 2

FAIL: test
==========

FAIL: herm random, normalized(1), unsorted (0.999999999999999112 observed vs 1 expected) [117761]
FAIL: herm random, normalized(2), val/asc (0.999999999999999112 observed vs 1 expected) [117789]
FAIL: herm random, normalized(0), val/desc (0.999999999999999112 observed vs 1 expected) [117811]
FAIL: herm random, normalized(1), abs/asc (0.999999999999999112 observed vs 1 expected) [117836]
FAIL: herm random, normalized(1), abs/desc (0.999999999999999112 observed vs 1 expected) [117860]

```
This is due to glucose not building.
Between 2b45037 and the current
revision, the semantics behind "platforms" changed, and removing the
"aarch64-linux" string doesn't work anymore to filter it out.

Instead, blacklist the platform using the (comparatively) new
badPlatforms.
Furthermore, this package needs to either be dropped or updated. The
version packaged is old, and the project has been abandoned by upstream.
There is no "arm64" machine, and using "arm32le" does not work.
@samueldr samueldr force-pushed the aarch64/disable-non-arm-builds-part-1 branch from db4da5f to 1670768 Compare December 10, 2018 19:55
@samueldr samueldr merged commit 3c38cc8 into NixOS:master Dec 21, 2018
m0rg-dev added a commit to m0rg-dev/nixpkgs that referenced this pull request Jun 7, 2023
This package has been disabled on aarch64-linux since NixOS#51813 in 2018, but was
not updated to include aarch64-darwin in badPlatforms, so it's been failing
there. While investigating the build failure, I found that it would be trivial
to patch bootil to compile on aarch64.

The only x86-specific code in bootil is in src/3rdParty/smhasher/Platform.h,
which defines a function which references the x86 RDTSC instruction using
inline assembly. That function is neither exported nor used by the library
itself, so I've patched it out and re-enabled aarch64 compilation.
@m0rg-dev m0rg-dev mentioned this pull request Jun 7, 2023
12 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants