Hi James
> On 23 Jun 2025, at 17:08, Richard Biener via Gcc <gcc@gcc.gnu.org> wrote:
>> Am 23.06.2025 um 17:56 schrieb James K. Lowden <jklow...@schemamania.org>:
>> On Sat, 21 Jun 2025 11:03:19 +0200
>> Richard Biener <richard.guent...@gmail.com> wrote:
>>
>>>> A comparison of the mentions of "fixinclude" in config.{status,log}
>>>> of two directories, bootstrap and non-bootstrap, shows no
>>>> difference.
>>>>
>>>> What should I be looking for?
>>>
>>> For why fixinclude isn?t built - the config.log therein might show
>>> something.
>>
>> Thanks, Richard. As I said, both bootstrap and nonboostrap builds
>> leave identical traces of fixinclude in config.log:
>>
>> $ grep fixi build/config.log | nl
>> 1 build_configdirs=' libiberty libcpp fixincludes'
>> 2 configdirs=' libiberty zlib libbacktrace libcpp libcody
>> libdecnumber fixincludes gcc libcc1 c++tools'
>>
>> At Iain's suggestion, I tried an out-of-body experience, and that
>> worked. So, now we know something we didn't before. Let me explain.
>>
>> I normally create a build directory off the root. According to
>> gccinstall.info, that is a supported arrangement.
>>
>> "... building where OBJDIR is a subdirectory of SRCDIR should
>> work as well; building where OBJDIR == SRCDIR is unsupported."
>>
>> I take that to mean that, wherever one builds, one must be free to run
>> "rm -rf" on the build tree.
>>
>> So I normally have:
>>
>> $ pwd && ls -d $(git rev-parse --show-toplevel) build
>> /home/jklowden/projects/3rd/gcc/parser
>> /home/jklowden/projects/3rd/gcc/parser build
>>
>> In that topology, for a bootstrap build only, build/fixinclude is
>> empty.
>>
>> Today I created a build directory in /tmp, and the bootstrap build
>> succeeded:
>>
>> $ head config.log | grep /configure
>> $ /home/jklowden/projects/3rd/gcc/cobol-stage/configure
>> --prefix=/usr/local/gcc-cobol --disable-multilib --enable-checking
>> --enable-languages=c,cobol
>>
>> $ ls fixincludes/ config.cache fixfixes.o
>> fixlib.o Makefile server.o config.h fixincl
>> fixopts.o mkheaders stamp-hconfig.log fixincl.o
>> fixtests.o mkheaders.almost config.status fixinc.sh full-stamp
>> procopen.o
>>
>> To recap:
>>
>> 1. For --disable-bootstrap, ../OBJDIR == SRCDIR works.
>>
>> 2. For --enable-bootstrap, if ../OBJDIR == SRCDIR, OBJDIR/fixinclude
>> is an empty directory. The build succeeds, but "make install" fails.
>
> This definitely works for me.
This is what I recall - whether this works depends on who one asks.
Perhaps there’s some sensitivity to make version or something?
(it would be good to explain the problem, so that we can document
what is supported).
>> 3. For --enable-bootstrap, if ../OBJDIR != SRCDIR, "make install"
>> succeeds.
>>
>> 4. gccinstall doesn't define "should work" for #2.
>>
>> I don't know what purpose fixinclude serves.
They serve an essential function on OSs where the installed (or SDK)
includes have incompatibilities with GCC - this allows those incompatibitities
to be corrected - certainly on Darwin/macOS they are currently required -
I’m on a mision to add workarounds to the compiler to avoid needing them -
but those workarounds are currently “work in progress” and only available
on the darwin development branch(es).
Iain
>> My problem is solved
>> insofar as I have a working solution. If I may, I would suggest to the
>> folks who know what fixinclude does that it be made to work for
>> case #2 above. If that's infeasible, we should update the
>> documentation to say so.
>>
>> --jkl
