[PATCH] libdrm: intel/Android.mk: Filter libdrm_intel library requirements on x86/x86_64

Rob Herring robh at kernel.org
Fri Mar 16 14:35:48 UTC 2018


On Wed, Mar 14, 2018 at 12:21 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 14 March 2018 at 16:47, John Stultz <john.stultz at linaro.org> wrote:
>> When building AOSP after updating libdrm project to the
>> freedesktop/master branch, I've seen the following build errors:
>>
>> external/libdrm/intel/Android.mk: error: libdrm_intel
>> (SHARED_LIBRARIES android-arm64) missing libpciaccess
>> (SHARED_LIBRARIES android-arm64) You can set
>> ALLOW_MISSING_DEPENDENCIES=true in your environment if this is
>> intentional, but that may defer real problems until later in the
>> build.
>>
>> Using ALLOW_MISSING_DEPENDENCIES=true when building allows
>> things to function properly, but is not ideal.
>>
>> So basically, while I'm not including the libdrm_intel package
>> into the build, just the fact that the Android.mk file references
>> libpciaccess which isn't a repo included in AOSP causes the build
>> failure.
>>
>> So it seems we need some sort of conditional filter in the
>> Android.mk to skip over it if we're not building for intel.
>>
> Could swear I asked a few times already, but cannot see an answer.
> Why/how does this happen - did you forget to set BOARD_GPU_DRIVERS?
>
> One way to avoid this kind of clutches like is to have meta drivers
> like "arm-all" or "x86-all".
>
> Some examples:
>  - the Mesa i965/anv drivers will not build for arm

They used to...

>  - the Mesa vc4 (even vc5?) driver has some perf. sensitive arm/thumb assembly
>  - building the following combinations is waste of resources -
> i915/i965/i915g on !x86, freedreno/etnaviv/imx on !arm

I disagree. To use the kernel as an example, it is very valuable to
have your driver code build for x86 allmodconfig even if it is
something that never runs on x86 because lots of people and bots build
that.

If you require having ARM cross compilers and environment setup to
build test "arm" drivers in mesa/libdrm, then you've really cut down
the number of people doing build testing. Just look at Android build
testing. I can count the number of people that do that on one hand.

> Without something like my earlier suggestion all of the above will
> need to be special cased. And more are to come with time :-\
>
> That is, unless I'm loosing my marbles. In which case don't be shy and
> let me know, please.

I think this has been beaten to death and will apply it. It's an easy
revert if someone has an itch to come up with something better.

Rob


More information about the dri-devel mailing list