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
