Implement Arch Linux RFCs 17, 23, and 26

See archlinux/rfcs!17 (merged), archlinux/rfcs!23 (merged), and archlinux/rfcs!26 (merged) respectively.

See also archlinux/devtools!191 (merged) (RFC 17), archlinux/devtools!188 (merged) (RFC 23), and archlinux/devtools!229 (merged) (RFC 26) for (status of) equivalent changes to devtools’ makepkg.conf files.

added priority3-normal statusunconfirmed labels

assigned to @foxboron and @anthraxx

changed the description

The RFC 26 mentions to add a flag for Rust:

For rust, the equivalent compilation flag we'll enable is -Cforce-frame-pointers=yes.

Is it normal that the implementation is not adding it ?

added 1 commit

• 2c037ab0 - RFC 26: Add no-omit-frame-pointer flags by default

Compare with previous version

resolved all threads

Thanks, however please note that we'll try and mirror the devtools makepkg.conf so the FORTIFY_SOURCE change might have to be removed depending on the status of the todo :)

added 4 commits

• 3c4480fe - 1 commit from branch archlinux/packaging/packages:main
• 71d2dd10 - RFC 17: Increase _FORTIFY_SOURCE level to 3
• 0f10f032 - RFC 23: Add -Wl,-z,pack-relative-relocs
• a84bd5de - RFC 26: Add no-omit-frame-pointer flags by default

Compare with previous version

approved this merge request

mentioned in merge request !8 (closed)

resolved all threads

mentioned in merge request !7 (closed)

merged

Thanks! Sorry for the delay :)

resolved all threads

I'm getting this error when I try building xorg-server-git with this change

xserver/meson.build:1:0: ERROR: Unable to detect linker for compiler `cc -Wl,--version -Wl,-O1, --sort-common,--as-needed,-z,relro,-z,pack-relative-relocs -flto=auto -march=x86-64 -mtune=generic -O2 -pipe -fexceptions -Wp,-D_FORTIFY_SOURCE=3 -Wformat -Werror=format-security -fstack-clash-protection -fcf-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -g -ffile-prefix-map=/home/anon/.cache/aurutils/sync/xorg-server-git/src=/usr/src/debug/xorg-server-git -flto=auto`
stdout: 
stderr: cc: error: unrecognized command-line option ‘--sort-common,--as-needed,-z,relro,-z,pack-relative-relocs’

It does work if I edit the LDFLAGS into LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now,-z,pack-relative-relocs"

This appears to break the build of kodi-git (https://aur.archlinux.org/packages/kodi-git) for me. No adjustments to LDFLAGS short of removing pack-relative-relocs works for me, it breaks the cmake FindThreads:

CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
  /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:600 (_FPHSA_FAILURE_MESSAGE)
  /usr/share/cmake/Modules/FindThreads.cmake:226 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
  CMakeLists.txt:166 (find_package)

The interesting thing here is that it only happens under makepkg; if I source /etc/makepkg.conf and manually run cmake, it works fine.

Is this some kind of path/security related issue with makepkg, is the flag somehow breaking something (but how when it works from the shell with the same flags?), or an issue with Kodi's cmakelists?

For now I'm having to do this in the build...but I don't understand why this would break the FindThreads cmake test...especially when it works with the same flags outside of makepkg.

  # makepkg is breaking the -Wl,-z,pack-relative-relocs ldflag for cmake's FindThreads
  export LDFLAGS=$(echo "$LDFLAGS" | sed 's/-Wl,-z,pack-relative-relocs//g')

Apparently ld.gold is known to break with these flags, so we also disable them for some projects which use this linker AFAIK.

Ah, good to know, though the fact that setting it to OFF has no effect within the PKGBUILD. I also find it VERY strange that I can do it manually without trouble...so something odd within the makepkg environment may be to blame...but since it doesn't really have any changes other than on potential binary size, it may not matter anyway.

This apparently also breaks some Haskell packages with autoconf'd C components (so eg pandoc-static-git breaks because network won't build). In particular, PKGBUILDs that call stack build without first calling stack setup (eg graphmod-git) fail if the particular GHC they pull in is not installed.

In this last case, for which I have better evidence, I've found that the problem arises from running autotools' ./configure with an LDFLAGS containing -Wl,-z,pack-relative-relocs -- it fails at checking size of void *... 0.

Thinking this was an upstream stack problem, I reported it there stack#6525, logs and reproductions can be found there if necessary.

I have also raised this with GHC upstream, hopefully there will be progress from some direction on this.

A valid temporary potentially permanent workaround that allowed me to build kodi, this should also help with haskell?

export LDFLAGS=$(echo "$LDFLAGS" | sed 's/-Wl,-z,pack-relative-relocs//g')

That works, though the workaround I went with (considering the bug is usually tripped up by the libraries pulled in by stack rather than the packages themselves) is to add stack setup && stack build --dependencies-only to prepare(). It doesn't have LDFLAGS set as exportable, so the dependency builds go through without issue.

I haven't updated the packages I maintain with this hack yet. I'm still clinging to the hope that either makepkg.conf gets updated to a more correct situation or that the Haskell ecosystem will become more defensive as to LD configuration (there's already some motion towards this with https://gitlab.haskell.org/ghc/ghc/-/merge_requests/12282, hopefully it will fix things enough for the other usecases)

mentioned in issue #21