On Sun, 2026-02-08 at 12:58 +0100, Peter Dyballa wrote: > Since configure had already produced a Makefile to build in libgcc I > removed the three created symlinks + libgcc_tm.stamp and libgcc_tm.h. > Then I invoked "env LANG=C /opt/local/bin/gmake -d" in this > directory. On the almost 10,000 lines of GMake output the missing two > symlinks to C header files, sfp-machine.h and md-unwind-def.h, are > *never* mentioned.
If they are never mentioned, then no target that make considered lists them as a prerequisite. In your initial email you showed this: 362 LIBGCC_LINKS = enable-execute-stack.c \ 363 unwind.h md-unwind-def.h md-unwind-support.h \ 364 sfp-machine.h gthr-default.h ... 1122 $(libgcc-objects) $(libgcc-s-objects) $(libgcc-eh-objects) \ 1123 $(libgcov-objects) \ 1124 $(libunwind-objects) $(libunwind-s-objects) \ 1125 $(EXTRA_PARTS): $(LIBGCC_LINKS) libgcc_tm.h This (if accurate and parsed as shown by GNU Make) means that if make considers any of the targets which the initial variables expand to, it will consider the links in LIBGCC_LINKS. If make doesn't consider any of those targets, then it won't consider those links and they won't appear in the output. There are, obviously a lot of "ifs" in this. For example, if the LIBGCC_LINKS variable is reset, or if the libgcc-objects variables are not set, or if whatever target you tried to build doesn't depend on them, etc. To understand what make's internal database looks like after parsing all the makefiles, you can run GNU Make with the -p option. This will print out the variable values, targets, and prerequisites. You should be able to search that output and find the name of the missing symlinks. See what targets list that symlink as a prerequisite. Then you can look through the debug log file you generated before, to find that target. If you don't see that target either, then you know why the symlinks weren't created: make didn't need to consider any target that listed them as a prerequisite. You can continue this backwards until you come to the goal target (the default or whatever you added to the make command line). What I find most odd is that you report the problem only happens on one OS version; that is, compiling the same source package with the same version of GNU make on two different OS versions gives different behaviors. That almost smells like some kind of OS issue. But on the other hand, if GNU Make doesn't report that it's even considering that target it points to something within GNU Make, since there's nothing about the OS involved with make's internal graph of prerequisites. It could be that this makefile tries to play tricks allowing it to ignore whole sections of targets, for efficiency reasons, and this is behaving differently somehow. Anyway. If you want me to look at the logs, Makefiles, make -p output, etc. you've generated and you can find somewhere to upload them I can do that (sending via email might not work so well for very large files).
