https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866
--- Comment #3 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #2)
> > --- Comment #1 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
> > I backported a fix from the D sources so it should no longer segfault at
> > least.
>
> It doesn't indeed.
>
> > From what I can see, it should pick up the object.d source correctly.
> >
> > -nostdinc -I /vol/gcc/src/hg/trunk/local/libphobos/libdruntime
> >
> > Unless it really isn't in the -I path.
>
> I've found what's going on:
>
> When d-incpath.dd (add_globalpaths) calls into Filename::canonicalName
> (path), path is set correctly to the d21 -I arg:
>
> 81 const char *target = FileName::canonicalName (path);
> (gdb) p path
> $7 = 0x9f33878 "/vol/gcc/src/hg/trunk/local/libphobos/libdruntime"
>
> (gdb) s
> 0x0833cea6 in FileName::canonicalName (
> name=0x9f33878 "/vol/gcc/src/hg/trunk/local/libphobos/libdruntime")
> at /vol/gcc/src/hg/trunk/local/gcc/d/dmd/root/filename.c:616
> 616 return realpath(name, NULL);
> (gdb) n
> 83 if (target == NULL || !FileName::exists (target))
> (gdb) p target
> $8 = 0x0
>
> However, canonicalPath returns with NULL. I traced this to realpath(3C)
> on Solaris 10 behaving differently, as explained in the man page:
>
> bolic links. The generated pathname is stored as a null-
> terminated string, up to a maximum of {PATH_MAX} bytes
> (defined in limits.h(3HEAD)), in the buffer pointed to by
> resolved_name.
>
> RETURN VALUES
> On successful completion, realpath() returns a pointer to
> the resolved name. Otherwise, realpath() returns a null
> pointer and sets errno to indicate the error, and the con-
> tents of the buffer pointed to by resolved_name are left in
> an indeterminate state.
>
> Unlike e.g. the Solaris 11.4 version, realpath doesn't allocate a buffer
> on it's own if the second arg is NULL, but given that it couldn't store
> the real path, returned NULL to indicate that failure.
>
> Rainer
OK, I guess I should be using libiberty here instead of the front-end's
provided FileName functions here, and probably in other places.
