Re: Help with Outreachy Setup

[Stefano Brivio <sbrivio@redhat.com>]

On Mon, 28 Mar 2022 23:15:58 +0000
Rebecca Mckeever <rebecca.mckeever@protonmail.com> wrote:

> Hi Stefano,
> 
> ------- Original Message -------
> 
> On Sunday, March 27th, 2022 at 03:54, Stefano Brivio <sbrivio@redhat.com> wrote:
>
> [...]
>
> > To build the kernel with that option, you don't just need binutils, you
> > would also need binutils with this specific support, which is not
> > commonly available in distribution. I bet "elf32-86-64" is missing in
> > the list of supported "targets" when you issue:
> >
> > objcopy --help  
> 
> Yes, "elf32-86-64" was missing from the list of targets. But the list did include "elf32-x86-64". Do you know what the difference between them is?

That was just my typo :( So objcopy supports it. The other component
that needs to support that is ld (the dynamic linker), you could check:

	$ ld --help|grep elf32_x86_64

but I think it's very unlikely that objcopy has that and ld doesn't, so
there must be some other issue. If you're interested, you could try to
add some debugging to that Makefile, it's arch/x86/Makefile.

> > Anyway, yes, it's just a warning. You can get rid of the warning by
> > disabling the CONFIG_X86_X32 in your kernel configuration. Maybe you
> > could make sure you disabled it with the correct syntax with this, from
> > your kernel tree:
> >
> > scripts/config -d CONFIG_X86_X32
> >
> > ...it can still be that it's selected by another option, so it would be
> > re-enabled automatically. Search for it from 'make menuconfig', typing
> > '/' (slash) and searching for X86_X32. Then you will see if that's the
> > case.  
> 
> This worked for me. I was able to recompile without seeing the warning.

Okay, nice!

> > The actual build error you got on the other machine is probably a
> > dependency issue between options, which happens with your particular
> > configuration, but it really shouldn't happen no matter how your
> > configuration looks like.
> >
> > The relevant configuration options are CONFIG_CRYPTO_AES_NI_INTEL and
> > CONFIG_64BIT -- you could start having a look at the state of those two.
> 
> CONFIG_CRYPTO_AES_NI_INTEL was set to m. I tried changing it to n and
> then y, and neither removed the error. Changing CONFIG_64BIT didn't
> remove the error either. I think I may have made a mistake early in the
> process and would need to start over to get it working. I will stick
> with compiling on the other machine for now; I actually prefer it that
> way.

Good, let's try to debug that only if it comes up again.

> Thanks for you help Stefano!

You're welcome!

-- 
Stefano