Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

6.10.0 - Odd Compile Errors Under LLVM18 #1001

Open
ThisNekoGuy opened this issue Sep 13, 2024 · 5 comments
Open

6.10.0 - Odd Compile Errors Under LLVM18 #1001

ThisNekoGuy opened this issue Sep 13, 2024 · 5 comments

Comments

@ThisNekoGuy
Copy link

ThisNekoGuy commented Sep 13, 2024

Describe the Bug:

  • OS: Gentoo (LLVM18-built)
  • Running Kernel: 6.10.9-tkg-eevdf-gentoo-llvm18-generic_v3
  • Logs.zip

Description:
Yesterday, I compiled version 6.10.9 and installed it just fine. Today, with the same patches, same compile options, and same configuration (I touched nothing except changing the kernel version number to 6.10.10), I get 20 errors now when attempting to compile. Even if I switch the kernel version back to 6.10.9, set the config fragment to pick up the running tkg kernel, rm -rf the kernel git repo, and git pull the linux-tkg repo.

I've got absolutely no idea what suddenly changed overnight for LLVM to suddenly claim that there are 20 uses of "undeclared identifiers".

User Patch Sources:
For clarification on what user patches were used, it was primarily Gentoo's official patches:

(I also wrote a script for grabbing them, since they're hassle to grab individually)

Quick Downloader:
#!/bin/bash

# Get the script path
SCRIPT_DIR="$0"

# Check if the path is relative and convert it to absolute
if [ "$(printf "%s" "${SCRIPT_DIR}" | cut -c 1)" = "/" ]; then
    # Absolute path; trim any potentially trailing filename name off
    SCRIPT_DIR="$(echo "${SCRIPT_DIR}" | xargs -I [] dirname [])"
else
    # Relative path, convert to absolute
    abs_script_path="${PWD}/${SCRIPT_DIR}"
    # Extract the directory; second step is necessary to remove a trailing '.'
    SCRIPT_DIR="$(dirname "${abs_script_path}")"
    SCRIPT_DIR=$(echo "${SCRIPT_DIR}" | xargs -I [] dirname [])
fi

DOWNLOADER=""
if [ -x /usr/bin/wget2 ]; then
    DOWNLOADER="wget2"
else
    DOWNLOADER="wget"
fi

# Function to download a single file
download_patch() {
    local url="${1}"
    local filename="${url##*/}"
    local new_extension=".mypatch"  # Change this to your desired extension

    # Remove the existing .patch extension and add the new one
    local new_filename="${filename%.patch}${new_extension}"

    echo "Downloading ${new_filename}..."

    ${DOWNLOADER} "$url" -O "${SCRIPT_DIR}/${new_filename}" || return
}

# KERNEL_VERSION=$(basename "${SCRIPT_DIR}" | cut -f 1 -d 'x' --complement | cut -f 1 -d '-')
# if [ -n ${KERNEL_VERSION} ] && [ ${KERNEL_VERSION} -gt 0 ]; then
#     ## TODO
#     # Problem: linux-tkg userpatch subfolders are named like '610'; which is an issue for determining the currect major and minor version dynamically on a per-folder basis
#     # and changing the genpatches URL to follow suit.
#     # The current method is just to copy this script to the respective folder and change the values here to match.
# fi

# Capture URLs into an array
# shellcheck disable=SC2207
# shellcheck disable=SC1001
patch_names=($(${DOWNLOADER} -O - https://dev.gentoo.org/~mpagano/genpatches/trunk/6.10/ | grep img | grep href | grep \.patch | grep \: | grep -v -E "[A-Za-z0-9]+\\.[A-Za-z0-9]+\\.[A-Za-z0-9]+\\.patch" | cut -f 1 -d '>' --complement | cut -f 1 -d '"' --complement | cut -f 1 -d '"'))

# Download each file
for patch in "${patch_names[@]}"; do
    download_patch "https://dev.gentoo.org/~mpagano/genpatches/trunk/6.10/${patch}" || return
done

printf "/nDone!"

for patch in "${SCRIPT_DIR}"/*; do
    case "${patch}" in
        *"_enable-cpu-optimizations-universal.mypatch"|*"_BMQ-and-PDS-"*".mypatch")
            rm "${patch}" || return
            ;;
        *)
            :
            ;;
    esac
done

And just a few of CachyOS's:

Regardless, though, I can't imagine what could be causing this if nothing changed between yesterday and today.
I didn't even run a system update, either.

@AdelKS
Copy link
Collaborator

AdelKS commented Sep 29, 2024

Have you tried without any user patches just to confirm ?

@Tk-Glitch
Copy link
Member

The only thing that comes to mind is Graysky2's cpu opt patch. Since it's external to this repo it gets updated outside of our control and stuff might change/break. There were pretty large changes recently regarding that patch. First about 3 weeks ago, when the issue happened, then up to last week where it seemingly stabilized. Did it get fixed along the way @ThisNekoGuy ?

@ThisNekoGuy
Copy link
Author

I haven't checked yet, but I can try again tomorrow @Tk-Glitch

@ThisNekoGuy
Copy link
Author

ThisNekoGuy commented Oct 11, 2024

@Tk-Glitch Sorry, I think I had responded when I was half-asleep before and I forgot;
I'm building 6.10.13 right now with the same configuration (did have to update the generic_v3 value to match the new config file update handling that) and it seems to be going fine... mostly:

. . .
LD [M]  drivers/gpu/drm/amd/amdgpu/amdgpu.o
  AR      drivers/gpu/built-in.a
  AR      drivers/built-in.a
  AR      built-in.a
  AR      vmlinux.a
  GEN     .tmp_remove-ctf.lds
ld.lld: error: no input files
  LD      vmlinux.o
  OBJCOPY modules.builtin.modinfo
  GEN     modules.builtin
  GEN     modules.builtin.objs
  MODPOST Module.symvers
  CC      .vmlinux.export.o
  UPD     include/generated/utsversion.h
  CC      init/version-timestamp.o
  KSYMS   .tmp_vmlinux0.kallsyms.S
  AS      .tmp_vmlinux0.kallsyms.o
  LD      .tmp_vmlinux1
  BTF     .tmp_vmlinux1.btf.o
  NM      .tmp_vmlinux1.syms
  KSYMS   .tmp_vmlinux1.kallsyms.S
  AS      .tmp_vmlinux1.kallsyms.o
  LD      .tmp_vmlinux2
  NM      .tmp_vmlinux2.syms
  KSYMS   .tmp_vmlinux2.kallsyms.S
  AS      .tmp_vmlinux2.kallsyms.o
  LD      vmlinux
  BTFIDS  vmlinux
  NM      System.map
  SORTTAB vmlinux
  RELOCS  arch/x86/boot/compressed/vmlinux.relocs
  RSTRIP  vmlinux

The errors from before aren't an issue anymore, but I did get an lld error for some reason?
The build continues, regardless, for some reason which surprises me because I would have expected a kernel linkage error to just halt compilation... Though, I'm not sure if I should use the kernel if it failed to link?

@Tk-Glitch
Copy link
Member

Strange that it didn't stop, indeed 🤔 And the error itself is also weird.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants