https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot
Uni-Bielefeld.DE> ---
> --- 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
