Build from .config doesn't trigger fixdep build

[Vincent Fazio]

I'm attempting to migrate from 2023.05 to 2025.05.

We have an automated build process that copies in a full .config file into a directory containing an untar'd git archive of the swupdate sources. We use a full config to avoid scenarios where using a defconfig silently picks up changes in defaults across versions so we're at least alerted that a config chang or the build is broken prior to performing functional testing.

I noticed that this build process no longer works after the migration to Kconfiglib.

vfazio@vfazio4:~/development/swupdate$ rm scripts/basic/fixdep
vfazio@vfazio4:~/development/swupdate$ ls .config
.config
vfazio@vfazio4:~/development/swupdate$ make
  CC      ipc/network_ipc.o
/bin/sh: 1: scripts/basic/fixdep: not found
make[1]: *** [scripts/Makefile.build:168: ipc/network_ipc.o] Error 127
make: *** [Makefile:527: ipc] Error 2

Bisecting shows f88b1686b61505c5bbf373dd05953233e9105632 changed the make rule for auto.conf.

The old rule called `silentoldconfig` which ended up triggering:

%config: scripts_basic outputmakefile FORCE
    $(Q)mkdir -p include/linux include/config
    $(Q)$(MAKE) $(build)=scripts/kconfig $@

The new rule, however, does not have an implicit or explicit dependency on `scripts_basic` so fixdep never gets compiled. Adding it as a dependency for `$(ipc-dirs)` seemed to work, but may be an incomplete solution.

It also looks like there is no longer a silentoldconfig target.

For now, I can manually trigger the build of fixdep via the `scripts_basic` make target and I can change our process to manually run `make oldconfig`

I'm sure this is an edge case and most users are comfortable specifying their own defconfig, so maybe that's something I can no longer work around long term.

[Stefano Babic]

Hi Vincent,

On 10/1/25 17:21, Vincent Fazio wrote:
> I'm attempting to migrate from 2023.05 to 2025.05.
>
> We have an automated build process that copies in a full .config file
> into a directory containing an untar'd git archive of the swupdate
> sources. We use a full config to avoid scenarios where using a defconfig
> silently picks up changes in defaults across versions so we're at least

The common way is to generate .config from defconfig, then .config
always matches the selected version. defconfig is generated via "make
savedefconfig".

If you do this, just run "make oldconfig", your .config is loaded then.

> alerted that a config chang or the build is broken prior to performing
> functional testing.
>
> I noticed that this build process no longer works after the migration to
> Kconfiglib.

It was never officially supported.

>
> vfazio@vfazio4:~/development/swupdate$ rm scripts/basic/fixdep
> vfazio@vfazio4:~/development/swupdate$ ls .config
> .config
> vfazio@vfazio4:~/development/swupdate$ make
>   CC      ipc/network_ipc.o

But then "make oldconfig;make"

> /bin/sh: 1: scripts/basic/fixdep: not found
> make[1]: *** [scripts/Makefile.build:168: ipc/network_ipc.o] Error 127
> make: *** [Makefile:527: ipc] Error 2
>
> Bisecting shows f88b1686b61505c5bbf373dd05953233e9105632 changed the
> make rule for auto.conf.
>
> The old rule called `silentoldconfig` which ended up triggering:
>
> %config: scripts_basic outputmakefile FORCE
>     $(Q)mkdir -p include/linux include/config
>     $(Q)$(MAKE) $(build)=scripts/kconfig $@
>
> The new rule, however, does not have an implicit or explicit dependency
> on `scripts_basic` so fixdep never gets compiled.

It is with make oldconfig.

> Adding it as a
> dependency for `$(ipc-dirs)` seemed to work, but may be an incomplete
> solution.
>
> It also looks like there is no longer a silentoldconfig target.
>
> For now, I can manually trigger the build of fixdep via the
> `scripts_basic` make target and I can change our process to manually run
> `make oldconfig`
> > I'm sure this is an edge case and most users are comfortable
specifying
> their own defconfig, so maybe that's something I can no longer work
> around long term.

Best regards,
Stefano Babic

[Vincent Fazio]

On Wed, Oct 1, 2025 at 11:53 AM Stefano Babic
<stefan...@swupdate.org> wrote:
>
> Hi Vincent,
>
> On 10/1/25 17:21, Vincent Fazio wrote:
> > I'm attempting to migrate from 2023.05 to 2025.05.
> >
> > We have an automated build process that copies in a full .config file
> > into a directory containing an untar'd git archive of the swupdate
> > sources. We use a full config to avoid scenarios where using a defconfig
> > silently picks up changes in defaults across versions so we're at least
>
> The common way is to generate .config from defconfig, then .config
> always matches the selected version. defconfig is generated via "make
> savedefconfig".
>

Thanks for taking the time to respond.

I think we had some issues in the early days with default values
changing or new dependencies being added, which is why I moved to
using a full config to try to lock things down vs an in-tree defconfig
where defaults were subject to change. Of course, I don't have any of
that history around.. this was probably 5 years ago or so. So I guess
while my workflow unintentionally worked, it worked for a number of
years.

Ultimately, however, I think the level of work is likely going to be
the same either way. I still need to evaluate the new symbols, the new
dependencies, and generate a new config or defconfig. I'll just have
to update my documentation to emphasize that I should not try to
blindly use an old config.

Thanks,
-Vincent