Re: Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks

From: Niveditha Rau <niveditha.rau@oracle.com>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: Alan Coopersmith <alan.coopersmith@oracle.com>,
	Thierry Reding <treding@nvidia.com>,
	Stuart Kreitman <stuart.kreitman@oracle.com>,
	ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: Solaris & [PATCH libdrm 1/2] configure.ac: split -fvisibility and __attribute__((visibility)) checks
Date: Mon, 06 Apr 2015 09:22:09 -0700	[thread overview]
Message-ID: <5522B2B1.4030806@oracle.com> (raw)
In-Reply-To: <alpine.SOC.2.00.1504051054230.8977@sibernet.com>

On 04/05/15 11:33, randyf@sibernet.com wrote:
>
>
> On Sun, 5 Apr 2015, Emil Velikov wrote:
>
>>> Note that the move of KMS drivers to this repo is recent, so there 
>>> is little
>>> history of their evolution.
>>>
>> Right, so things are a few newer than I thought, but still a bit off
>> from upstream drm. Not too shocking though considering the amount of
>> work that goes in there ;-)
>
>   It is a bit overwhelming, so I (currently) tend to scan this list 
> irregularly, and look for some source snapshot for porting reference.
>
>
>> The thing that struck me is that every drm driver comes with its own 
>> version of core drm. Not critisizing, just a bit unusual.
>
>   So technically, only one driver has it's own version, and that is 
> mostly driven by a lack of hardware to verify it continues to work as 
> drm changes (and is slated for removal as the hardware is obsolete and 
> unavailable).
>
>   With (currently) only one other drm driver, it would appear that the 
> drm core is unique to it (and to some extent it is), but the evolution 
> would be to be towards a common drm.
>
>
>>>
>>>   AFAICT, we aren't that bad.  And where we divert is probably more 
>>> driven
>>> by our lack of knowlege at the time than the ability to properly 
>>> converge,
>>> but I have lots of ground to cover before I can properly resolve the
>>> differences.
>>>
>> Afaics you're using the last UMS-capable xf86-video-radeon, so maybe
>> not all places are updated/ported to KMS ? Not a big deal though.
>>
>
>   We're hopeful that this will change in the near future (we have 
> someone working on a radeon KMS port, which is expected to use a 
> common drm).
>
>
>>>
>>>   For the most part, I have no problem with killing off any legacy 
>>> layers
>>> that should go, as we will catch up (we do have the ability to at least
>>> offer a working frozen solution in the intrim).  At least in the 
>>> near term,
>>> there are bodies actively working on getting the above driver source 
>>> in sync
>>> with what the community has.
>>>
>> Great - glad to hear. Meanwhile I've noticed a few workarounds for
>> libdrm in the hg repo:
>> - Force use of GCC and GNU make.
>> - Disabled tests.
>>
>> If you can provide some more information that would be appreciated.
>> Wouldn't mind squashing some bugs :-)
>
IIRC, we had issues with getting drm.7 without using GNU make.   And the 
build of libdrm_radeon was failing without using gcc.  I'll revert back 
to Studio and get you the failures since its been a while having made 
the switch.

We had disabled tests because of parfait failures which is part of our 
build process.  But I think we should be able to enable it now since we 
have an updated version of parfait that we are building with.

Thanks
Niveditha

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel