Arch Linux User Repository

@graysky,

Thanks for pointing out my non-Arch standard settings and I forgot there was a new /etc/makepkg.conf.pacnew hanging about. I'm back to standard now.

I see you removed 'subarch 27' from PKGBUILD, and now as expected, linux-ck-4.20.3-1-x86_64.pkg.tar.xz and its headers build without issue.

@air-g4p - As well, your CFLAGS are not the Arch standard... drop -fstack-protector-strong per the new makepkg.conf in pacman-5.1.2-2.

@air-g4p - See the comments in the PKGBUILD and the discussion here in the AUR.

<h1>Note - the march=native option is unavailable by this method, use the nconfig and manually select it.</h1>

In short, I do not know how to allow the native option to get set via the method used for the other discretely defined options.

@graysky,

I'm running an i7 8550U.

Under both /etc/makepkg.conf and ~/chroot/root/etc/makepkg.conf, I have these identical settings:

ARCHITECTURE, COMPILE FLAGS

CARCH="x86_64" CHOST="x86_64-pc-linux-gnu"

-- Compiler and Linker Flags

CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=native -O2 -pipe -fstack-protector-strong -fno-plt" CXXFLAGS="-march=native -O2 -pipe -fstack-protector-strong -fno-plt" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now"

-- Make Flags: change this for DistCC/SMP systems

MAKEFLAGS="-j8"

-- Debugging flags

DEBUG_CFLAGS="-g -fvar-tracking-assignments" DEBUG_CXXFLAGS="-g -fvar-tracking-assignments"

Is there anything you see in my setup that would drive:

'The build fails with hundreds of instances of:

Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW) 27'

that I mentioned when '_subarch=27' is set?

I normally build linux-ck in a clean chroot without issue, but this infinite loop issue disturbs me.

I remember looking at this a while ago and concluding it isn't possible... prove me wrong :)

Hi graysky,

I can confirm the build loop issue zoopp mentioned last month is still present in linux-ck 4.20.1-1.

With this PKGBUILD option set:

27. Native optimizations autodetected by GCC (MNATIVE)

_subarch=27

The build fails with hundreds of instances of:

Support for P6_NOPs on Intel chips (X86_P6_NOP) [N/y/?] (NEW) 27

It appears to me that the only way out of this loop is crtl-c.

Of course, the build proceeds normally with any other appropriate subarch assigned.

@artafinde - ck1 disables NUMA

@vltr: try enabling NUMA on ck.

@marceliq ohhh ... I haven't seen that. And that's actually a real bummer :(

In patch-4.20-ck1 there is:

@@ -896,6 +913,7 @@ config CGROUP_DEVICE

 config CGROUP_CPUACCT
        bool "Simple CPU accounting controller"
+       depends on !SCHED_MUQSS
        help
          Provides a simple controller for monitoring the
          total CPU consumed by the tasks in a cgroup.

which disable CPUACCT if SCHED_MUQSS is enabled :(