On 25 January 2018 at 19:02, Matt Godbolt wrote: > On Thu, Jan 25, 2018 at 12:58 PM, Jonathan Wakely <jwakely.gcc@xxxxxxxxx> > 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 >
