> Date: Sun, 18 Dec 2005 11:49:37 -0500 > From: Daniel Jacobowitz <[EMAIL PROTECTED]> > > 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.
Heh, the shell does set PWD, but does not export it. If I explicitly say "export PWD", before "make bootstrap" it seems to work. > I've been considering disabling ln -s support. It's too fragile, > though this is the first report of it actually failing I've seen by > email; someone mentioned similar problems on IRC. Don't know how many broken shells are out there. Actually, I don't think the OpenBSD sh(1) is broken, at least not according to POSIX. Is explicitly exporting PWD at an appropriate point an option? Mark