Build fail for 7.3.0 with in-tree binutils

[Matt Godbolt]

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@gmail.com>
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