Segfault

[Linus Torvalds]

On Tue, Feb 12, 2013 at 2:32 PM, Cristian Ionescu-Idbohrn
<cristian.ionescu-idbohrn at axis.com> wrote:
>
> So, Jef.  Is there something you can recall?  Anything?

It's worth noting that the autogenerated dependencies aren't perfect.
They will fail if:

 (a) you have object files that predate the whole autogenerated
dependency maker.

     So if Jef had some *really* old objects (that didn't have the
dependency file), updated recently, and re-built, the automated
dependency logic doesn't catch that. It only catches dependencies on
object files that were built after the dependency logic was
implemented.

 (b) you change compiler options etc.

     The Linux kernel auto-generated dependency rules are really
fancy, and actually notice if you change something that changes the
compiler options used to build the object file, but the kernel
Makefile infrastructure is insanely convoluted. The subsurface
auto-dep support is much simpler.

    So if you change CFLAGS to include "-m32" or something like that,
which changes the object file model, the auto-dependency tracker will
*not* understand that the object files are "stale" in the new world
order.

 (c) if you somehow remove the .dep/xyxxy.o.dep file, but leave the
xyzzy.o file alone

     This is really just a special case of (a), and normally wouldn't
happen, but maybe somebody ends up noticing the hidden directory, and
finds it annoying, and then just does a "rm -rf .dep". In which case
the dependency information will obviously be silently lost, and the
Makefile won't complain.

Btw, there is actually a good reason to do that "rm -rf" in (c). In
particular, if your whole installation changes, and some header file
gets removed, the dependency file can contain stale information that
mentions header files that simply don't exist any more (and this
includes *system* header files that got moved somewhere else when you
updated some developer library package or something). Doing a "rm -rf
.dep" may be the simplest thing to do - but you should always also
remove *.o if you do this.

All of the above are "fixable" things, but the fixes imply an insane
amount of Makefile rule hackery that just likely isn't worth it. For
example, in the kernel, we massage the output from "gcc -MD" to use
the GNU make "$(wildcard heade-file-name)" thing instead of just the
header file name, exactly so that if header files disappear, we don't
get errors about "don't know how to generate that stale header file"
etc. And the whole infrastructure to check the command line hasn't
changed is more black magic Makefile code.

So for the kernel, we have some beautiful Makefiles (that do not look
like traditional makefiles at all) with automagical support for
configuration options etc, but the price of all that fancy Makefile
magic is that we have some of the absolutely totally most inscrutable
stuff to implement the infrastructure. Complexity spread over many
different helper files. Just for the *makefile*.

For subsurface, I went for a *much* simpler model with just a few
extra lines in the Makefile.

               Linus