Unable to build kernel

[Ferruck]

I'm unable to build the provided kernel with the devel::cross-toolchain-arm-linux-gnueabihf toolchain using the latest HEAD. It fails with the following error message:

   DOWNLOAD  work/kernel/linux-image/dist/1/workspace .. not found
   BUILD     work/kernel/linux-image/build/1/workspace
/bob/0db088bbb3adf91865aa1ec11c1136cb75eb97f4/workspace/scripts/extract-cert.c:21:25: fatal error: openssl/bio.h: No such file or directory
compilation terminated.
make[2]: *** [scripts/Makefile.host:90: scripts/extract-cert] Error 1
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [/bob/0db088bbb3adf91865aa1ec11c1136cb75eb97f4/workspace/Makefile:1099: scripts] Error 2
make[1]: *** Waiting for unfinished jobs....
make: *** [/bob/0db088bbb3adf91865aa1ec11c1136cb75eb97f4/workspace/Makefile:179: sub-make] Error 2
Step failed with return status 2; Command: make -j "${MAKE_JOBS-$(nproc)}" "$@"
Call stack (most recent call first)
    #0: Class  make, layer basement, line 3, in makeParallel
    #1: Recipe kernel::linux#2, layer basement, line 1, in main
Build error: Build script ./work/kernel/linux-image/build/1/build.sh returned with 2

I'm unsure about how to provide the obviously needed dependency OpenSSL to the kernel, I've tried a few ways, none of which worked. The turnaround time is quite high, as you can imagine, so I'd rather stop my uneducated guesses and hope for constructive feedback from your side.

[jkloetzke]

I'll look into it...

[jkloetzke]

Obviously the kernel likes to have a host OpenSSL to build some tool.

😬 I'm afraid there is no good solution for that available in Bob currently. We would need to define a dependency that is built with the host toolchains instead of the currently configured cross toolchain. I'm not yet sure how to integrate that elegantly... 😐

[Ferruck]

So you're on the exact same point as I am... 😂 We've managed to build the kernel by adding libs::openssl-dev to the devel::sandbox recipe and removing the line

rm -rf usr/include

from classes::sandbox. Maybe @frajasalo might add his patch here for reference, but this is a hack, for sure (though I'm unsure about the classes::sandbox thing, maybe that's indeed the right thing to do?!). We thought about adding libs::openssl-dev as a dependency to the host compiler toolchain and provide the dependency therein, but we're yet unsure about how to do this exactly.

[frajasalo]

Here is the patch of my hack which patches the openssl recipe for installing into an non-standard directory and pulling this directory during the kernel build: edeX-UG/basement@44b1a52

[Ferruck]

I just wanted to ensure that this doesn't get out of focus. @jkloetzke, did you managed yet to have a look into the provided patch? Is this a feasible way of fixing the issue? Any remarks or possible improvements?

[jkloetzke]

Well, the patch solves the problem but is more a hack than a long term viable solution. The sandbox image should not hold any host development libraries because the build should be independent of the fact that a sandbox is used or not. The real solution will need some support on the Bob side but I currently have no time to work on that...

[Ferruck]

Maybe if you could give some more insight, we're able to provide those changes needed in Bob...

[jkloetzke]

The main idea is to somehow remap the toolchains for dependencies. Maybe something like:

depends:
  - name: libs::openssl-dev
    tools:
      target-toolchain: host-toolchain
    environment:
      ARCH: "${HOST_ARCH}"
      AUTOCONF_HOST: "${AUTOCONF_BUILD}"
      AUTOCONF_TARGET: null

This would replace the target-toolchain with the current host-toolchain for just one dependency. Now the tricky part is how to cope with the environment variables. My current idea is to attach the toolchain dependent variables (CC, LD, ...) to the tool itself (as environment in provideTools). The approach above would then nicely handle these variables automatically. The drawback is that you cannot use these variables in a recipe anymore unless you actually use the tool. The generic target variables (ARCH, AUTOCONF_HOST and AUTOCONF_TARGET) still need to be handled separately. The null syntax to delete a variable needs to be added too...

[Ferruck]

Thanks for your response. I just want to sort out any possible misunderstandings here:

This would replace the target-toolchain with the current host-toolchain for just one dependency.

This has to be implemented into Bob, right?

My current idea is to attach the toolchain dependent variables (CC, LD, ...) to the tool itself (as environment in provideTools).

This is currently already possible and is just a change in the Basement recipes, isn't it?

The drawback is that you cannot use these variables in a recipe anymore unless you actually use the tool.

In fact, that would be a welcomed change for me, since it always bothered me, why I could use some variables automagically and others not.

I'll gladly have a look into the needed changes and see if I can provide some constructive input.

[jkloetzke]

Thanks for your response. I just want to sort out any possible misunderstandings here:

This would replace the target-toolchain with the current host-toolchain for just one dependency.

This has to be implemented into Bob, right?

Exactly.

My current idea is to attach the toolchain dependent variables (CC, LD, ...) to the tool itself (as environment in provideTools).

This is currently already possible and is just a change in the Basement recipes, isn't it?

Yes. The feature is in Bob since one or two releases.

The drawback is that you cannot use these variables in a recipe anymore unless you actually use the tool.

In fact, that would be a welcomed change for me, since it always bothered me, why I could use some variables automagically and others not.

I'll gladly have a look into the needed changes and see if I can provide some constructive input.

👍