On 12/28/16 12:03 AM, [email protected] wrote:
On Tue, 27 Dec 2016, Alexander Pyhalov wrote:
Gordon, it seems the following patch fixes the issue:
https://github.com/pyhalov/gfx-drm/commit/b1ebcc82b300cdb4abd4ad83b0b1b832758fb73f
Current patch mechanism in gfx-drm is ugly, so I had to update also
another patch, touching *.pc.in files, but it's as sepate issue.
Also this patch fixes one compilation warning:
https://github.com/pyhalov/gfx-drm/commit/b30075dd1203a123a871687281c2dc1f38fe956e
(seems to appear only in debug build).
As this issue affects oi-userland build, I'd appreciate if someone
committed this (or another) fix for https://www.illumos.org/issues/7692
At one time usr/include/drm was a symlink to usr/include/libdrm (still
is in Oracle Solaris), you might look into something that changes with
the new drm bits to see if that link got broken.
That said, the continued use of usr/include/libdrm is probably
unnecessary as any external software wants to find includes in
<drm/...>. As part of future restructuring, usr/include/libdrm will
probably be removed in favor of either of both of usr/include/drm and
usr/include/uapi/drm (as is the case for much of the upstream work). So
you might consider for these fixes to put all the headers in
usr/include/drm and have this as the sole include path outside of
usr/include and will be easier to maintain with your upstream providers.
Hi, Randy.
Thanks for you response.
I've updated suggested fix:
https://github.com/pyhalov/gfx-drm/commit/877deaccd71e636b0cb1d06613724131378d49c1
.
As you suggested, now we install all drm headers to /usr/include/drm and
create symlink /usr/include/libdrm -> drm.
This allowed me rebuild mesa without rerunning configure (and of course,
running it).
--
Best regards,
Alexander Pyhalov,
system administrator of Southern Federal University IT department
_______________________________________________
oi-dev mailing list
[email protected]
https://openindiana.org/mailman/listinfo/oi-dev
