Hi all,
Sorry for the late reply. Yes, the old patch of mine is required in libdrm/master if you are to build it with aosp/oreo-mr1-release as it now expects libdrm_platform.so. I will rebase it and submit. (of course considering Rob's patch)
> Strange I though we already have both issues addressed?
> Admittedly the /vendor move was recent, although the static build of
> libdrm (for recovery) has been around for ages.
>
> Аre you saying that despite that it's around latest AOSP does not pick it up?
> Can you share a bit more light on the topic?
> Admittedly the /vendor move was recent, although the static build of
> libdrm (for recovery) has been around for ages.
>
> Аre you saying that despite that it's around latest AOSP does not pick it up?
> Can you share a bit more light on the topic?
My patch was needed because in some of the products (aosp_arm64_ab, aosp_walleye, aosp_taimen, etc.) in O-MR1 turned a build option called 'BOARD_VNDK_VERSION' on. When the option is on, the build system ensures that any vendor module isn't using a system module and any system module isn't using a vendor module. For example, after Rob's patch, libminui can't use libdrm.so because libminui is not in the vendor partition, but libdrm.so has moved to vendor partition. So, it is a system->vendor violation. Before Rob's patch, libminui -> libdrm is okay, but libdrm_<vendor>.so -> libdrm.so isn't okay as it is a vendor->system violation. Of course, this does not trigger an error for the products which don't set BOARD_VNDK_VERSION.
FYI. Starting from P, this will again be changed (in a good way).
[1] is changing the build scripts to Android.bp and eliminates the need for declaring two lib definitions for the same source code.
cc_library {
name: "libdrm",
vendor_availalbe: true,
...
}
The 'vendor_available: true' internally makes two variants of libdrm.so (one in /system/lib and the other in /vendor/lib) and modules in system or vendor are linked to the appropriate variant of libdrm.so depending on their origin. As a result. the platform version of libdrm has been renamed back to libdrm.so and that is reflected to [2].
On Tue, Dec 12, 2017 at 4:28 AM, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote:
On 11 December 2017 at 03:51, Chih-Wei Huang <cwhuang@xxxxxxxxxxxxxxx> wrote:
> Please rebase to the latest master and re-submit the patch.
> In particular, please consider the master already has
> a Rob Herring's patch which moved libdrm* to /vendor.
>
This please.
>
>
> 2017-07-26 18:08 GMT+08:00 Jiyong Park <jiyong@xxxxxxxxxx>:
>> libdrm_<vendor>.so are moved to the vendor partition (/vendor/lib or
>> /system/vendor/lib if there is no dedicated vendor partition), since
>> they are vendor-specific extension that must not be in the system
>> partition which should be generic.
>>
>> libdrm.so (which is generic) is built/installed twice: once to
>> /vendor/lib to satisfy the dependency for the libdrm_<vendor>.so libs
>> and once to /system/lib for platform clients such as the recovery
>> executable.
>>
Strange I though we already have both issues addressed?
Admittedly the /vendor move was recent, although the static build of
libdrm (for recovery) has been around for ages.
Аre you saying that despite that it's around latest AOSP does not pick it up?
Can you share a bit more light on the topic?
Thanks
Emil
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
