> So I currently see the following in my build logs: > > [...] > mkdir -p -- ./fixincludes > Configuring in ./fixincludes > configure: creating cache ./config.cache > [...]/source-gcc/fixincludes/configure: line 3030: > enable_darwin_at_rpath_--srcdir=[...]/source-gcc/fixincludes=no: No such file > or directory > checking build system type... x86_64-pc-linux-gnu > checking host system type... x86_64-pc-linux-gnu > checking target system type... nvptx-unknown-none > [...] > > I'm not convinced that's achieving what it means to achieve?
I’ve tried to understand where that line gets expanded from: >>> +enable_darwin_at_rpath_$1=no It comes from: > _LT_TAGVAR(enable_darwin_at_rpath, $1)=no in the top-level libtool.m4. I can’t say that I understand why that line is there. All the other definitions using this structure are all inside the definition of _LT_ prefixed functions, defined by m4_defun. This one line is alone, outside of any function. If I remove the line from libtool.m4 (innocent smile) I see that fixincludes/configure is better, and it does not appear to change the regenerated files in other directories (I didn’t do a build yet, just tried to regenerate with some manual autoconf invocations). Food for thought. FX
