Arch Linux 2024

[Grogan]

I found an article at Tom's complaining about the AVX-512 thing:
https://www.tomshardware.com/news/intel ... in-silicon

Intel's support for AVX-512 instructions with its Alder Lake processors has been a confusing affair. The company initially claimed the feature wouldn't work on its new 12th Gen processors and then backtracked when motherboard vendors found multiple workarounds to enable the commands. After a bit of cat and mouse with motherboard vendors that built new firmware to enable the feature despite Intel's attempts at disabling it, the company has finally decided to deploy the nuclear option and fuse off AVX-512 support entirely inside newer revisions of the Alder Lake chips.

The reason would be that they want you to buy a big expensive Xeon if you want 512 bit vector instructions, not that it wouldn't work on the cpu architecture as they claimed (vendors were turning it on with firmware lol) so they permanently sabotaged it on them going forward.

-------------------------------

Related, I found a cool awk script to determine which x86_64 sub arch levels are supported. I didn't need it (I can look myself and already knew that) but I like clever little scripts

Code: Select all

#!/usr/bin/awk -f

BEGIN {
    while (!/flags/) if (getline < "/proc/cpuinfo" != 1) exit 1
    if (/lm/&&/cmov/&&/cx8/&&/fpu/&&/fxsr/&&/mmx/&&/syscall/&&/sse2/) level = 1
    if (level == 1 && /cx16/&&/lahf/&&/popcnt/&&/sse4_1/&&/sse4_2/&&/ssse3/) level = 2
    if (level == 2 && /avx/&&/avx2/&&/bmi1/&&/bmi2/&&/f16c/&&/fma/&&/abm/&&/movbe/&&/xsave/) level = 3
    if (level == 3 && /avx512f/&&/avx512bw/&&/avx512cd/&&/avx512dq/&&/avx512vl/) level = 4
    if (level > 0) { print "CPU supports x86-64-v" level; exit level + 1 }
    exit 1
}

That would run if set executable, but I just did "awk -f filename" to run it.

Code: Select all

CPU supports x86-64-v3

[Grogan]

Fascinating stuff. A bootstrap LTO build of gcc isn't helped a lot by -j24 because it can't just go ahead and compile all the objects (I'd think a plain build could do more in parallel). OK, that's boring, but it gave me a chance to observe Turbo Boost behaviour on a workload where cores are idle. It can go up to 5.2 GHz under those conditions:

Code: Select all

[grogan@nicetry ~]$ cat /proc/cpuinfo | grep MHz
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 5143.098
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 3945.585
cpu MHz		: 3088.444
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000
cpu MHz		: 800.000

[Grogan]

Well, I can say the -march=alderlake wasn't good for some 32 bit parts of Wine (or at least in my Proton-TKG build... I also built a system wine 9.4 (TGK) that I haven't tested yet, I might not bother lol)

The Ubisoft client was crashing out on me, wouldn't start. I tried some other games and they were fine. I went back to my previous Proton-TKG (nehalem) and the Ubisoft client worked fine again.

Then I noticed that ubibooby was in c:\program files(x86) and tested another 32 bit game that was working just last night, and blammo.

So that wasn't such a good idea. I'm going to have to recompile that.

[Grogan]

That turned out to be only the 32 bit build of DXVK that broke on -march=alderlake. It was easier to isolate that with my system wine and DXVK for Lutris.

So I built my Proton-TKG with -march=alderlake everywhere but that, where I used "-march=nehalem -mtune=alderlake" (nehalem always has worked) and now the Ubisoft client in Steam works again too. That was a good clue, that the client was 32 bit (everything like that uses directx on windows at the back end... the embedded browsers generally use Angle which translates EGL to directx)

[Zema Bus]

Looks like I have a favorable revision of Alderlake

Code: Select all

CPU supports x86-64-v3

I haven't run any games on it yet but I'll be doing that soon. In all the gaming benchmarks I've seen the Ryzen 7 5800X3D (which is what I have in my other machine next to me) comes out on top of the 12900KF in most games probably mainly because of it's 96 MB L3 cache (the 12900KF comes out ahead of the Ryzen 9 5900X in the gaming benchmarks) but I want to test that myself with the same card.

[Zema Bus]

I did a new Arch install last night on my main machine, I did it "the Arch way". I ssh'd into it from my other machine so I could copy paste some stuff along the way. I didn't bother trying the script, it only works half the time. Initially I installed Mate as the only DE since it's compatible with other DE's including Plasma, and I'll be doing some gaming on this machine, I've found Mate to be pretty gaming friendly. I have more work to do on it today. I may do Slackware-Current today too, then once they're both the way I want them I'll nuke the old installs.

[Grogan]

Yeah, that's the best way to install Arch. It only takes maybe half an hour to get the base system up that way. It's easy to forget stuff if you get in a rush though. I didn't even look at the instructions for this install (I had just done one a few hours prior) and forgot to run localegen. Perl and a bunch of software were all complaining that my locale was invalid "fuck off, I set the variables". What I forgot was the actual en_US.utf8 locale. Two ways to fix that... simply reinstall the glibc package. It will generate a locale (it doesn't during the install, because that stuff is installed by pacstrap, not the package manager). Or, just install the glibc-locales package. What I did was just manually extract the glibc-locales package and copy the en_US.utf8 directory to /usr/lib/locale. Of course now I have my own glibc package and it installed the locale.

I find Arch pretty easy once the base system is up, with the package groups and dependencies pulling things in and all. (but if the Arch install is actually for me to use, I have a lot of shit I'd want to do)

[Grogan]

Well, everything is alive and well but I had trouble starting Arch, or so I thought. It was just going to a black screen with a blinking cursor (mode switching first, so I knew it was actually "booting" enough to load modules and firmware). I'm all WTF, because nothing should have changed. The nvme0 and nvme1 devices didn't shift. My LFS system started up fine (after I re-corrected the nvme0 vs nvme1 changes I didn't need to make) and didn't miss a beat.

What was ACTUALLY happening, was that I had it booting in "quiet" mode, and systemd was taking a 1:30 to time out on a start job, the network. (and I wasn't waiting a minute and a half, but aborting with ctrl-alt-del)

You see, that stupid "enp5s0" shit bit me in the ass again! I meant to change that all over to eth0, but it's a pain in the ass and it was working fine.

Removing the NVME drive from the PCI-E slot (M.2 adapter card) and installing it on the M.2 slot on the motherboard, shifted the device numbers on the PCI-E bus. Therefore, enp5s0 wasn't that anymore.

It took me a a while to remember all the places I have to change enp5s0 to eth0 (and mask out Arch's udev rule in /usr/lib/udev/rules.d and replace it with mine to change the device to eth0 which is the real kernel device anyway that gets mapped to the other)

But now, this will never happen to me again. What a dumb assed thing, that nomenclature. It's way easier to just change a MAC address if you change adapters or something than when bus device numbering changes.

[Grogan]

I forgot to install acpid, Arch doesn't install that itself. (should check... install and "systemctl enable acpid.service" if you don't have it)

I went to test a power button shutdown and it didn't work. I'm not sure why else I should care about acpid personally (I do want acpi power button shutdown to work for sure, it can save you from a bad shutdown if all that's screwed up are your input devices and display etc.) as I don't really use much power management, but xorg also complains in the log if it can't connect to the acpid socket, so it likes it for something. It doesn't seem necessary/mandatory for anything though.

[Zema Bus]

Just got it installed and running on both machines.

[Grogan]

I'm glad I noticed, then. (I wasn't sure if maybe some KDE power manager might have pulled that in for you or not)

The default should be to intercept and do a shutdown command, HOWEVER, I have seen "power managers" override that. XFCE power manager for one (I removed that, smeagol hates it)

Check in your desktop environment's control center to see if there are settings for any of that behaviour, if it has any kind of power manager. Disable if you can, or at least make sure the override is going to do the right thing. (I hate desktop environment power managers... The X server already does the right thing for the display in absence of such overrides and I don't want a DE messing with anything else)

I still think you should have acpid, despite that caution. I don't think a distro's acpid is configured to do much out of the box. For the power button purpose, that's something you'll probably need more when your graphical environment is dead in the water or something. Like, for example, if a game malfunctions and hurts your session in a bad way

[Grogan]

Heh... I went to install xpdf today and noticed that Arch links theirs against QT6. I don't want any of my software dependent on that (I don't have it installed) so I went to grab the PKGBUILD. There, I noticed they are applying part of a debianal patchset. Just the patch that wraps enforcement of document permissions around #ifdef's. Just that, not the part that actually defines ENFORCE_PERMISSIONS. At first I was all "WHAT? I want that about as much as diarrhoea in a spacesuit" but then I grepped for the definition in the source headers and stuff and there's nothing that's ever going to define it. So they are essentially disabling the enforcement if nothing sets it (the only behaviour in the program was, previously, to enforce it)

Anyway, for a QT5 build of xpdf I'm all good according to the CMake config files... I just have to not have QT6 installed (and change the deps in the PKBBUILD) and it will build against QT5, which I prefer and have configured the way I like it (non-kde).

[Grogan]

Arch has decided to change the default vm.max_map_count to 1048576 (which is far lower than my value lol)

If you have already set one, make sure it overrides the default in /usr/lib/sysctl.d. One would think that simply putting files in /etc/sysctl.d would do that, since it's the one that's processed first as overrides, but not so. The priority gets processed first regardless of the directory. Therefore, /usr/lib/sysctl.d/10-arch.conf would get processed after something 01-filename.conf. Unless the files are the same name, just having them in /etc/sysctl.d may not do what you want.

For example, I'm fine because I named my file where I put sysctl commands /etc/sysctl.d/99-swappiness.conf. It will get processed last because of the 99 and change whatever values that may be set in /usr/lib/sysctl conf files.

[Grogan]

I just got the "filesystem" package that made this change in /usr/lib/sysctl.d and I rebooted.

I can verify that it's not fucking with any of my values with the output of: (or I could pipe the results through grep etc.)

Code: Select all

[grogan@nicetry ~]$ sysctl -a
abi.vsyscall32 = 1
debug.exception-trace = 1
dev.hpet.max-user-freq = 64
dev.tty.ldisc_autoload = 1
dev.tty.legacy_tiocsti = 0
fs.aio-max-nr = 65536
fs.aio-nr = 0
fs.binfmt_misc.DOSWin = enabled
fs.binfmt_misc.DOSWin = interpreter /usr/bin/wine

.... snipping a long list of default values of kernel parameters...

vm.max_map_count = 2147483642
... snip...
vm.swappiness = 10
...snip

My directives are processed last in the /etc/sysctl.d/99-filename.conf

[Grogan]

I got around to getting my Trinity stuff working today. I had already copied it over (and the configs from grogan) but just had to set some environment variables and ldconfig paths (I have it in a non system location, /opt/trinity and /opt/tqt3 for its qt). It's one of those things where every time I thought to do it, the old PC wasn't powered on and "OK, next time" and I couldn't remember the variables offhand (TQTDIR and stuff).

So that means I have my preferred PDF viewer (the KDE 3 version of kpdf), my hex editor (khexedit) AND most importantly, my fat ladies solitaire game

trinitykpat.jpg (98.78 KiB) Viewed 98967 times

It's no problem to run these applications in other environments because as soon as the last thing closes, all the KDE daemons and shit go away.

[Grogan]

I just tried that "archinstall" script that's in the ISO's now.

It's pretty bad... anything other than just letting it take the disk "best guess partitioning layout" or some such wording, fails with a bunch of python errors, it doesn't look like it actually created the second partition and didn't format, and couldn't mount. I even created them beforehand with fdisk before running archinstall and all I did was go in to manual partitioning and assign the mount points. Still "missing superblock, wrong fs type, missing codepage..." some mount error occurred.

All it will do is use swap in zram, there are no facilities for creating and using a swap partition or any other kind of swap. That's got to be the most retarded spinning of wheels I've ever seen. Putting swap in ram mostly defeats the purpose of freeing up pages, and adds compression overhead to it if you actually use it. Write it out to swap on disk and forget about it. (most common use of swap nowadays is more likely to free up anonymous pages that didn't get freed when an application terminated)

So that's not really viable for Saturday either. I can't do that on a real system where I can't lose data.

It did let me choose grub though, not just systemd-boot.

So now I have nothing and I must pacman everything. But we'll get a better system up than that manjaroo poo here for testing a Linux guest with Plasma 6

[Grogan]

Oh, how fruity

(my nephew won't like this... lol)

fruityarch.jpg (190.97 KiB) Viewed 98717 times

[Zema Bus]

lol!

I'm surprised to hear Manjaro is still on Plasma 5. Slackware-Current is still on Plasma 5, but that's not surprising considering how long he stayed with Plasma 4

[Grogan]

Well, Slackware gets a pass for that stuff.

1) It's not piggybacking on Arch. Manjaro doesn't actually DO a lot, but build Arch packages. They have some of their own front ends (e.g. that MHWD) and do build some packages somewhat differently, but most of it is Arch. Their installer is just that Calamares thing, they didn't make it and they already have the pacman packaging system and dev environment already worked out.

2) Slackware is one man that stubbornly does everything himself. (I understand that... it's his project and he doesn't want to have to owe anybody. So he doesn't have to concede to them etc.)

The hoops he jumped through to adapt Slackware to Plasma 5... it took years for him to work that out and be OK with it (even though Alien Bob did much of the ground work, his big honking workarounds are fine for him, but it's still not appropriate to just blast into Slackware). I'm sorry to say it ruined Slackware though, it's now too complex of a system for its simplicity, turning it into an all-or-nothing monolith for most people. For me it's no longer worth fighting with to have things my way.

[Grogan]

Well, I've got a pretty versatile Ventoy boot stick now. It's the (fast, $100) Corsair 250 Gb one. I actually may give him Manjaro tomorrow, he won't know about Plasma 6 anyway and 5 was probably better anyway, I was just mad because it was 6 that I wanted to see. The installer may not crash when manual partitioning is selected on a different (or real) system. I'd also consider kubuntu for him, though I do not like that prospect. Buntardo is probably the one he'd get the most help/acknowledgement of. I don't think he cares too much about gaming on Linux at this time (not when he has a Windows setup) though I'd prefer to see him with a good environment for it. I'd also prefer to see him with a good dev environment (which Manjaroo does have) so he can realize what power that grants.

archlinux-2024.04.01-x86_64.iso
manjaro-kde-23.1.4-240406-linux66.iso
kubuntu-24.04-desktop-amd64.iso
Win11_23H2_English_x64v2.iso

I have room for maybe 1 more (~4Gb free)

I have an 18G partition for boot ISOs and the rest of the disk (except for a 32M EFI partition) is a 220G exfat for normal thumb drive use. It's the fastest sneakernet solution I've ever had (~400 Mb/sec under the right conditions)

[Zema Bus]

Plasma 6 is still not nearly as stable as Plasma 5 anyway, it often crashes when I merely click on a launcher. If he's not going to do any gaming on Linux then Debian may be a better option than Ubuntu. Debian is pretty good these days and with none of of the Ubuntu nonsense, though it will get crusty after a few years. But yeah he'd find more online help for Ubuntu.

I overlooked your earlier post - yeah the Arch install script only seems to work about 40% of the time. I didn't even bother with it for my current Arch install, I just did it "the Arch way" via ssh from my other machine.

[Grogan]

I haven't had any crashy behaviour with Plasma 6 yet, but if I set Autohide on the panel, it goes away and never comes back. I see a bit of that faint glow effect (one of the compositor desktop effects) at the bottom screen edge but the panel is off screen and can't be actuated. I can turn off that panel float (that looks stupid) but can't use autohide. The only way to get at the panel controls is by right clicking on the panel, too ("edit mode"). I have to delete plasmashellrc to get it back. That's a piss poor disconnect, right there.

Hell no, the things that archinstall script does would not be happening on my machine (or any real one for that matter). I was just looking for a shortcut (mostly for my nephew's system), but it's not viable. Too inflexible and the partitioning facility is retarded (less user friendly than fdisk too lol!) even if it doesn't bomb out. At least it allows grub now though, it used to only set up systemd-boot. It DID serve the purpose of getting an arch install up quickly in a VM to play with Plasma though.

The safest way to partition, when you don't want to lose data, is manually with fdisk while knowing what you're doing. With fuzzy things like those partitioning wizards in installers, knowing shit won't necessarily help you when they fail to do what you intend. Things like the Ubuntu desktop installer force you to install a boot loader too (though there is still a text based installer I think)

I'm leaning heavily towards stopping at a computer store and buying him a SATA SSD for Linux. He's intending to put it on his mechanical storage drive. I won't have to touch any others that way, he can just go into the bios and change boot drives or use the boot override. I hate to spend more money, but I also hate doing work lol

[Grogan]

Yep... I found a 1 TB Verbatim SSD (SATA) for $99 which isn't bad for hopping in the car and going to a local shop. They had Kingston too, but they can fuck off forever for their self destructing firmware. I wouldn't trust them for a $10 thumb drive. They make crap RAM too.

That will be more practical than carving out space on his mechanical storage drive and I'm not going to have to touch his other drives at all this way (it'll have its own EFI boot partition)

[Grogan]

So they've definitely changed the way the globbing works with wildcards in pacman's IgnorePkg directives. What used to work for me doesn't anymore.

For example, if I ignore gcc as gcc* it doesn't match package name gcc itself, only gcc-libs. If there is nothing after the wildcard, it doesn't match. That's fucking stupid. Similarly, if I say *foo it would only match something-foo, not foo itself.

P.S. This is how globbing is expected to work, for example. (purpose of me doing it like that is to exclude glibc-locales which I build but don't install... that command is going to be pacman -U next)

Code: Select all

[nicetry build]# ls *glibc-2.39*.pkg.tar.zst
glibc-2.39-2-x86_64.pkg.tar.zst  lib32-glibc-2.39-2-x86_64.pkg.tar.zst

----------------------------------------------------------------------------------

By the way, the implications of something just occurred to me. I happened to glance at that March 5 announcement you screenshotted for me and noticed that now CPU microcode is being built right into Arch's initramfs images. I breezed right by that because I don't do initrd's. That means you're getting CPU microcode whether you like it or not (unless you hack the mkinitcpio hook templates or whatever they call them, I suppose). It wasn't relevant at the time (picture a vampire hunter holding a crucifix with an outstretched hand... I hate initrd's) but now I have to build a kernel in that Arch VM, thinking about this, to maximize performance. You configure vcpus in different socket/core/thread configurations, but unless you have some other purpose, you're going to be using passthrough for your CPU type.

Not only the spectre and friends, but things like disabling TSX by default unless the kernel detects a CPU known to be not vulnerable to side-channel timing tomfoolery or disabling it altogether, I couldn't say. Some microcode updates will outright disable it on some CPUs too (e.g. skylake, coffeelake) as the only "mitigation".

I'll have to check what Manjaro is doing with their mkinitcpio routines (I'd be surprised if they weren't following Arch on that). I should build Mr. Nephew a groganized kernel anyway. (if for no other reason than device enumeration stability... I hate having to use UUIDs for drives and a bunch of stupid udev rules)

[Grogan]

Hah... I upgraded to gcc 14.1.0 today (ahead of Arch). I noted some more new things that used to be warnings are errors now (and some new warnings that are errors). I'm thinking I don't build much old code these days and I can work around it if I do.

-Werror=int-conversion
-Werror=implicit-function-declaration
-Werror=implicit-int
-Werror=incompatible-pointer-types
-Werror=return-mismatch
-Werror=declaration-missing-parameter-type

Didn't I hit two of those on the first thing I went to build with it. (Well, other than bootstrapping toolchains)

Code: Select all

winIVROverlay.c: In function ‘winIVROverlay_IVROverlay_001_SetOverlayTexture’:
winIVROverlay.c:270:47: error: passing argument 1 of ‘ivroverlay_001_set_overlay_texture’ from incompatible pointer type [-Wincompatible-pointer-types]

winIVRMailbox.c:48:12: error: implicit declaration of function ‘ivrmailbox_undoc3’ [-Wimplicit-function-declaration]

That's the OpenVR client in a Proton build. I'm either going to have to pass -Wno-error=those things (I don't think -Wno-error itself stops such sabotage) or skip around building the VR client, which I don't use anyway (but could cause the scripts to fail later in the build if it's not there or something)

Implicit function declaration turned into an error is going to break a lot of builds.

P.S. It was more than just the VR Client, I had to add -Wno-error=incompatible-pointer-types -Wno-error=implicit-function-declaration for other parts of the build too, or it causes an error that doesn't fail the build (script keeps going and skips that). I watched the whole build to make sure I didn't need to override those errors anywhere else.

[Grogan]

So yesterday, I noticed Arch was starting to override package names with git revision using the pkgver() function. I noticed this while merging my changes into the latest glibc PKGBUILD (new yesterday). That's ugly, but it solves the problem I've been complaining about where all they do is bump the pkgrel when they take a different commit.

Too bad I didn't wait one more day, my package versions would have matched. That's going to happen a lot now, because they pick new commits willy nilly.

I thought Arch was going to be a while with gcc 14.1 but they jumped the gun. That's kind of nasty, because I very, very much doubt that the whole distro will compile without overriding some of those new -Werror conditions (especially implicit function declaration, that's been accepted with warning for so long). That's what gcc does, first deprecate, then turn warning into error, then permanent error. It's not only gcc, but Clang is doing similar things, turning similar conditions into errors now. Eventually compilers aren't going to accept that code.

Code: Select all

warning: binutils: ignoring package upgrade (2.42-3 => 2.42+r91+g6224493e457-1)
warning: gcc: ignoring package upgrade (14.1.0-1 => 14.1.1+r1+g43b730b9134-1)
warning: gcc-libs: ignoring package upgrade (14.1.0-1 => 14.1.1+r1+g43b730b9134-1)
warning: glibc: ignoring package upgrade (2.39+r31+g31da30f23c-1 => 2.39+r52+gf8e4623421-1)
warning: lib32-gcc-libs: ignoring package upgrade (14.1.0-1 => 14.1.1+r1+g43b730b9134-1)
warning: lib32-glibc: ignoring package upgrade (2.39+r31+g31da30f23c-1 => 2.39+r52+gf8e4623421-1)
warning: libgccjit: ignoring package upgrade (14.1.0-1 => 14.1.1+r1+g43b730b9134-1)
warning: linux-api-headers: local (6.8.8-1) is newer than core (6.8-1)
warning: lto-dump: ignoring package upgrade (14.1.0-1 => 14.1.1+r1+g43b730b9134-1)

I checked out a stable commit for gcc yesterday, their new checkout is not really 14.1.1 that's just a version bump because it's a new branch. I'm good for now, I just bootstrapped all that yesterday. My LLVM and Rust too.

[Grogan]

Wow, upstream Wine is rife with incompatible pointer types and implicit function declarations. Worse, is that my CFLAGS are being overridden in Makefile.in templates. I've patched a few (it's a pain in the ass to make changes like that in a PKGBUILD) but now I have to do it in dlls/win32u. That's the w's so maybe that'll be it now lol

It's 4 patches now (including patching the configure script as I always do), so when I'm sure I'm done, I'll just edit all the files I need and make a recursive patch (using renamed directories)

I thought it would just be Valve's fork (Wine 9.0 and their vrclient etc.) but it appears Wine 9.9 has that poo too and because of the way it builds (v.s. the proton-tkg scripting I use when I build my Proton with Valve sources) it's overriding a UNIX_CFLAGS variable in Makefiles that aren't generated yet. In this specific case (win32u) it's as stupid as this (so I can't even fix this shit globally because it's setting the UNIX_CFLAGS variable differently in those directories)

Code: Select all

UNIX_CFLAGS  = $(FREETYPE_CFLAGS) $(FONTCONFIG_CFLAGS)

Umm, no... -Wno-incompatible-pointer-types and -Wno-implicit-function-declaration are not in my Freetype and Fontconfig CFLAGS (likely obtained from PKG_CONFIG .pc files)

After all this, I'm probably going to find that I can't even use this Wine build (since Wine 9.6, EA activation, ActivationUI.exe just hangs and the games won't start. It was still broken with Wine 9.8) but I refuse to let compiler flags stop me from completing a build.

[Grogan]

Alright, I'll document this in case some other poor sod in the same boat finds it

First of all, In my PKGBUILD I first unset my flags because I don't want to use the ones in makepkg.conf for wine builds

It's only relevant for C, as C++ wouldn't allow that nonsense anyway, period (though it will take those switches without complaining). On a vanilla wine there probably isn't any C++ code but I've got some in my build (fsync patchset). The rest of this would be applicable (though the directory won't be named wine-tkg)

Code: Select all

prepare() {
  unset CFLAGS
  unset CXXFLAGS
  export CFLAGS="-O2 -march=alderlake -Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types"
  export CXXFLAGS="-O2 -march=alderlake"
  unset LDFLAGS

# add my CFLAGS where needed
  patch -Np0 -i "$srcdir"/cflags.patch
... 

I don't recommend anybody use -march, I just left it in as an example. I know that works for me, with Wine, I'm not hitting any breakage (and I'd try a build without if I did) but that's no so for all parts of the compatibility layer. For example, building those dlls likely get that overridden, and other builds like dxvk and vkd3d-proton will have subtly broken results. (not part of this build, but a related example)

These are the places where I added -Wno-error in my patch (at least the only places where I really need it to be)

There's no configure.in, only configure.ac which gets variables like that from other macros when autoconf is run, so it's easier to just patch configure, which is fine for just changing some variables.

Code: Select all

--- wine-tkg_orig/configure	2024-05-18 12:02:27.000000000 -0400
+++ wine-tkg/configure	2024-05-18 14:21:30.564730520 -0400
@@ -25304,7 +25304,7 @@
 arm64ec_DELAYLOADFLAG = $arm64ec_DELAYLOADFLAG
 arm64ec_DISABLED_SUBDIRS = $arm64ec_DISABLED_SUBDIRS
 i386_CC = $i386_CC
-i386_CFLAGS = $i386_CFLAGS
+i386_CFLAGS = $i386_CFLAGS -march=alderlake -Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types
 i386_EXTRACFLAGS = $i386_EXTRACFLAGS
 i386_LDFLAGS = $i386_LDFLAGS
 i386_DEBUG = $i386_DEBUG
@@ -25312,7 +25312,7 @@
 i386_DELAYLOADFLAG = $i386_DELAYLOADFLAG
 i386_DISABLED_SUBDIRS = $i386_DISABLED_SUBDIRS
 x86_64_CC = $x86_64_CC
-x86_64_CFLAGS = $x86_64_CFLAGS
+x86_64_CFLAGS = $x86_64_CFLAGS -march=alderlake -Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types
 x86_64_EXTRACFLAGS = $x86_64_EXTRACFLAGS
 x86_64_LDFLAGS = $x86_64_LDFLAGS
 x86_64_DEBUG = $x86_64_DEBUG
diff -Naur wine-tkg_orig/dlls/ntdll/Makefile.in wine-tkg/dlls/ntdll/Makefile.in
--- wine-tkg_orig/dlls/ntdll/Makefile.in	2024-05-18 12:02:28.000000000 -0400
+++ wine-tkg/dlls/ntdll/Makefile.in	2024-05-18 14:23:53.244737487 -0400
@@ -3,7 +3,7 @@
 UNIXLIB   = ntdll.so
 IMPORTLIB = ntdll
 IMPORTS   = $(MUSL_PE_LIBS) winecrt0
-UNIX_CFLAGS  = $(UNWIND_CFLAGS)
+UNIX_CFLAGS  = $(UNWIND_CFLAGS) -Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types
 UNIX_LIBS    = $(IOKIT_LIBS) $(COREFOUNDATION_LIBS) $(CORESERVICES_LIBS) $(RT_LIBS) $(PTHREAD_LIBS) $(UNWIND_LIBS) $(I386_LIBS) $(PROCSTAT_LIBS) -lm
 
 EXTRADLLFLAGS = -nodefaultlibs
diff -Naur wine-tkg_orig/dlls/win32u/Makefile.in wine-tkg/dlls/win32u/Makefile.in
--- wine-tkg_orig/dlls/win32u/Makefile.in	2024-05-18 12:02:28.000000000 -0400
+++ wine-tkg/dlls/win32u/Makefile.in	2024-05-18 14:24:36.805739614 -0400
@@ -3,7 +3,7 @@
 UNIXLIB   = win32u.so
 IMPORTLIB = win32u
 IMPORTS   = ntdll winecrt0
-UNIX_CFLAGS  = $(FREETYPE_CFLAGS) $(FONTCONFIG_CFLAGS)
+UNIX_CFLAGS  = $(FREETYPE_CFLAGS) $(FONTCONFIG_CFLAGS) -Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types
 UNIX_LIBS    = $(CARBON_LIBS) $(APPKIT_LIBS) $(PTHREAD_LIBS) -lm
 
 EXTRADLLFLAGS = -nodefaultlibs

Look at the paths and the + and - lines (don't apply this patch and again, don't use -march )

To summarize:

Add -Wno-error=implicit-function-declaration -Wno-error=incompatible-pointer-types to wherever you are setting your CFLAGS (e.g. override in PKGBUILD or by setting variables)
Edit i386_CFLAGS and x86_64_CFLAGS in the configure script in the top level source dir
Edit UNIX_CFLAGS in dlls/ntdll/Makefile.in
Edit UNIX_CFLAGS in dlls/win32u/Makefile.in

[Grogan]

oof... the other computer. I haven't updated it in 3+ months, because I'd have to upgrade glibc, gcc (libstdc++) and a lot of other stuff that I took over. I needed it to just work, for accessing NFS shares etc. while transitioning but I'm done with that for now (until I need something else I forgot about) and seldom start that system. So it's time to fix it up.

So I have to go back to distro packages for all that stuff now (except a few things) as I don't want to compile much on there anymore (kernel and a few things like mesa, media players, window managers etc. will be all). This has a good chance of breaking some existing things, as I have compiled things with different linker flags, hardening technologies that can break if something else is compiled with/without it (e.g. CET).

603 packages... looks like it just finished, finally (I had file conflicts to resolve)

Time to reboot and assess damages...

[Grogan]

Since I'm not gaming anymore on this computer (and hence, will not have focus problems with games) I'm back to my beloved TDE now. The last time that (and TQT3) was recompiled was around 2 years ago (and it still runs transplanted on the new computer) as parts of it got subtly broken once on Arch. I could upgrade it, but I've learned that when you're happy with something old, and it still compiles, use the same sources (and don't try to recompile it again unless there's a reason because it might be a pain in the ass)

It sure is nice to be using this, with my all black, rounded Keramik style and all. Beautiful big panel and desktop pager (I use a 2x2 square configuration)