Compile glibc without -fstack-protector. #1
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
At least until NixOS full supports -fstack-protector it's better to turn it off at the moment, as previous successful builds didn't include it either.
|
What would be required for NixOS to fully support -fstack-protector? |
|
https://wiki.ubuntu.com/GccSsp - but that was dated 2006, and for example the kernel now fully supports it. |
|
No one that I know of. If you think you could put something together go for it. |
|
I assume that since this is a Glibc change, it should go into the stdenv branch? |
|
BTW, what is actually gained by disabling stack protection in Glibc? Sure, we don't turn it on in other packages, but does that affect stack protection in Glibc functions? |
|
Yeah, the stdenv concern is why I suggested we look into using stack protection more completely. No idea whether stack protection needs to be in all packages to be useful in any. |
|
Well, the original reason for disabling SSP was because of these build failures: |
|
Is there anything that's harmed by keeping this as it is for now? Since this will require a stdenv rebuild we'd have to put this into a stdenv-updates branch at first anyway, but if it's not a big deal maybe this can wait until a more compelling reason for stdenv-updates arises? Anyway, we can't merge this into master so I'm closing. If it's important to have this fixed soon, please open a PR against the stdenv-updates branch. |
|
@edolstra Ok, having looked into this we have a strange problem. Building glibc as part of stdenv works fine (i.e. nix-build -A glibc), but building the same glibc with the final stdenv instead of the bootstrap fails (i.e. nix-build -A glibc213). So there's definitely an issue. Should I open a stdenv-updates branch? |
Glibc 2.14 also produces a build failure in Hydra, so we need to apply the same fix here, too.
|
It's already open, see https://github.com/NixOS/nixpkgs/commits/stdenv-updates |
ecarreras
referenced
this pull request
in ecarreras/nixpkgs
Oct 1, 2012
Add xserver integration of i3 WM.
bjornfor
added a commit
that referenced
this pull request
Feb 16, 2014
The bsddb module is apparently not compatible with db5 (or db48), so switch
back to db44. Fixes the following build error:
$ nix-build -A python26.modules
these derivations will be built:
/nix/store/5zcqmpa4iby0aa342psjph0byiyikm6h-python-bsddb-2.6.8.drv
building path(s) `/nix/store/qpsjyx7nmxhm9zq40674wr67dx8w6ycl-python-bsddb-2.6.8'
building /nix/store/qpsjyx7nmxhm9zq40674wr67dx8w6ycl-python-bsddb-2.6.8
unpacking sources
unpacking source archive /nix/store/2qwc1kd8allnaljm1z360lv9jsf8cfqy-Python-2.6.8.tar.bz2
source root is Python-2.6.8
patching sources
applying patch /nix/store/cfk04ans56xql9l6waqhqzzd60g9rzxi-search-path.patch
patching file setup.py
Hunk #1 succeeded at 424 (offset 145 lines).
applying patch /nix/store/dxscwf37hgq0xafs54h0c8xx47vg6d5g-nix-store-mtime.patch
patching file Python/import.c
Hunk #1 succeeded at 747 (offset -4 lines).
configuring
building
running build_ext
INFO: Can't locate Tcl/Tk libs and/or headers
Traceback (most recent call last):
File "./setup.py", line 2037, in <module>
main()
File "./setup.py", line 2032, in main
'Lib/smtpd.py']
File "/nix/store/xxzwak31qql6vq7v35xmq68zmjpfr5py-python-2.6.8/lib/python2.6/distutils/core.py", line 152, in setup
dist.run_commands()
File "/nix/store/xxzwak31qql6vq7v35xmq68zmjpfr5py-python-2.6.8/lib/python2.6/distutils/dist.py", line 975, in run_commands
self.run_command(cmd)
File "/nix/store/xxzwak31qql6vq7v35xmq68zmjpfr5py-python-2.6.8/lib/python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/nix/store/xxzwak31qql6vq7v35xmq68zmjpfr5py-python-2.6.8/lib/python2.6/distutils/command/build_ext.py", line 340, in run
self.build_extensions()
File "./setup.py", line 249, in build_extensions
longest = max([len(e.name) for e in self.extensions])
ValueError: max() arg is an empty sequence
builder for `/nix/store/5zcqmpa4iby0aa342psjph0byiyikm6h-python-bsddb-2.6.8.drv' failed with exit code 1
error: build of `/nix/store/5zcqmpa4iby0aa342psjph0byiyikm6h-python-bsddb-2.6.8.drv' failed
wavewave
referenced
this pull request
in wavewave/nixpkgs
Sep 20, 2014
fix some packages that won't build in the darwin-clang-stdenv
adrianpk
added a commit
to adrianpk/nixpkgs
that referenced
this pull request
May 31, 2024
The sed expression actually caused an error on hydra: ``` sed: -e expression NixOS#1, char 18: Invalid collation character ``` It seems to build fine without it however.
adrianpk
added a commit
to adrianpk/nixpkgs
that referenced
this pull request
May 31, 2024
The sed expression actually caused an error on hydra: ``` sed: -e expression NixOS#1, char 18: Invalid collation character ``` It seems to build fine without it however.
adrianpk
added a commit
to adrianpk/nixpkgs
that referenced
this pull request
May 31, 2024
This hopefully fixes intermittent test failures like http://hydra.nixos.org/build/29962437 router# [ 240.128835] INFO: task mke2fs:99 blocked for more than 120 seconds. router# [ 240.130135] Not tainted 3.18.25 NixOS#1-NixOS router# [ 240.131110] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. assuming that these are caused by high load on the host. (cherry picked from commit 6d02d7e)
1 task
Merged
13 tasks
13 tasks
13 tasks
13 tasks
fpletz
pushed a commit
that referenced
this pull request
Aug 24, 2024
Strongly inspired by the forgejo counterpart[1], for the following
reasons:
* The feature is broken with the current module and crashes on
authentication with the following stacktrace (with a PAM service
`gitea` added):
server # Stack trace of thread 1008:
server # #0 0x00007f3116917dfb __nptl_setxid (libc.so.6 + 0x8ddfb)
server # #1 0x00007f3116980ae6 setuid (libc.so.6 + 0xf6ae6)
server # #2 0x00007f30cc80f420 _unix_run_helper_binary (pam_unix.so + 0x5420)
server # #3 0x00007f30cc8108c9 _unix_verify_password (pam_unix.so + 0x68c9)
server # #4 0x00007f30cc80e1b5 pam_sm_authenticate (pam_unix.so + 0x41b5)
server # #5 0x00007f3116a84e5b _pam_dispatch (libpam.so.0 + 0x3e5b)
server # #6 0x00007f3116a846a3 pam_authenticate (libpam.so.0 + 0x36a3)
server # #7 0x00000000029b1e7a n/a (.gitea-wrapped + 0x25b1e7a)
server # #8 0x000000000047c7e4 n/a (.gitea-wrapped + 0x7c7e4)
server # ELF object binary architecture: AMD x86-64
server #
server # [ 42.420827] gitea[897]: pam_unix(gitea:auth): unix_chkpwd abnormal exit: 159
server # [ 42.423142] gitea[897]: pam_unix(gitea:auth): authentication failure; logname= uid=998 euid=998 tty= ruser= rhost= user=snenskek
It only worked after turning off multiple sandbox settings and adding
`shadow` as supplementary group to `gitea.service`.
I'm not willing to maintain additional multiple sandbox settings for
different features, especially given that it was probably not used for
quite a long time:
* There was no PR or bugreport about sandboxing issues related to
PAM.
* Ever since the module exists, it used the user `gitea`, i.e. it had
never read-access to `/etc/shadow`.
* Upstream has it disabled by default[2].
If somebody really needs it, it can still be brought back by an overlay
updating `tags` accordingly and modifying the systemd service config.
[1] 07641a9
[2] https://docs.gitea.com/usage/authentication#pam-pluggable-authentication-module
13 tasks
azuwis
added a commit
to azuwis/nixpkgs
that referenced
this pull request
Sep 8, 2024
[Vidstab][1] is an useful ffmpeg video stabilization filter. Both [Debian][2] and [Archlinux][3] enable it on default ffmpeg build, we should also enable it on default ffmpeg in nixpkgs. On the `master` branch, closure size for ffmpeg-headless went up 182.9KiB. ``` $ nix store diff-closures nixpkgs#ffmpeg-headless^bin .#ffmpeg-headless^bin ffmpeg-headless: +18.1 KiB vid.stab-unstable: ∅ → 2022-05-30, +164.8 KiB $ nvd diff $(nix build nixpkgs#ffmpeg-headless^bin --print-out-paths --no-link) $(nix build .#ffmpeg-headless^bin --print-out-paths --no-link) <<< /nix/store/kwihalx7ryh51ghcp8f1hhy8skbdh8w9-ffmpeg-headless-6.1.2-bin >>> /nix/store/ps62y85p9jgjbf2x9s97199mpqnd0ggz-ffmpeg-headless-6.1.2-bin Added packages: [A.] NixOS#1 vid.stab-unstable 2022-05-30 Closure size: 78 -> 79 (4 paths added, 3 paths removed, delta +1, disk usage +182.9KiB). ``` [1]: http://public.hronopik.de/vid.stab/ [2]: https://salsa.debian.org/multimedia-team/ffmpeg/-/blob/debian/7%256.1.1-5/debian/control#L158 [3]: https://gitlab.archlinux.org/archlinux/packaging/packages/ffmpeg/-/blob/2-6.1.1-7/PKGBUILD?ref_type=tags#L73
This was referenced Sep 14, 2024
Closed
alyssais
pushed a commit
that referenced
this pull request
Oct 12, 2024
The first assumption[1] we had was that the `aarch64-unknown-none` target was missing from rustc and that this was the cause for the regression. However, it turns out that the relevant code from `rustc` wasn't used anyways because the Makefile does `--sysroot /dev/null`[2] which prevents rustc from using its own libcore. So luckily we don't have to patch the Rust bootstrap to get aarch64-linux back working[3]. In fact, the Rust part seems broken for both 6.10 and 6.11[4], but I decided to not bother since none of those are longterm versions. So all that's left here is to enable Rust for aarch64-linux because it clearly works[5]. [1] #315121 (comment) [2] https://lore.kernel.org/all/[email protected]/ [3] Of course I only realized this _after_ I spent some time hacking a rustc patch together 🙃 [4] This broke with error[E0463]: can't find crate for `core` | = note: the `aarch64-unknown-none` target may not be installed = help: consider downloading the target with `rustup target add aarch64-unknown-none` = help: consider building the standard library from source with `cargo build -Zbuild-std` [5] While the build is fine, the VM tests are still panicking, but that's also the case for `kernel-generic` because of a 9p regression: switch_root: can't execute '/nix/store/zv87gw0yxfsslq0mcc35a99k54da9a4z-nixos-system-machine-test/init': Exec format error [ 1.734997] Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000100 [ 1.736002] CPU: 0 UID: 0 PID: 1 Comm: switch_root Not tainted 6.12.0-rc1 #1-NixOS [...] Reported as https://lore.kernel.org/all/[email protected]/T/#u
dezren39
referenced
this pull request
in developing-today-forks/nixpkgs
Oct 14, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
At least until NixOS fully supports -fstack-protector it's better to turn it off
at the moment, as previous successful builds didn't include it either.