[Bug d/87866] gdc fails to compile minimal test

[ibuclaw at gdcproject dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87866

--- Comment #3 from Iain Buclaw <ibuclaw at gdcproject dot org> ---
(In reply to ro@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.