Hi! I only had a curious look here; hope that's still useful.
On 2021-09-22T16:30:42+0100, Andrew Burgess <andrew.burg...@embecosm.com> wrote: > The top-level configure script is shared between the gcc repository > and the binutils-gdb repository. > > The target_configdirs variable in the configure.ac script, defines > sub-directories that contain components that should be built for the > target using the target tools. > > Some components, e.g. zlib, are built as both host and target > libraries. > > This causes problems for binutils-gdb. If we run 'make all' in the > binutils-gdb repository we end up trying to build a target version of > the zlib library, which requires the target compiler be available. > Often the target compiler isn't immediately available, and so the > build fails. I did wonder: shouldn't normally these target libraries be masked out via 'noconfigdirs' (see 'Handle --disable-<component> generically' section), via 'enable_[...]' being set to 'no'? But I think I now see the problem here: the 'enable_[...]' variables guard both the host and target library build! (... if I'm quickly understanding that correctly...) ... and you do need the host zlib, thus '$enable_zlib != no'. > The problem with zlib impacted a previous attempt to synchronise the > top-level configure scripts from gcc to binutils-gdb, see this thread: > > https://sourceware.org/pipermail/binutils/2019-May/107094.html > > And I'm in the process of importing libbacktrace in to binutils-gdb, > which is also a host and target library, and triggers the same issues. > > I believe that for binutils-gdb, at least at the moment, there are no > target libraries that we need to build. > > My proposal then is to make the value of target_libraries change based > on which repository we are building in. Specifically, if the source > tree has a gcc/ directory then we should set the target_libraries > variable, otherwise this variable is left entry. > > I think that if someone tries to create a single unified tree (gcc + > binutils-gdb in a single source tree) and then build, this change will > not have a negative impact, the tree still has gcc/ so we'd expect the > target compiler to be built, which means building the target_libraries > should work just fine. > > However, if the source tree lacks gcc/ then we assume the target > compiler isn't built/available, and so target_libraries shouldn't be > built. > > There is already precedent within configure.ac for check on the > existence of gcc/ in the source tree, see the handling of > -enable-werror around line 3658. (I understand that one to just guard the 'cat $srcdir/gcc/DEV-PHASE', tough.) > I've tested a build of gcc on x86-64, and the same set of target > libraries still seem to get built. On binutils-gdb this change > resolves the issues with 'make all'. > > Any thoughts? > --- a/configure.ac > +++ b/configure.ac > @@ -180,9 +180,17 @@ target_tools="target-rda" > ## We assign ${configdirs} this way to remove all embedded newlines. This > ## is important because configure will choke if they ever get through. > ## ${configdirs} is directories we build using the host tools. > -## ${target_configdirs} is directories we build using the target tools. > +## > +## ${target_configdirs} is directories we build using the target > +## tools, these are only needed when working in the gcc tree. This > +## file is also reused in the binutils-gdb tree, where building any > +## target stuff doesn't make sense. > configdirs=`echo ${host_libs} ${host_tools}` > -target_configdirs=`echo ${target_libraries} ${target_tools}` > +if test -d ${srcdir}/gcc; then > + target_configdirs=`echo ${target_libraries} ${target_tools}` > +else > + target_configdirs="" > +fi > build_configdirs=`echo ${build_libs} ${build_tools}` What I see is that after this, there are still occasions where inside 'case "${target}"', 'target_configdirs' gets amended, so those won't be caught by your approach? Instead of erasing 'target_configdirs' as you've posted, and understanding that we can't just instead add all the "offending" ones to 'noconfigdirs' for '! test -d "$srcdir"/gcc/' (because that would also disable them for host usage), I wonder if it'd make sense to turn all existing 'target_libraries=[...]' and 'target_tools=[...]' assignments and later amendments into '[...]_gcc=[...]' variants, with potentially further variants existing -- but probably not, because won't you always need the target GCC to be able to build target libraries ;-) -- and then, where we finally evalue '$target_libraries' and '$target_tools', only evaluate the '[...]_gcc' variants iff 'test -d "$srcdir"/gcc/'? (All that completely untested, of course...) Grüße Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
