| Message ID | 20141029103151.GQ10376@tucnak.redhat.com |
|---|---|
| State | New |
| Headers | show |
On 10/29/2014 11:31 AM, Jakub Jelinek wrote: > It would be nice to have libcc1 built just once, not bootstrap it, but > it is a build module, is that possible? > In toplevel configure.ac I'm seeing: > host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim gdb gprof etc expect dejagnu m4 utils guile fastjar gnattools libcc1" Stuff such as texinfo and flex is in host_tools just as a relic of the old Cygnus tree. fixincludes is in there for running it after installation. The ones that matter in the common case are biuntils, gas, ld, gcc, gdb, gnattools and of course libcc1. > shouldn't libcc1 be in build_tools instead? > I mean, it is a library meant to be dlopened by gdb and gcc > plugin that uses that library, so in canadian-cross should be > for the build target, where the resulting compiler will be run > and where gdb will be run. That is host, not build. Build is the system you are on. Say you're cross-building a native mingw compiler and debugger: build = i686-pc-linux-gnu host = i686-pc-mingw (or whatever they use these days) target = i686-pc-mingw You cannot link build-libcc1 (for i686-pc-linux-gnu) into host-gcc or host-gdb. But you surely know this, so perhaps it's me who is missing something.
On 29/10/14 10:31, Jakub Jelinek wrote: > It would be nice to have libcc1 built just once, not bootstrap it, but > it is a build module, is that possible? > In toplevel configure.ac I'm seeing: > host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim gdb gprof etc expect dejagnu m4 utils guile fastjar gnattools libcc1" > shouldn't libcc1 be in build_tools instead? > I mean, it is a library meant to be dlopened by gdb and gcc > plugin that uses that library, so in canadian-cross should be > for the build target, where the resulting compiler will be run > and where gdb will be run. > > Could something like following work? Phil, can you try that? > Perhaps some toplevel Makefile* changes would be needed too. From GDB's point-of-view, as long as we have access to the .so that is built that's all GDB wants. So whichever stage it is produced should be fine. My archaeology into the source repository has not revealed why we needed bootstrap. Perhaps we included it out of a sense of paranoia for testing. I've CC'd Tom on this, so he may have an opinion or insight. From my point of view, I see no value in bootstrapping libcc1 now. It's not a required build to bootstrap GCC. Cheers Phil
On 10/29/2014 11:58 AM, Phil Muldoon wrote: > My archaeology into the source repository has not revealed why > we needed bootstrap. Perhaps we included it out of a sense of > paranoia for testing. I've CC'd Tom on this, so he may have an > opinion or insight. From my point of view, I see no value in > bootstrapping libcc1 now. It's not a required build to bootstrap GCC. Then I agree, I don't think it needs to be bootstrapped. Paolo
On 29/10/14 10:31, Jakub Jelinek wrote: > It would be nice to have libcc1 built just once, not bootstrap it, but > it is a build module, is that possible? > In toplevel configure.ac I'm seeing: > host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim gdb gprof etc expect dejagnu m4 utils guile fastjar gnattools libcc1" > shouldn't libcc1 be in build_tools instead? > I mean, it is a library meant to be dlopened by gdb and gcc > plugin that uses that library, so in canadian-cross should be > for the build target, where the resulting compiler will be run > and where gdb will be run. > > Could something like following work? Phil, can you try that? > Perhaps some toplevel Makefile* changes would be needed too. From a point of view of GDB, as long as in all scenarios above the .so is available in the finished produce that is fine. I will test your patch and report back. Cheers Phil
On 29/10/14 11:24, Phil Muldoon wrote: > On 29/10/14 10:31, Jakub Jelinek wrote: >> It would be nice to have libcc1 built just once, not bootstrap it, but >> it is a build module, is that possible? >> In toplevel configure.ac I'm seeing: >> host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim gdb gprof etc expect dejagnu m4 utils guile fastjar gnattools libcc1" >> shouldn't libcc1 be in build_tools instead? >> I mean, it is a library meant to be dlopened by gdb and gcc >> plugin that uses that library, so in canadian-cross should be >> for the build target, where the resulting compiler will be run >> and where gdb will be run. >> >> Could something like following work? Phil, can you try that? >> Perhaps some toplevel Makefile* changes would be needed too. > > >From a point of view of GDB, as long as in all scenarios above the .so > is available in the finished produce that is fine. I will test your > patch and report back. I built with bootstrap enabled, and also disabled with this patch. In both cases the .so is available. So it looks good. I also ran GDB compile testcases against both .so's and all looks good there too. Cheers Phil
On 29/10/14 14:26, Phil Muldoon wrote: > On 29/10/14 11:24, Phil Muldoon wrote: >> On 29/10/14 10:31, Jakub Jelinek wrote: >>> It would be nice to have libcc1 built just once, not bootstrap it, but >>> it is a build module, is that possible? >>> In toplevel configure.ac I'm seeing: >>> host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim gdb gprof etc expect dejagnu m4 utils guile fastjar gnattools libcc1" >>> shouldn't libcc1 be in build_tools instead? >>> I mean, it is a library meant to be dlopened by gdb and gcc >>> plugin that uses that library, so in canadian-cross should be >>> for the build target, where the resulting compiler will be run >>> and where gdb will be run. >>> >>> Could something like following work? Phil, can you try that? >>> Perhaps some toplevel Makefile* changes would be needed too. >> >> >From a point of view of GDB, as long as in all scenarios above the .so >> is available in the finished produce that is fine. I will test your >> patch and report back. > > I built with bootstrap enabled, and also disabled with this patch. In > both cases the .so is available. So it looks good. I also ran GDB > compile testcases against both .so's and all looks good there too. > > Cheers > > Phil I forgot to ask, I am fine with this patch. I concur with Jakub that building libcc1 as part of bootstrap is not needed. Does anyone else object to removing libcc1.so from bootstrap? Cheers Phil
On 10/29/14 08:32, Phil Muldoon wrote: > On 29/10/14 14:26, Phil Muldoon wrote: >> On 29/10/14 11:24, Phil Muldoon wrote: >>> On 29/10/14 10:31, Jakub Jelinek wrote: >>>> It would be nice to have libcc1 built just once, not bootstrap it, but >>>> it is a build module, is that possible? >>>> In toplevel configure.ac I'm seeing: >>>> host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim gdb gprof etc expect dejagnu m4 utils guile fastjar gnattools libcc1" >>>> shouldn't libcc1 be in build_tools instead? >>>> I mean, it is a library meant to be dlopened by gdb and gcc >>>> plugin that uses that library, so in canadian-cross should be >>>> for the build target, where the resulting compiler will be run >>>> and where gdb will be run. >>>> >>>> Could something like following work? Phil, can you try that? >>>> Perhaps some toplevel Makefile* changes would be needed too. >>> >>> >From a point of view of GDB, as long as in all scenarios above the .so >>> is available in the finished produce that is fine. I will test your >>> patch and report back. >> >> I built with bootstrap enabled, and also disabled with this patch. In >> both cases the .so is available. So it looks good. I also ran GDB >> compile testcases against both .so's and all looks good there too. >> >> Cheers >> >> Phil > > I forgot to ask, I am fine with this patch. I concur with Jakub that > building libcc1 as part of bootstrap is not needed. Does anyone else > object to removing libcc1.so from bootstrap? Not at all... To a large degree libcc1 is driven by your needs, so if you don't need the bootstrap, then let's remove it from bootstrap. jeff
--- configure.ac 2014-10-28 14:39:53.018852391 +0100 +++ configure.ac 2014-10-29 11:27:39.866152791 +0100 @@ -129,7 +129,7 @@ extra_host_args= build_libs="build-libiberty build-libcpp" # these tools are built for the build environment -build_tools="build-texinfo build-flex build-bison build-m4 build-fixincludes" +build_tools="build-texinfo build-flex build-bison build-m4 build-fixincludes build-libcc1" # these libraries are used by various programs built for the host environment #f @@ -141,7 +141,7 @@ host_libs="intl libiberty opcodes bfd re # binutils, gas and ld appear in that order because it makes sense to run # "make check" in that particular order. # If --enable-gold is used, "gold" may replace "ld". -host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim gdb gprof etc expect dejagnu m4 utils guile fastjar gnattools libcc1" +host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim gdb gprof etc expect dejagnu m4 utils guile fastjar gnattools" # libgcj represents the runtime libraries only used by gcj. libgcj="target-libffi \ @@ -2659,11 +2659,18 @@ for module in ${build_configdirs} ; do echo 1>&2 "*** removing ${build_subdir}/${module}/Makefile to force reconfigure" rm -f ${build_subdir}/${module}/Makefile fi + + # Don't bootstrap libcc1 + case $module in + libcc1) build_bootstrap_suffix=no-bootstrap ;; + *) build_bootstrap_suffix=$bootstrap_suffix ;; + esac + extrasub_build="$extrasub_build /^@if build-$module\$/d /^@endif build-$module\$/d -/^@if build-$module-$bootstrap_suffix\$/d -/^@endif build-$module-$bootstrap_suffix\$/d" +/^@if build-$module-$build-bootstrap_suffix\$/d +/^@endif build-$module-$build-bootstrap_suffix\$/d" done extrasub_host= for module in ${configdirs} ; do