lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAK7LNATgO-ujY1xOowqmL0Dz03qBsjANx4Zc69aXB0Qbju2-8g@mail.gmail.com>
Date: Sat, 30 Nov 2024 18:19:19 +0900
From: Masahiro Yamada <masahiroy@...nel.org>
To: Caleb Connolly <caleb.connolly@...aro.org>
Cc: linux-kbuild@...r.kernel.org, Miguel Ojeda <ojeda@...nel.org>, 
	rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org, 
	Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nicolas@...sle.eu>, 
	Stephan Gerhold <stephan.gerhold@...aro.org>
Subject: Re: [PATCH 21/23] kbuild: use absolute path in the generated wrapper Makefile

On Sat, Nov 30, 2024 at 8:31 AM Caleb Connolly
<caleb.connolly@...aro.org> wrote:
>
> Hi Masahiro,
>
> On 9/17/24 16:16, Masahiro Yamada wrote:
> > Keep the consistent behavior when this Makefile is invoked from another
> > directory.
>
> This breaks building in a chroot for me. I usually compile the kernel on
> my host and then use some tooling to just run the "package" step of an
> Alpine kernel package definition. See
>
> https://wiki.postmarketos.org/wiki/Compiling_kernels_with_envkernel.sh#Packaging_kernels_built_without_envkernel
>
> Since this requires mounting the source directory into a chroot, and
> then symlinking the output directory to the package "src" dir. It relies
> on the fact that make can be run from the output directory and
> implicitly relies on the include being relative since the absolute paths
> don't map inside the chroot.


I do not understand what is happening in your workflow, but presumably
you need to come up with a solution on your end (or in the pmos community).

 - Kbuild never promised that $(srctree) is always a relative path.
   $(srctree) is relative only when building in-tree (srctree=.)
   or when the output directory is a sub-directory of the source tree.
    (srctree=..) For other cases, $(srctree) is an absolute path.
   Therefore, "include directive with an absolute path" is not something new.

 - The wrapper Makefile generated in the output directory
   is a bonus convenience for humans. It is not even required
   to build the kernel from scripts.

Your report seems like a jungle of a chroot and mounts with a symlink.
I guess it just happened to work, relying on something Kbuild did not support.


>
> I'm not sure if breakages like this justify a revert, but I noticed this
> issue in -next the other day and thought it was at least worth reporting.


Thanks for the report, but I do not think this is worth a revert
for the above reasons.


> I wouldn't be surprised if other folks with other build systems get
> bitten by this too.
>
> Kind regards,
> Caleb
> >
> > Signed-off-by: Masahiro Yamada <masahiroy@...nel.org>
> > ---
> >
> >   Makefile | 5 +++--
> >   1 file changed, 3 insertions(+), 2 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index ce646a6994a6..9f0ba07e8f25 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -643,8 +643,9 @@ ifdef building_out_of_srctree
> >
> >   quiet_cmd_makefile = GEN     Makefile
> >         cmd_makefile = { \
> > -     echo "\# Automatically generated by $(srctree)/Makefile: don't edit"; \
> > -     echo "include $(srctree)/Makefile"; \
> > +     echo "\# Automatically generated by $(abs_srctree)/Makefile: don't edit"; \
> > +     echo "export KBUILD_OUTPUT = $(CURDIR)"; \
> > +     echo "include $(abs_srctree)/Makefile"; \
> >       } > Makefile
> >
> >   outputmakefile:
>


-- 
Best Regards
Masahiro Yamada

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ