Build fail for 7.3.0 with in-tree binutils

[Jonathan Wakely]

On 25 January 2018 at 19:02, Matt Godbolt wrote:
> On Thu, Jan 25, 2018 at 12:58 PM, Jonathan Wakely <jwakely.gcc@gmail.com>
> wrote:
>>
>> On 25 January 2018 at 18:47, Matt Godbolt wrote:
>> > 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.
>>
>> Nope, quite the opposite. GCC uses no absolute paths except for system
>> dirs like /usr/include and /usr/lib (and they can be re-configured, or
>> avoided altogether with a sysroot).
>>
>> > I'd love to use a more traditional installation
>> > process and then "relocate" once it's moved to the ultimate destination?
>>
>> Moving it to the ultimate destination *is* the relocation, there's
>> nothing else needed.
>>
> [snip]
>
> I see, that's what I'm already doing[1]. But without an in-tree binutils,
> the binutils doesn't come along for the ride :)

But it does if you install both to the same --prefix=/some/empty/dir
and then move everything under /some/empty/dir to a new location. The
two packages move together, and so GCC still finds the binutils
binaries at the same relative paths as it expects to.


> I'll combine an out-of-tree
> binutils with the compiler, and then have two packages within my deployment
> system to track both binutils and the compiler and ensure they find each
> other.

There's no need for two packages, just treat the entire contents of
/some/empty/dir as a single gcc+binutils package.

I'll send you a pull request ...

> Thanks for your patience, I'm glad I wasn't too far off piste!
>
> Cheers, Matt
>
> [1]
> https://github.com/mattgodbolt/compiler-explorer-image/blob/master/gcc/build/build.sh#L140
>