[OE-core] [PATCH] virglrenderer: fix compiling failure with `-fvisibility=default'

Hongxu Jia hongxu.jia at windriver.com
Sun May 19 15:04:41 UTC 2019


On 5/19/19 10:30 PM, Hongxu Jia wrote:
> On 5/19/19 6:10 PM, Alexander Kanavin wrote:
>> On Sun, 19 May 2019 at 07:01, Hongxu Jia <hongxu.jia at windriver.com> 
>> wrote:
>>> +Extern global variable `util_cpu_caps' to multiple C source files is
>>> +not a good habit, it caused linking failure when making a shard object
>>> +in some cross compiling circumstance
>>> +...
>>> +|ld: gallium/auxiliary/.libs/libgallium.a(u_cpu_detect.o): relocation
>>> +R_386_GOTOFF against undefined symbol `util_cpu_caps' can not be used
>>> +when making a shared object
>>> +|ld: final link failed: bad value
>>> +...
>>> +
>>> +Covert global variable to static and assign it only in one C source 
>>> file,
>>> +provide get function for other C source files
>>> +
>>> +Upstream-Status: Submitted [virglrenderer-devel at lists.freedesktop.org]
>> I do not actually see the submission here:
>> https://lists.freedesktop.org/archives/virglrenderer-devel/2019-May/date.html 
>>
>
> Here is the mailing list reply
>
> ...
>
> Your mail to 'virglrenderer-devel' with the subject
>
>     [PATCH] fix symbol `util_cpu_caps' can not be used when making a
> shared object
>
> Is being held until the list moderator can review it for approval.
>
> The reason it is being held:
>
>     Post by non-member to a members-only list
>
> Either the message will get posted to the list, or you will receive
> notification of the moderator's decision.  If you would like to cancel
> this posting, please visit the following URL:
>
> https://lists.freedesktop.org/mailman/confirm/virglrenderer-devel/131d0999373561efdb12c196276096402856dbc7
>
> ...
> //Hongxu
>
>> I think the patch should be submitted as a merge request here:
>> https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests
>>
I also submit a merge request

https://gitlab.freedesktop.org/virgl/virglrenderer/merge_requests/239

//Hongxu

>> and I would rather wait for upstream to accept it, and then take it in
>> oe-core as a backport.
>>
>> Alex
>
>



More information about the Openembedded-core mailing list