On Sun, 2005-12-18 at 16:49, Daniel Jacobowitz wrote:
> On Sun, Dec 18, 2005 at 01:28:48PM +0100, Mark Kettenis wrote:
> > Looks like the new toplevel bootstrap infrastructure broke
> > bootstrapping on OpenBSD. I get a bootstrap comparison which is
> > caused by differences in the compilation directory encoded in the
> > object files from different stages.
> >
> > Forcing the coplevel configure to use "mv" instead of "ln -s" by setting
> >
> > gcc_cv_prog_ln_s_dir=${gcc_cv_prog_ln_s_dir=no}
> >
> > fixes things. I'm not sure what's the source for this problem, but
> > obviously somewhere OpenBSD is canonicalising a path where most other
> > OSes aren't.
> >
> > This is on OpenBSD/amd64 3.8-current (for which I'm hacking up GCC
> > support right now), but no doubt this won't be different on other
> > OpenBSD ELF platforms, such as OpenBSD/i386.
> >
> > Based on what I see on OpenBSD I fail to understand how the "ln -s"
> > approach could ever work on any OS. Assuming that I'm not the only
> > one trying to bootstrap GCC, I'm obviously missing something, so any
> > hints would be appreciated.
>
> I'm sure you have access to some non-OpenBSD platforms; try it and see
> :-) My guess is that you're using a shell that does not set the
> environment variable 'PWD', or sets it to a canonicalized path; see
> libiberty/getpwd.c.
I think the problem is PWDCMD (defaults to pwd) in the top-level
makefile. If your shell builds in pwd, then things will work. If it
doesn't then you'll get /bin/pwd which gives the canonical path. Bash
has a built-in pwd, and since on Linux /bin/sh is bash in disguise, it
still uses the builtin. A traditional Berkeley sh doesn't do this.
'info pwd' on Linux says:
`pwd' prints the fully resolved name of the current directory.
That is, all components of the printed name will be actual
directory names--none will be symbolic links.
I suspect that if you run a bootstrap of gcc on Linux with
PWDCMD=/bin/pwd it will fail too.
R.
