> 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
