Thanks! I'll try 2.29 and see if that does the trick! In the spirit of trying to improve my process: How might one relocate a GCC? My understanding was that once paths had been "baked in" with `--prefix` they were set in stone. I'd love to use a more traditional installation process and then "relocate" once it's moved to the ultimate destination? Thanks so much! --matt On Thu, Jan 25, 2018 at 12:18 PM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> wrote: > On 25 January 2018 at 17:29, Jonathan Wakely wrote: > > On 25 January 2018 at 17:12, Matt Godbolt wrote: > >> Hi Jonathan, > >> > >> Thanks so much for the reply. I'm somewhat hamstrung insasmuch as I > support > >> both Compiler Explorer and my company's GCC distribution. An in-tree > >> binutils allows me to ship both GCC and binutils together easily as a > >> tarball (required by both CE and my company's hermetic build system). > >> There's no "install" in either case; I can use the GCC unpacked at a > certain > >> spot in the filesystem and know it uses the binutils it was built with. > This > >> means LTO and all that work, regardless of the host system's binutils, > and > >> the location of their unpacking. > > > > That should still work with my suggestion. > > > > > >> As the unpack path differs on every installation I can't build GCC with > a > >> `--prefix` to that location. This is why I went with an in-tree > binutils in > >> the first instance, the absolute path requirement of `--prefix` was > >> untenable. > > > > Create a directory with mkstemp, install to there, then tar it up and > > remove the temp dir. > > > > It doesn't matter that the final unpacking location isn't where you > > installed to, GCC uses relative paths to find its own binaries, and if > > binutils was installed to the same path then GCC will also find the > > assembler, linker etc. there. > > > >> For what it's worth I've built every other version of GCC from > >> tarballs with in-tree bintuils until GCC 5.5 and 7.3. > >> > >> I don't use arbitrary releases of GCC and binutils, I pick what I > believe is > >> the appropriate version of binutils per GCC release (usually the latest > >> binutils available at the time GCC was released). In this case I'm > building > >> with bintuils 2.29.1 > > > > Which is about 6 months newer than the gcc-7-branch, and has commit > > de837d77bca30483e8e926044fa497e3d49f7972 which syncs binutils with GCC > > trunk. That means binutils expects libiberty to contain > > get_DW_IDX_name, but the libiberty from gcc-7-branch doesn't have > > that. > > This means you could probably just use 2.29, which would be missing > support for a DWARF feature that GCC 7.x doesn't use anyway (I'm not > sure what else is different between 2.29 and 2.29.1, I didn't look). > > I'd still prefer to do things properly with "make install" and then > relocate the result. > > > >> If in-tree binutils isn't supported, it would be ideal if this is > documented > >> somewhere and GCC made to not attempt to compile an in-tree binutils, > >> failing with an error message instead of a very obscure linker error. > > > > It's supported for top-of-tree for both code bases, where the shared > > directories are in sync. > > > > See https://gcc.gnu.org/ml/gcc/2011-12/msg00263.html > -- Matt
