./configure ... --with-build-time-tools=$MY_TOOLS ignores $MY_TOOLS (though it correctly warns when $MY_TOOLS is not an absolute path). Let's just say this led to extremely frustrating behavior until I decided to start digging... Suggested patch to correct the problem: Index: /home/Ryan/apps/gcc-4.5-src/configure.ac =================================================================== --- /home/Ryan/apps/gcc-4.5-src/configure.ac (revision 157227) +++ /home/Ryan/apps/gcc-4.5-src/configure.ac (working copy) @@ -3221,7 +3221,9 @@ [ --with-build-time-tools=PATH use given path to find target tools during the build], [case x"$withval" in - x/*) ;; + x/*) + with_build_time_tools=$withval + ;; *) with_build_time_tools= AC_MSG_WARN([argument to --with-build-time-tools must be an absolute path])
(In reply to comment #0) > Let's just say this led to extremely frustrating behavior until I decided to > start digging... To be more specific, the gcc/as wrapper is generated with: ORIGINAL_AS_FOR_TARGET="" ORIGINAL_LD_FOR_TARGET="" ORIGINAL_PLUGIN_LD_FOR_TARGET="" ORIGINAL_NM_FOR_TARGET="" Which causes the building of libgcc to fail later on at gcc/as line 83 with a message about "exec: not found"
(In reply to Ryan Johnson from comment #0) > ./configure ... --with-build-time-tools=$MY_TOOLS ignores $MY_TOOLS (though > it correctly warns when $MY_TOOLS is not an absolute path). > > Let's just say this led to extremely frustrating behavior until I decided to > start digging... > > Suggested patch to correct the problem: > > Index: /home/Ryan/apps/gcc-4.5-src/configure.ac > =================================================================== > --- /home/Ryan/apps/gcc-4.5-src/configure.ac (revision 157227) > +++ /home/Ryan/apps/gcc-4.5-src/configure.ac (working copy) > @@ -3221,7 +3221,9 @@ > [ --with-build-time-tools=PATH > use given path to find target tools during the > build], > [case x"$withval" in > - x/*) ;; > + x/*) > + with_build_time_tools=$withval > + ;; > *) > with_build_time_tools= > AC_MSG_WARN([argument to --with-build-time-tools must be an absolute > path]) Confirming that GCC's configure.ac is still unpatched.
(In reply to Eric Gallager from comment #2) > (In reply to Ryan Johnson from comment #0) > > ./configure ... --with-build-time-tools=$MY_TOOLS ignores $MY_TOOLS (though > > it correctly warns when $MY_TOOLS is not an absolute path). > > > > Let's just say this led to extremely frustrating behavior until I decided to > > start digging... > > > > Suggested patch to correct the problem: > > > > Index: /home/Ryan/apps/gcc-4.5-src/configure.ac > > =================================================================== > > --- /home/Ryan/apps/gcc-4.5-src/configure.ac (revision 157227) > > +++ /home/Ryan/apps/gcc-4.5-src/configure.ac (working copy) > > @@ -3221,7 +3221,9 @@ > > [ --with-build-time-tools=PATH > > use given path to find target tools during the > > build], > > [case x"$withval" in > > - x/*) ;; > > + x/*) > > + with_build_time_tools=$withval > > + ;; > > *) > > with_build_time_tools= > > AC_MSG_WARN([argument to --with-build-time-tools must be an absolute > > path]) > > Confirming that GCC's configure.ac is still unpatched. Patches go to the gcc-patches mailing list if you still want to see this fixed
(In reply to Eric Gallager from comment #3) > Patches go to the gcc-patches mailing list if you still want to see this > fixed Actually I guess I can try taking it myself
(In reply to Eric Gallager from comment #4) > (In reply to Eric Gallager from comment #3) > > Patches go to the gcc-patches mailing list if you still want to see this > > fixed > > Actually I guess I can try taking it myself OK, submitted: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/599118.html
JFTR, I had cause to use this today on powerpc-darwin9, and it seemed to DTRT - so it would be useful to establish what it was that did not work before, that was fixed by the patch. /src-local/gcc-git-11/configure --prefix=/opt/iains/powerpc-apple-darwin9/gcc-11-3Dr2d --build=powerpc-apple-darwin9 --enable-languages=all --with-tune-cpu=G5 --enable-libphobos --with-libphobos-druntime-only CC=powerpc-apple-darwin-gcc CXX=powerpc-apple-darwin-g++ --with-build-time-tools=/opt/iains/powerpc-apple-darwin9/gcc-11-3Dr2d/bin Without the "--with-build-time-tools=/opt/iains/powerpc-apple-darwin9/gcc-11-3Dr2d/bin" the system linker and assembler are found and used (which fails to work with D, causing a bootstrap fail) with the option, the relevant tools are found and bootstrap succeeded.... (so I am not sure what the original problem was since $build is not specified in the summary, I guess we must assume it was i686-pc-cygwin so perhaps the problem is specific to that setup?)
(In reply to Iain Sandoe from comment #6) > JFTR, I had cause to use this today on powerpc-darwin9, and it seemed to > DTRT - so it would be useful to establish what it was that did not work > before, that was fixed by the patch. > > /src-local/gcc-git-11/configure > --prefix=/opt/iains/powerpc-apple-darwin9/gcc-11-3Dr2d > --build=powerpc-apple-darwin9 --enable-languages=all --with-tune-cpu=G5 > --enable-libphobos --with-libphobos-druntime-only > CC=powerpc-apple-darwin-gcc CXX=powerpc-apple-darwin-g++ > --with-build-time-tools=/opt/iains/powerpc-apple-darwin9/gcc-11-3Dr2d/bin > > Without the > "--with-build-time-tools=/opt/iains/powerpc-apple-darwin9/gcc-11-3Dr2d/bin" > the system linker and assembler are found and used (which fails to work with > D, causing a bootstrap fail) with the option, the relevant tools are found > and bootstrap succeeded.... > > (so I am not sure what the original problem was > since $build is not specified in the summary, I guess we must assume it was > i686-pc-cygwin so perhaps the problem is specific to that setup?) Alexandre Oliva's assessment is that the issue was just one having an old build left over, and that all the patch did was to force a rebuild: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599169.html (so we might be going with his patch instead)
(In reply to Eric Gallager from comment #7) > > Alexandre Oliva's assessment is that the issue was just one having an old > build left over, and that all the patch did was to force a rebuild: > https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599169.html > (so we might be going with his patch instead) So, current patch status is that we've got an idea that I just need to test, along with possibly extending it to similar cases: https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599354.html