Gábor Boskovits writes: > I just pushed what I have right now. It's on branch gcc-ddc on my github. > Should I post a patch here?
Great! Yes, that makes commenting on it an easy option. Also, please mention the location to clone from. github is non-free, but cloning from it is ok. janneke > > 2017-11-21 0:16 GMT+01:00 Gábor Boskovits <boskov...@gmail.com>: > > The only problematic one seems to be standard_libexec_prefix, because > that is used in line 3654 of gcc/ > gcc.c in a real assignment. > It is also used in line 64 of gcc/gcc-ar.c. > > Other uses of all these other symbols could be calculated as compile time > realitve paths, and if we can live > with these paths staying in the same store directory, then it would be > ok. > > This problematic use pattern is in the from: > > x=make_relative_prefix(y,standard_exec_prefix,standard_libexec_prefix); > if(!x) x=standard_libexec_prefix; > > Code of make_relative_prefix is in libiberty/make-relative-prefix.c. > > Assuming sane values (not nulls, existing program name, valid > GCC_EXEC_PREFIX) we get null in the following > cases: > 1. GCC_EXEC_PREFIX(or the program name directory > component)==standard_exec_prefix > 2. if the path present in standard_exec_prefix and > standard_libexec_prefix has no common directories > (starting from the beginning) > 3. in case of allocation failure. > > We can safely assume that case 2 does not happen, as we at least have > /gnu/store there, I think. > Nothing can be done about case 3, I don't think we get too far in that > case anyway... > > So, when this happens we simply have case 1: we are not relocated. > > In gcc/gcc.c this pattern is guarded by if(gcc_exec_prefix) basically.(it > is in an else block) > It is not so in gcc/gcc-ar.c. > > This is how far I could get with it by now. > > 2017-11-20 23:14 GMT+01:00 Ricardo Wurmus <rek...@elephly.net>: > > Jan Nieuwenhuizen <jann...@gnu.org> writes: > > > Gábor Boskovits writes: > > > > Hey Gábor! > > > > [cc: guix-devel] > > > >> I'm definietly making progress on this. Now I have a working debug > build of gcc. > >> Identified the critical symbols, they are: > > > >> static const char *const standard_exec_prefix = > STANDARD_EXEC_PREFIX; > >> static const char *const standard_libexec_prefix = > STANDARD_LIBEXEC_PREFIX; > >> static const char *const standard_bindir_prefix = > STANDARD_BINDIR_PREFIX; > > > > Oh nice! > > > >> The problem fundamentally is that they are calculated from prefix > passed to configure. > >> I've checked, that that is the store location. > > > > Right. > > > >> How should we go on with this? > >> > >> Is it possible to pass other value as prefix, or should we keep > prefix as is, and patch the makefile? > >> It is set from line 2092 in gcc/Makefile.in by the way. > > > > Good question. I think we should try patching the Makefile.in. > > I’m just throwing this in, even though I suspect that it is a terrible > idea: we could replace these symbols with calls to getenv and provide > the values at runtime with a separate wrapper that would be excluded > in > the comparison. > > -- > Ricardo > > GPG: BCA6 89B6 3655 3801 C3C6 2150 197A 5888 235F ACAC > https://elephly.net > -- Jan Nieuwenhuizen <jann...@gnu.org> | GNU LilyPond http://lilypond.org Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com
