[oi-dev] Problems with packages and drm

Alexander Pyhalov alp at rsu.ru
Wed Dec 28 09:08:07 UTC 2016

On 12/28/16 12:03 AM, randyf at sibernet.com 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: 

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

More information about the oi-dev mailing list