# binutils:2.31 amd64 corrupted my 4.14 kernels [solved]

## CaptainBlood

I've just recompiled a couple of 4.14 amd64 stable kernels

None of them don't boot anymore, messaging:

Alignment of LOAD segment isn't multiple of 2 MB

-- System halted

Am I the only one?

Thks 4 ur attention.Last edited by CaptainBlood on Tue Apr 30, 2019 4:52 pm; edited 2 times in total

----------

## DaggyStyle

 *CaptainBlood wrote:*   

> I've just recompiled a couple of 4.14 amd64 stable kernels
> 
> None of them don't boot anymore, messaging:
> 
> Alignment of LOAD segment isn't multiple of 2 MB
> ...

 

try defconfig from scratch, see if they boot.

----------

## toralf

maybe a newer elfutils foolished you? elfutils was unstabled again in the mean while.

Don't forget "make clean".

----------

## CaptainBlood

Worked around my masking sys-devel/binutils:2.31,

As a side note, binutils:2.31 forced USE="gold plugins".

May be related.

gcc:8.3 is bind to be gold ready, altough not using it for quite a while now.

'make clean' seems reasonable enough as a first step, defconfig if previous failed.

Thks 4 ur attention, interest & support.

----------

## Duncan Mac Leod

Today I had another problem with binutils 2.31 on amd64.

First I compiled/upgraded to glibc 2.28-r5, then I want to compile binutils, noticing these new gold flags.

During compilation I tried to figure out their meaning. After the successful compilation of binutils 2.31.1-r4 I noticed that binutils is not listed as stable any longer on the package-site https://packages.gentoo.org/packages/sys-devel/binutils, but portage listed them as stable.

So I unmerged 2.31.1-r4 and recompiled 2.30-r4 - so far, so good.

Now, I recompiled gcc 6.4.0-r1, BUT gcc compiling FAILED. Very strange!

So, I decided to set my Gentoo system back before the first emerge of glibc (I am using Gentoo in a VM). Lost 2 hours and I am wondering why these packages went into stable tree?

----------

## Anon-E-moose

I've not had a problem with binutils-2.31 ... yet. But I didn't do the upgrade to glibc-2.28, I've stayed with glibc-2.27.

as far as the gold flag, binutils 2.30 also set it internally in the ebuild, it just didn't have a USE flag, not sure if plugins was set though.

----------

## CaptainBlood

Neither 

```
make clean
```

 nor 

```
make defconfig
```

 solved the issue.

Here's

```
sys-libs/glibc-2.28-r5
```

.

Thks 4 ur attention, interest é support.Last edited by CaptainBlood on Sun Apr 07, 2019 2:46 am; edited 2 times in total

----------

## Anon-E-moose

Were there any warning messages when compiling the kernel?

----------

## CaptainBlood

 *Anon-E-moose wrote:*   

> Were there any warning messages when compiling the kernel?

 

No warning at all...

Thks 4 ur attention, interest & support

----------

## Anon-E-moose

I see this morning they downgraded elfutils, from 0.176 (was stable, now marked ~) back to 0.170-r1. Might have something to do with the problems some of you have had. *shrugs*

----------

## Duncan Mac Leod

https://packages.gentoo.org/packages/sys-devel/binutils says that binutils-2.31.1-r4 is unstable, but portage means that it is flagged stable. Curious...

----------

## fedeliallalinea

 *Anon-E-moose wrote:*   

> I see this morning they downgraded elfutils, from 0.176 (was stable, now marked ~) back to 0.170-r1. Might have something to do with the problems some of you have had. *shrugs*

 

Related bug https://bugs.gentoo.org/671760

----------

## Anon-E-moose

 *Duncan Mac Leod wrote:*   

> https://packages.gentoo.org/packages/sys-devel/binutils says that binutils-2.31.1-r4 is unstable, but portage means that it is flagged stable. Curious...

 

Packages website hasn't been updated properly. Bugs.gentoo and the ebuild itself are what to pay attention to.

2.31.1-r4 is still marked stable for amd64. all other archs are still unstable.

----------

## toralf

or an elfutils bug? 

https://bugs.gentoo.org/676794

https://bugs.gentoo.org/671760

----------

## fedeliallalinea

 *toralf wrote:*   

> or an elfutils bug? 
> 
> https://bugs.gentoo.org/676794
> 
> https://bugs.gentoo.org/671760

 

The real bug is binutils, see upstream bug https://sourceware.org/bugzilla/show_bug.cgi?id=23919

----------

## Anon-E-moose

 *fedeliallalinea wrote:*   

>  *toralf wrote:*   or an elfutils bug? 
> 
> https://bugs.gentoo.org/676794
> 
> https://bugs.gentoo.org/671760 
> ...

 

That's for binutils 2.32, not sure what all the people above are running. So won't say for sure that that's a problem until they chime in. 

The original poster says 2.31 which doesn't have the problem, but he didn't say which elfutils he was using.

But it's some variation of binutils + elfutils that's likely the culprit.

Note: I did look at some of the bugs yesterday and there indeed is a problem when switching back to 2.31 from things compiled/linked with 2.32, as it seems that some internals changed between the 2 versions. No matter which it is, it's a developer caused problem both gentoo and upstream as there seems to be a severe lack of coordination between all parties. Elfutils went from 0.170 to 0.176 and then back to 0.170 in conjunction with the binutils stuff.

----------

## fedeliallalinea

 *Anon-E-moose wrote:*   

> That's for binutils 2.32, not sure what all the people above are running. So won't say for sure that that's a problem until they chime in. 

 

I tested the upstream patch in binutils 2.31 with >=dev-libs/elfutils-0.175 and works

----------

## Duncan Mac Leod

 *Duncan Mac Leod wrote:*   

> Today I had another problem with binutils 2.31 on amd64.
> 
> First I compiled/upgraded to glibc 2.28-r5, then I want to compile binutils, noticing these new gold flags.
> 
> During compilation I tried to figure out their meaning. After the successful compilation of binutils 2.31.1-r4 I noticed that binutils is not listed as stable any longer on the package-site https://packages.gentoo.org/packages/sys-devel/binutils, but portage listed them as stable.
> ...

 

My mistake  :Embarassed:  ...

Today I ran into the same error on x86 (re-)compiling gcc 6.4.0-r1, so I decided to upgrade gcc to the latest stable version (8.2.0-r6). No errors on compiling gcc.

The error on gcc 6.4.0-r1 was that the new glibc-2.28 is missing sys/ustat.h, so gcc 6.4.0-r1 is throwing an error nearly at the end of the build process.

Maybe gcc 6.4.0-r1 should check whether it builds against glibc-2.28 and abort.

----------

## Hu

 *Duncan Mac Leod wrote:*   

> The error on gcc 6.4.0-r1 was that the new glibc-2.28 is missing sys/ustat.h, so gcc 6.4.0-r1 is throwing an error nearly at the end of the build process.
> 
> Maybe gcc 6.4.0-r1 should check whether it builds against glibc-2.28 and abort.

 This is a bug in the ebuild.  It should patch gcc to work anyway, or have dependencies that prevent building it with a known incompatible glibc.  Aborting the build after it starts is only very slightly better than doing nothing, since it will still be a failure that the user must resolve.

----------

## CaptainBlood

 *fedeliallalinea wrote:*   

> I tested the upstream patch in binutils 2.31 with >=dev-libs/elfutils-0.175 and works

 Would you be keen enough to post a link for patch if any as I haven't found one yet, but indications what to patch and how, which is another story.

Surprisingly current statble 2.31 doesn't seem patched in portage, AFAIK.

Thks 4 ur attention.

----------

## fedeliallalinea

 *CaptainBlood wrote:*   

>  *fedeliallalinea wrote:*   I tested the upstream patch in binutils 2.31 with >=dev-libs/elfutils-0.175 and works Would you be keen enough to post a link for patch if any as I haven't found one yet, but indications what to patch and how, which is another story.
> 
> Surprisingly current statble 2.31 doesn't seem patched in portage, AFAIK.

 

Sure but rember that patch works and tested only in my system without problem for now (patch).

The patch is not applied because the problem is present only with a unstable package (dev-libs/elfutils-0.175).

----------

## CaptainBlood

Hum...

```
'snipped' eix dev-libs/elfutils

     Installed versions:  0.173-r1(17:57:20 10/04/2019)(-bzip2 -lzma -nls -static-libs -test -threads -utils ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
```

That kernel alignment issue remains... only with binutils:2.31, unpatched.

Puzzled  :Embarassed: 

Thks 4 ur attention, interest & support.

----------

## Anon-E-moose

What version of gcc and glibc.

And is the problem with building the kernel or trying to execute an already built image?

----------

## CaptainBlood

The problem is with booting a fresh builded kernel.

```
emerge --info sys-devel/binutils 

Portage 2.3.62 (python 3.6.5-final-0, default/linux/amd64/17.0, gcc-8.3.0, glibc-2.28-r6, 4.14.105-gentoo-r1-tuntap x86_64)

=================================================================

                         System Settings

=================================================================

System uname: Linux-4.14.105-gentoo-r1-tuntap-x86_64-Intel-R-_Core-TM-_i3-6100_CPU_@_3.70GHz-with-gentoo-2.6

KiB Mem:     3942400 total,   2399124 free

KiB Swap:    8048528 total,   8048528 free

sh bash 4.4_p23-r1

ld GNU ld (Gentoo 2.31.1 p5) 2.31.1

app-shells/bash:          4.4_p23-r1::gentoo

dev-java/java-config:     2.2.0-r4::gentoo

dev-lang/perl:            5.26.2::gentoo

dev-lang/python:          2.7.15::gentoo, 3.6.5::gentoo

dev-util/cmake:           3.9.6::gentoo

dev-util/pkgconfig:       0.29.2::gentoo

sys-apps/baselayout:      2.6-r1::gentoo

sys-apps/openrc:          0.38.3-r1::gentoo

sys-apps/sandbox:         2.13::gentoo

sys-devel/autoconf:       2.13-r1::gentoo, 2.69-r4::gentoo

sys-devel/automake:       1.11.6-r3::gentoo, 1.15.1-r2::gentoo, 1.16.1-r1::gentoo

sys-devel/binutils:       2.30-r4::gentoo, 2.31.1-r4::gentoo

sys-devel/gcc:            8.2.0-r6::gentoo, 8.3.0-r1::gentoo

sys-devel/gcc-config:     2.0::gentoo

sys-devel/libtool:        2.4.6-r3::gentoo

sys-devel/make:           4.2.1-r4::gentoo

sys-kernel/linux-headers: 4.14-r1::gentoo (virtual/os-headers)

sys-libs/glibc:           2.28-r6::gentoo

Repositories:

gentoo

    location: /usr/portage

    sync-type: rsync

    sync-uri: rsync://rsync.europe.gentoo.org/gentoo-portage

    priority: -1000

    sync-rsync-verify-metamanifest: no

    sync-rsync-extra-opts: 

    sync-rsync-verify-jobs: 1

    sync-rsync-verify-max-age: 24

x-portage

    location: /usr/local/portage

    masters: gentoo

    priority: 0

cross-aarch64-unknown-linux-gnu

    location: /usr/local/portage-cross-aarch64-unknown-linux-gnu

    masters: gentoo

    priority: 10

ACCEPT_KEYWORDS="amd64"

ACCEPT_LICENSE="* -@EULA"

CBUILD="x86_64-pc-linux-gnu"

CFLAGS="-march=native -mtune=skylake  -O2             -pipe"

CHOST="x86_64-pc-linux-gnu"

CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"

CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/dconf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php7.2/ext-active/ /etc/php/cgi-php7.2/ext-active/ /etc/php/cli-php7.2/ext-active/ /etc/revdep-rebuild /etc/sandbox.d /etc/splash /etc/terminfo /etc/texmf/language.dat.d /etc/texmf/language.def.d /etc/texmf/updmap.d /etc/texmf/web2c"

CXXFLAGS="-march=native -mtune=skylake  -O2             -pipe    "

DISTDIR="/usr/portage/distfiles"

EMERGE_DEFAULT_OPTS="   --alert y          --alphabetical       --ask-enter-invalid          --autounmask y           --autounmask-only n           --autounmask-unrestricted-atoms y     --autounmask-write y          --misspell-suggestions n       --noconfmem          --nospinner            --tree       --with-bdeps y"

ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"

FCFLAGS="-O2 -pipe"

FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms split-elog strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync"

FFLAGS="-O2 -pipe"

GENTOO_MIRRORS="http://distfiles.gentoo.org"

LANG="fr_FR.utf8"

LDFLAGS="  -Wl,-O1       -Wl,-fuse-ld=bfd  -Wl,--enable-new-dtags  -march=native -mtune=skylake  -O2             -pipe "

LINGUAS="fr"

MAKEOPTS="-j3 -l3"

PKGDIR="/usr/portage/packages"

PORTAGE_COMPRESS="lzma"

PORTAGE_COMPRESS_FLAGS="-9"

PORTAGE_CONFIGROOT="/"

PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"

PORTAGE_TMPDIR="/var/tmp"

USE="amd64 asm minimal" ABI_X86="64" ALSA_CARDS="hda-intel" CPU_FLAGS_X86="aes avx avx2 f16c fma3 mmx mmxext pclmul popcnt sse sse2 sse3 sse4_1 sse4_2 ssse3" ELIBC="glibc" GRUB_PLATFORMS="pc" INPUT_DEVICES="libinput" KERNEL="linux" L10N="fr" PHP_TARGETS="php7-2" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6 python3_7" QEMU_USER_TARGETS="aarch64" RUBY_TARGETS="ruby24" USERLAND="GNU" VIDEO_CARDS="intel i965"

Unset:  CC, CPPFLAGS, CTARGET, CXX, INSTALL_MASK, LC_ALL, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_RSYNC_EXTRA_OPTS

=================================================================

                        Package Settings

=================================================================

sys-devel/binutils-2.30-r4::gentoo was built with the following:

USE="cxx -doc -multitarget -nls -static-libs -test" ABI_X86="(64)"

sys-devel/binutils-2.31.1-r4::gentoo was built with the following:

USE="cxx -default-gold -doc gold -multitarget -nls plugins -static-libs -test" ABI_X86="(64)"
```

Also tried with patched binutils:2.31

```
mkdir -p /etc/portage/patches/sys-devel/binutils-2.31.1-r4

nano -w /etc/portage/patches/sys-devel/binutils-2.31.1-r4/binutils-2.31.1-r4-elf-compressed-data-alignment.patch
```

where I pasted lines 58 to 518 both inclusive from fedeliallalinea's above patch, then

```
emerge -1 =sys-devel/binutils-2.31.1-r4

eselect binutils x86_64-pc-linux-gnu-2.31.1

. /etc/profile
```

starting with

```
make clean
```

before rebuilding kernel.

But alignment issue remains.

Thks 4 ur attention, interest & support.

----------

## Anon-E-moose

```
LDFLAGS="  -Wl,-O1       -Wl,-fuse-ld=bfd  -Wl,--enable-new-dtags  -march=native -mtune=skylake  -O2             -pipe " 
```

 :Question: 

```
       --enable-new-dtags

       --disable-new-dtags

           This linker can create the new dynamic tags in ELF. But the older ELF systems may not understand them. If

           you specify --enable-new-dtags, the new dynamic tags will be created as needed and older dynamic tags will

           be omitted.  If you specify --disable-new-dtags, no new dynamic tags will be created. By default, the new

           dynamic tags are not created. Note that those options are only available for ELF systems.
```

I would not set LDFLAGS in your make.conf (which is where some of the stuff is coming from and let the default take place)

Default is [LDFLAGS="-Wl,-O1 -Wl,--as-needed"]

Edit to add: I don't know if the above is part of the problem, but simplifying things is always a good first step.

----------

## CaptainBlood

Snippet from my kernel build bash script:

```
make CC="gcc -fuse-ld=bfd -Wl,-fuse-ld=bfd" LDFLAGS="-fuse-ld=bfd" -j3 -l3 all
```

These bfd things are remains from a former period where gold was default.

Thks 4 ur attention, interest & support.

----------

## Anon-E-moose

Those are kernel build flags, what I was talking about is what you have set up for the rest of the portage binaries (make.conf)

You may be building binaries (especially toolchain ones) that are causing the problem rather than the kernel itself. 

Build a proper elfutils, binutils, etc and then see if the problems of the kernel go away.

----------

## CaptainBlood

Hi,

It so happens, I've been compiling kernel via a script for a couple of years now, culprit snippet here

```
make CC="gcc -fuse-ld=bfd -Wl,-fuse-ld=bfd" LDFLAGS="-fuse-ld=bfd" -j3 -l3 all
```

 which forces the use of ld.bfd when ld.gold might be the default.

I've removed the ld.bfd cruff, as I don't ld.gold anymore.

AFAIK,

```
-Wl,--enable-new-dtags
```

has been set as default in Gentoo for quite a while now.

I think I added it to be remembered this gentoo specific.

I'm keeping it active for now.

Thks 4 ur attention, interest & support.

----------

## hoegger

Hi!

Sorry for hijacking this thread but since my issue seems to be related to the same bug I am posting it here.

After upgrading to binutils-2.31.1-r4 I am not able to build a working kernel. There is no error message, just instant reboot as soon as the system tries to execute the kernel.

Also the nvidia-drivers compile without error msg but fail on load.

After switching to binutils-2.30 everything is fine.

Xeon E3-1231 v3

kernel-4.9.34

binutils-2.31.1-r4

elfutils-0.173-r1

glibc-2.28-r6

gcc-8.2.0-r6

libtool-2.4.6-r3

llvm-6.0.1

I tried make clean —> no success

emerge -e @system —> no success

binutils-config 2.30 && . /etc/profile —> works

Should I again build @system since it is (re)built with binutils-2.31.1-r4 ?

----------

## Hu

hoegger: what kernel version(s) have you tried with binutils-2.31?  Does a 5.0.x series kernel also fail this way?

----------

## Anon-E-moose

Hmm https://www.fclose.com/linux-kernels/324105/x86-boot-64-verify-alignment-of-the-load-segment-linux-4-9-91/

The link mentions that it was applied to different kernels, link for those at link above.

Not sure if this is the problem or just part of it when combined with other parts of the toolchain.

But it is where the "alignment ... 2mb" message is being generated.

I haven't tried to recompile the kernel yet (kernel 4.14.62, gcc 8.2, glibc 2.27 and binutils 3.21) to see if it bites me.

Edit to add: and this commit

```
commit faf470583a5701c286c62f0dfaaa06964a8c4ed8

Author: H.J. Lu <hjl.tools@gmail.com>

Date:   Mon Mar 19 13:57:46 2018 -0700

    x86/build/64: Force the linker to use 2MB page size

    

    commit e3d03598e8ae7d195af5d3d049596dec336f569f upstream.

    

    Binutils 2.31 will enable -z separate-code by default for x86 to avoid

    mixing code pages with data to improve cache performance as well as

    security.  To reduce x86-64 executable and shared object sizes, the

    maximum page size is reduced from 2MB to 4KB.  But x86-64 kernel must

    be aligned to 2MB.  Pass -z max-page-size=0x200000 to linker to force

    2MB page size regardless of the default page size used by linker.

    

    Tested with Linux kernel 4.15.6 on x86-64.
```

I mention because it specifically mentions binutils 2.31.

ETA2: Not sure what to make of things, looking at my kernel sources, -z max-page-size=0x200000, is being passed when building the kernel, so it shouldn't see a problem. Not sure if modules built outside of the kernel build pick up this parm though.

----------

## Anon-E-moose

 *CaptainBlood wrote:*   

> Snippet from my kernel build bash script:
> 
> ```
> make CC="gcc -fuse-ld=bfd -Wl,-fuse-ld=bfd" LDFLAGS="-fuse-ld=bfd" -j3 -l3 all
> ```
> ...

 

I think this might be your problem, as you're overriding the LDFLAGS from inside the makefile, you're not adding to them, you're replacing them.

I did a test, 

make -n CC="gcc -fuse-ld=bfd -Wl,-fuse-ld=bfd" LDFLAGS="-fuse-ld=bfd" >/tmp/lookat 2>&1

then  grep max-page /tmp/lookat (total output listed)

```
set -e;  echo '  VDSO    arch/x86/entry/vdso/vdso64.so.dbg'; gcc -fuse-ld=bfd -Wl,-fuse-ld=bfd -nostdlib -o arch/x86/entry/vdso/vdso64.so.dbg -fPIC -shared  -Wl,--hash-style=both  -Wl,--build-id -Wl,-Bsymbolic  -m64 -Wl,-soname=linux-vdso.so.1 -Wl,--no-undefined -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096  -Wl,-T,arch/x86/entry/vdso/vdso.lds arch/x86/entry/vdso/vdso-note.o arch/x86/entry/vdso/vclock_gettime.o arch/x86/entry/vdso/vgetcpu.o && sh ./arch/x86/entry/vdso/checkundef.sh 'nm' 'arch/x86/entry/vdso/vdso64.so.dbg'; printf '%s\n' 'cmd_arch/x86/entry/vdso/vdso64.so.dbg := gcc -fuse-ld=bfd -Wl,-fuse-ld=bfd -nostdlib -o arch/x86/entry/vdso/vdso64.so.dbg -fPIC -shared  -Wl,--hash-style=both  -Wl,--build-id -Wl,-Bsymbolic  -m64 -Wl,-soname=linux-vdso.so.1 -Wl,--no-undefined -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096  -Wl,-T,arch/x86/entry/vdso/vdso.lds arch/x86/entry/vdso/vdso-note.o arch/x86/entry/vdso/vclock_gettime.o arch/x86/entry/vdso/vgetcpu.o && sh ./arch/x86/entry/vdso/checkundef.sh '\''nm'\'' '\''arch/x86/entry/vdso/vdso64.so.dbg'\''' > arch/x86/entry/vdso/.vdso64.so.dbg.cmd
```

then did

make -n  >/tmp/lookat2 2>&1 (no LDFLAGS, etc)

then grep max-page /tmp/lookat2 (only showing a snippet, but shows what the problem is)

```
set -e;  echo '  VDSO    arch/x86/entry/vdso/vdso64.so.dbg'; gcc -nostdlib -o arch/x86/entry/vdso/vdso64.so.dbg -fPIC -s

hared  -Wl,--hash-style=both  -Wl,--build-id -Wl,-Bsymbolic  -m64 -Wl,-soname=linux-vdso.so.1 -Wl,--no-undefined -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096  -Wl,-T,arch/x86/entry/vdso/vdso.lds arch/x86/entry/vdso/vdso-note.o arch/x86/entry/vdso/vclock_gettime.o arch/x86/entry/vdso/vgetcpu.o && sh ./arch/x86/entry/vdso/checkundef.sh 'nm' 'arch/x86/entry/vdso/vdso64.so.dbg'; printf '%s\n' 'cmd_arch/x86/entry/vdso/vdso64.so.dbg := gcc -nostdlib -o arch/x86/entry/vdso/vdso64.so.dbg -fPIC -shared  -Wl,--hash-style=both  -Wl,--build-id -Wl,-Bsymbolic  -m64 -Wl,-soname=linux-vdso.so.1 -Wl,--no-undefined -Wl,-z,max-page-size=4096 -Wl,-z,common-page-size=4096  -Wl,-T,arch/x86/entry/vdso/vdso.lds arch/x86/entry/vdso/vdso-note.o arch/x86/entry/vdso/vclock_gettime.o arch/x86/entry/vdso/vgetcpu.o && sh ./arch/x86/entry/vdso/checkundef.sh '\''nm'\'' '\''arch/x86/entry/vdso/vdso64.so.dbg'\''' > arch/x86/entry/vdso/.vdso64.so.dbg.cmd

set -e;  echo '  LD [M]  arch/x86/kvm/kvm.o'; ld -m elf_x86_64  -z max-page-size=0x200000   -r -o arch/x86/kvm/kvm.o arch/x86/kvm/../../../virt/kvm/kvm_main.o arch/x86/kvm/../../../virt/kvm/coalesced_mmio.o arch/x86/kvm/../../../virt/kvm/eventfd.o arch/x86/kvm/../../../virt/kvm/irqchip.o arch/x86/kvm/../../../virt/kvm/vfio.o arch/x86/kvm/../../../virt/kvm/async_pf.o arch/x86/kvm/x86.o arch/x86/kvm/mmu.o arch/x86/kvm/emulate.o arch/x86/kvm/i8259.o arch/x86/kvm/irq.o arch/x86/kvm/lapic.o arch/x86/kvm/i8254.o arch/x86/kvm/ioapic.o arch/x86/kvm/irq_comm.o arch/x86/kvm/cpuid.o arch/x86/kvm/pmu.o arch/x86/kvm/mtrr.o arch/x86/kvm/hyperv.o arch/x86/kvm/page_track.o arch/x86/kvm/debugfs.o ; printf '%s\n' 'cmd_arch/x86/kvm/kvm.o := ld -m elf_x86_64  -z max-page-size=0x200000   -r -o arch/x86/kvm/kvm.o arch/x86/kvm/../../../virt/kvm/kvm_main.o arch/x86/kvm/../../../virt/kvm/coalesced_mmio.o arch/x86/kvm/../../../virt/kvm/eventfd.o arch/x86/kvm/../../../virt/kvm/irqchip.o arch/x86/kvm/../../../virt/kvm/vfio.o arch/x86/kvm/../../../virt/kvm/async_pf.o arch/x86/kvm/x86.o arch/x86/kvm/mmu.o arch/x86/kvm/emulate.o arch/x86/kvm/i8259.o arch/x86/kvm/irq.o arch/x86/kvm/lapic.o arch/x86/kvm/i8254.o arch/x86/kvm/ioapic.o arch/x86/kvm/irq_comm.o arch/x86/kvm/cpuid.o arch/x86/kvm/pmu.o arch/x86/kvm/mtrr.o arch/x86/kvm/hyperv.o arch/x86/kvm/page_track.o arch/x86/kvm/debugfs.o ' > arch/x86/kvm/.kvm.o.cmd

set -e;  echo '  LD [M]  arch/x86/kvm/kvm-amd.o'; ld -m elf_x86_64  -z max-page-size=0x200000   -r -o arch/x86/kvm/kvm-amd.o arch/x86/kvm/svm.o arch/x86/kvm/pmu_amd.o ; printf '%s\n' 'cmd_arch/x86/kvm/kvm-amd.o := ld -m elf_x86_64  -z max-page-size=0x200000   -r -o arch/x86/kvm/kvm-amd.o arch/x86/kvm/svm.o arch/x86/kvm/pmu_amd.o ' > arch/x86/kvm/.kvm-amd.o.cmd
```

And given that binutils 2.31 does things different, when you remove, -z max-page-size=0x200000, from the LDFLAGS, you cause problems.

----------

## hoegger

 *Hu wrote:*   

> hoegger: what kernel version(s) have you tried with binutils-2.31?  Does a 5.0.x series kernel also fail this way?

 

I did not try 5.0.x. Meanwhile i switched to binutils-2.30-r4 and did an emerge -e @system and emerge -e @world. Also I graded up from kernel 4.9.34 to 4.19.27-r1. Since firefox was complaining about clang:7 and clang:8 not found is also installed clang:7/8 and dependencies.

While previously trying to compile the old kernel (4.9.34) with binutils-2.31.1-r4 i noticed the size of the (unusable) binary was about 2M smaller as it was with 2.30-r4.

----------

## Anon-E-moose

binutils 2.31 should work with at least these kernels (min version for old kernels)

4.1.52

4.4.125

4.9.91

4.14.31

Not sure if all the 4.19 series is ok, but from 4.19.27 on it should be fine.

and all of the 5.* series.

The key to working with binutils 2.31 as mentioned above is the ld flag "-z max-page-size=0x200000" if the kernel is not built with it, it won't work when trying to load.

----------

## CaptainBlood

 *hoegger wrote:*   

> While previously trying to compile the old kernel (4.9.34) with binutils-2.31.1-r4 i noticed the size of the (unusable) binary was about 2M smaller as it was with 2.30-r4.

 

Just the symptom with my faulty make command.

No idea what to point you to...

Thks 4 ur attention, interest & support.

----------

## Anon-E-moose

 *CaptainBlood wrote:*   

>  *hoegger wrote:*   While previously trying to compile the old kernel (4.9.34) with binutils-2.31.1-r4 i noticed the size of the (unusable) binary was about 2M smaller as it was with 2.30-r4. 
> 
> Just the symptom with my faulty make command.
> 
> No idea what to point you to...
> ...

 

For you, get rid of your make "script" that overrides CC and LD flags. 

For hoegger, use a kernel where they put the fix in that applies to binutils 2.31

----------

## hoegger

 *Anon-E-moose wrote:*   

>  *CaptainBlood wrote:*    *hoegger wrote:*   While previously trying to compile the old kernel (4.9.34) with binutils-2.31.1-r4 i noticed the size of the (unusable) binary was about 2M smaller as it was with 2.30-r4. 
> 
> Just the symptom with my faulty make command.
> 
> No idea what to point you to...
> ...

 

So i will give it a shot as soon as an update for nvidia-drivers is available in portage. I already placed a sticky note to remember myself.

Thank you very much!

----------

