| Message ID | 20230225030813.3885661-1-benl@squareup.com |
|---|---|
| Headers | show |
| Series | build: fix compile issues against non-glibc | expand |
On Sat, Feb 25, 2023 at 4:08 AM Benjamin Li <benl@squareup.com> wrote: > > Fix issues when building against a C library other than glibc, such as > Android's Bionic libc. The basename() patch isn't needed on master. > > A commit with a sample Android.bp file that's working against Android 11 is > included for informational purposes, which I don't expect Bartosz to pull. > > Benjamin Li (3): > tools: use getprogname() when available to remove dependency on glibc > core: add missing #include for basename() > build: add Android.bp to build within Android tree > > Android.bp | 126 +++++++++++++++++++++++++++++++++++++++++++ > configure.ac | 5 ++ > lib/core.c | 1 + > tools/gpiodetect.c | 4 +- > tools/gpiofind.c | 4 +- > tools/gpioget.c | 4 +- > tools/gpioinfo.c | 4 +- > tools/gpiomon.c | 4 +- > tools/gpioset.c | 4 +- > tools/tools-common.c | 12 +++-- > tools/tools-common.h | 4 +- > 11 files changed, 154 insertions(+), 18 deletions(-) > create mode 100644 Android.bp > > -- > 2.25.1 > I applied patch 2/3 as it's a fix. For the rest of them - my goal for the v1.6.x series is to not support it anymore, than is absolutely necessary - that means no new features and android build looks like one to me. Any chance you can carry this locally? For v2.x I'm open to adding it but have a couple comments, see the relevant email threads. Bart
On 2/25/23 6:10 AM, Bartosz Golaszewski wrote: > I applied patch 2/3 as it's a fix. For the rest of them - my goal for > the v1.6.x series is to not support it anymore, than is absolutely > necessary - that means no new features and android build looks like > one to me. Any chance you can carry this locally? Sure, we don't mind. But I'd like to gently remind that a lot of device manufacturers like us have platforms that are unfortunately stuck on older kernel versions that don't have the v2 IOCTLs. Are there plans to introduce backwards compatibility to libgpiod v2 to support pre-5.10 kernels without v2 IOCTLs? I assume no based on your talk from July since there's a major data model re-architecture. Anyways, as an aside it would be nice to note in the README about the 5.10-or-later requirement for libgpiod v2 (apologies if it's mentioned and I missed it). I didn't learn about the compatibility gap until I tested libgpiod v2 tools on-device and found that they failed without a sufficiently new kernel. Bummer as I was looking forward to being able to reference GPIOs by just the labels in the CLI! > > For v2.x I'm open to adding it but have a couple comments, see the > relevant email threads. Thanks, will respond there. Ben > > Bart
On Mon, Feb 27, 2023 at 9:56 PM Benjamin Li <benl@squareup.com> wrote: > > On 2/25/23 6:10 AM, Bartosz Golaszewski wrote: > > I applied patch 2/3 as it's a fix. For the rest of them - my goal for > > the v1.6.x series is to not support it anymore, than is absolutely > > necessary - that means no new features and android build looks like > > one to me. Any chance you can carry this locally? > > Sure, we don't mind. But I'd like to gently remind that a lot of device > manufacturers like us have platforms that are unfortunately stuck on > older kernel versions that don't have the v2 IOCTLs. > Ah, right. Android again. :) Does the android build file need to live in the top source directory? Can it go into a separate contrib/ directory where this kind of less maintained stuff could go? > Are there plans to introduce backwards compatibility to libgpiod v2 > to support pre-5.10 kernels without v2 IOCTLs? I assume no based on > your talk from July since there's a major data model re-architecture. > Not really, as the previous uAPI is quite limited and a lot of features of libgpiod v2 would no longer work. > Anyways, as an aside it would be nice to note in the README about the > 5.10-or-later requirement for libgpiod v2 (apologies if it's mentioned > and I missed it). Sounds good I will add it. Unfortunately it's impossible to know the kernel version at build-time so configure checks are useless. We also carry our own copy of the kernel uAPI headers for other reasons so checking the target's headers won't fly either. Bart > > I didn't learn about the compatibility gap until I tested libgpiod v2 > tools on-device and found that they failed without a sufficiently new > kernel. Bummer as I was looking forward to being able to reference > GPIOs by just the labels in the CLI! > > > > > For v2.x I'm open to adding it but have a couple comments, see the > > relevant email threads. > > Thanks, will respond there. > > Ben > > > > > Bart
On 2/27/23 1:01 PM, Bartosz Golaszewski wrote: > Ah, right. Android again. :) > > Does the android build file need to live in the top source directory? > Can it go into a separate contrib/ directory where this kind of less > maintained stuff could go? Yeah, that should work as far as I understand. I'll test it out and re-send the Android build file patch if this works out. > Sounds good I will add it. Unfortunately it's impossible to know the > kernel version at build-time so configure checks are useless. We also > carry our own copy of the kernel uAPI headers for other reasons so > checking the target's headers won't fly either. Thanks! Ben > > Bart