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. > 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
