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?
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].