Arch Linux User Repository

Sorry guys, turns out I apparently screwed up merging the latest makepkg.conf pacnew.

@chrisjbillington: Thanks, I've applied the diff.

The problem seems to be that as of pacman 6.1, released earlier this month, Arch's default makepkg.conf has -Wp,-D_FORTIFY_SOURCE=3 in CFLAGS, and this conflicts with pyinstaller passing -D_FORTIFY_SOURCE=2.

To retain the stricter setting if it's set (which probably makes sense?), one might patch the pyinstaller bootloader build script:

fortify-source-fix.diff:

--- a/bootloader/wscript
+++ b/bootloader/wscript
@@ -518,7 +518,7 @@
             # manipulation functions.
             if ctx.options.debug:
                 ctx.env.append_value('CFLAGS', '-U_FORTIFY_SOURCE')
-            elif ctx.env.CC_NAME == 'gcc':
+            elif ctx.env.CC_NAME == 'gcc' and '-Wp,-D_FORTIFY_SOURCE=3' not in ctx.env['CFLAGS']:
                 # Undefine this macro if already defined by default to avoid "macro redefinition" errors.
                 ctx.env.append_value('CFLAGS', '-U_FORTIFY_SOURCE')

source=("$pkgname-$pkgver.tar.gz::https://github.com/pyinstaller/pyinstaller/archive/refs/tags/v$pkgver.tar.gz"
        fortify-source-fix.diff)
sha256sums=('0200fb8e27c284e5698a688aa904980b7a1692bc38daf6446bbae8f71b65dc2e'
            '46f7cfd082570a3f4c138a868e55dc39deacccbff602ce7e70d033236566fa1b')

prepare() {
  cd "$pkgname-$pkgver"

  # Force bootloader build for the current platform
  # and remove the unnecessary binaries
  rm -rvf PyInstaller/bootloader/{Darwin,Linux,Windows}*

  # Apply patch to bootloader build script to avoid redefining _FORTIFY_SOURCE if
  # default makepkg CFLAGS are used, which contain `-Wp,-D_FORTIFY_SOURCE=3`:
  patch -Np1 -i "${srcdir}/fortify-source-fix.diff"

}

makepkg succeeds for me after this change.

Perhaps there is a more sensible way, but I think at least this identifies the problem. Not sure why some others aren't seeing this problem, as I would have expected the default makepkg.conf to be used in a clean chroot.

It's failing for me in a chroot as well.

I haven't built AUR packages in chroots before, so I may not be doing it right, but I'm seeing the same problem when I build as below (script at the bottom of this comment). I'm on Arch on an x86-64 system, is there anything from my system that propagates into a chroot like this? I do have custom stuff in LD_PRELOAD, but I'm running the below script with LD_PRELOAD unset (and PATH set conservatively) just in case:

LD_PRELOAD= PATH=/usr/local/bin:/usr/bin:/usr/local/sbin ./build.sh

I think maybe most of the "errors" are irrelevant, since they correspond to other lines that are output when you run makepkg that appear to indicate success:

Setting top to                           : /build/pyinstaller/src/pyinstaller-6.5.0/bootloader
Setting out to                           : /build/pyinstaller/src/pyinstaller-6.5.0/bootloader/build
Python Version                           : 3.11.8 (main, Feb 12 2024, 14:50:05) [GCC 13.2.1 20230801]
MSVC target(s)                           : not found
Checking for 'gcc' (C compiler)          : /usr/bin/gcc
Checking size of pointer                 : 8
Platform                                 : Linux-64bit-intel detected based on compiler
Checking for compiler flags -m64         : yes
Checking for linker flags -m64           : yes
Checking for compiler flags -Wno-error=unused-but-set-variable : yes
Checking for library dl                                        : not found

I think it's might only the last one that is fatal:

Checking for library dl
==>

int main(int argc, char **argv) {
    (void)argc; (void)argv;
    return 0;
}

<==
[1/2] Compiling build/.conf_check_7f4bda2539af68cac4bfceb0cd41b238/test.c

['/usr/bin/gcc', '-march=x86-64', '-mtune=generic', '-O2', '-pipe', '-fno-plt', '-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=/build/pyinstaller/src=/usr/src/debug/pyinstaller', '-flto=auto', '-m64', '-O2', '-Wall', '-Werror', '-Wno-error=unused-variable', '-Wno-error=unused-function', '-Wno-error=unused-but-set-variable', '-U_FORTIFY_SOURCE', '-D_REENTRANT', '-D_BSD_SOURCE', '-D_DEFAULT_SOURCE', '-D_FORTIFY_SOURCE=2', '../test.c', '-c', '-o/build/pyinstaller/src/pyinstaller-6.5.0/bootloader/build/.conf_check_7f4bda2539af68cac4bfceb0cd41b238/testbuild/test.c.1.o']
err: <command-line>: error: "_FORTIFY_SOURCE" redefined [-Werror]
<command-line>: note: this is the location of the previous definition
cc1: all warnings being treated as errors

from /build/pyinstaller/src/pyinstaller-6.5.0/bootloader: Test does not build: Traceback (most recent call last):
  File "/build/pyinstaller/src/pyinstaller-6.5.0/bootloader/waflib/Configure.py", line 383, in run_build
    bld.compile()
  File "/build/pyinstaller/src/pyinstaller-6.5.0/bootloader/waflib/Build.py", line 191, in compile
    raise Errors.BuildError(self.producer.error)
waflib.Errors.BuildError: Build failed
 -> task in 'testprog' failed with exit status 1 (run with -v to display more information)

not found
from /build/pyinstaller/src/pyinstaller-6.5.0/bootloader: The configuration failed

libdl does exist:

$ arch-nspawn $CHROOT/root find /usr/ -name 'libdl.so*'
/usr/lib/libdl.so.2

Perhaps the error raised (_FORTIFY_SOURCE" redefined) when checking for libdl is causing that detection step to fail and be interpreted as libdl not being present?

Anyway, here's how I'm building in a chroot, let me know if I'm doing anything wrong:

#!/usr/bin/bash
set -euxo pipefail

mkdir build && cd build

# Make chroot
mkdir chroot
CHROOT=$PWD/chroot
mkarchroot $CHROOT/root base-devel
arch-nspawn $CHROOT/root pacman -Syu

# Clone AUR packages
git clone ssh://aur@aur.archlinux.org/pyinstaller.git
git clone ssh://aur@aur.archlinux.org/pyinstaller-hooks-contrib.git
git clone ssh://aur@aur.archlinux.org/python-altgraph.git

# Build deps:
cd pyinstaller-hooks-contrib
makechrootpkg -c -r $CHROOT
cd ..

cd python-altgraph
makechrootpkg -c -r $CHROOT
cd ..

# Build pyinstaller, passing packages for deps
cd pyinstaller
makechrootpkg -c -r $CHROOT \
  -I ../python-altgraph/*.pkg.tar.zst \
  -I ../pyinstaller-hooks-contrib/*.pkg.tar.zst
cd ..

Same issue today as chrisjbilliington, full output matches his. Attempted update from 6.5.0-1 -> 6.5.0-2 using yay on EndeavourOS.

In the bootloader build config.log I also have the same error (err: ../test.c) as well as two more a bit further down:

err: <command-line>: error: "_FORTIFY_SOURCE" redefined [-Werror]

and

line 191, in compile
    raise Errors.BuildError(self.producer.error)
waflib.Errors.BuildError: Build failed

@chrisjbillington: I just built it in a clean chroot with no issues. By the way, the precompiled bootloaders are removed purposely in order to compile it, so that first message is normal.

Build failing for me today, full output here:

https://gist.github.com/chrisjbillington/14ff939d18dfc970e7ef2a386f63e556

Key lines:

No precompiled bootloader found or compile forced. Trying to compile the bootloader for you ...

[...]

The configuration failed (complete log in /tmp/pyinstaller/src/pyinstaller-6.5.0/bootloader/build/config.log) ERROR: Failed compiling the bootloader. Please compile manually and rerun setup.py

This configuration step appears to involve compiling and running lots of C snippets to detect things about the environment. In the log file (config.log), there are a bunch of compile errors which are presumably the source of the problem, e.g.:

err: ../test.c: In function ‘main’: ../test.c:3:24: error: size of array ‘test_array’ is negative 3 | static int test_array[1 - 2 * !(sizeof(void *) == 4)]; | ^~

The sha256sum is wrong, for me it is:

0200fb8e27c284e5698a688aa904980b7a1692bc38daf6446bbae8f71b65dc2e pyinstaller-6.5.0.tar.gz

@HurricanePootis: I've limited it to only run the unit tests.

@yochanamrqos could you remove the check function from the package? Takes way too long

@samarthj: This has been out of date for months. Please add me as as Co-Maintainer if you would like help updating it in a timely manner. I was a previous Maintainer, but was no longer using it. I'm now using it again with my pixelflasher package.