[oi-dev] Problems with packages and drm

[Gordon Ross]

Do we really need the libdrm symlink?
I assumed we could have just .../include/drm


On Wed, Dec 28, 2016 at 4:08 AM, Alexander Pyhalov <alp at rsu.ru> wrote:
> 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:
> 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
> oi-dev at openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev