If you run `xbps-rindex -Rx android-studio` you will see the dependencies which it currently has:
```
libGL>=0
musl>=0.9.9_1
glibc>=2.25_1
openjdk-jre>=8u20_1
freetype>=2.3.9_1
libgcc>=4.4.0_1
libXext>=1.0.5_1
libX11>=1.2_1
libXrender>=0.9.4_1
libXtst>=1.0.3_1
libXi>=1.2.1_1
alsa-lib>=1.0.20_1
```
So these are the same which you explicitly list, except for `musl>=0.9.9_1`.
Running `sudo xbps-install -d -S android-studio` reveals that the reason for the failing dependency tracking is the dependency on `libc.so` which is provided by the `musl` package, but not by `glibc`.
I don't know if the workaround to set `noverifyrdeps=yes` and explicitly listing the dependencies is a good choice to deal with the underlying problem, @voidlinux/pkg-committers ?
@pullmoll, If I understand correctly linking directly to `libc.so` is not valid in terms of glibc.
I checked my Debian sid chroot with `objdump -p bin/* usr/bin usr/sbin 2>/dev/null | grep libc.so | sort | uniq`:
```
NEEDED libc.so.6
required from libc.so.6:
```
Same on Void Linux with glibc.
I belive `libc.so` entries come from Android shared libraries included in archive. See https://github.com/voidlinux/void-packages/issues/9830#issuecomment-369981172
Those are for Android system. Should we collect deps for them?
If there are libs inside the android-studio binary package which are not required for the target system (x86_64 or i686), they should be removed from the `$DESTDIR/usr/lib/...` in `post_install()`.
I'll have a look at it to see if I can get rid of that wrong dependency this way.
@pullmoll My guess: `libperfa.so` are added to Android .apk to provide perfomance metrics while in development. So it is part of Android Studio functionality.
I'm not really acquainted with Android or smart phones at all. I don't even have one.
The problem here seems to be that libperfa.so is detected as a runtime dependency for the host, while it is meant to be run on a target device or emulation?
IMO we need to find a way to exclude specific libs from the reverse dependency scanning happening in `04-generate-runtime-deps.sh`. Then adding `libperfa.so` to such a list should result in a useable list of runtime dependencies.
> IMO we need to find a way to exclude specific libs from the reverse dependency scanning happening in 04-generate-runtime-deps.sh. Then adding libperfa.so to such a list should result in a useable list of runtime dependencies.
Besides `04-generate-runtime-deps.sh` does not test shared library architecture, should it?
(Just checked: Android Studio 3.1 released already)
Yes, it doesn't check architecture. Yes it should. Current hack to work around bogus dependencies is to add an common/shlibs entry (see 7cece6a8dd3d0b079f1aa4f9e0e8130a8fa0a706 for example)
@pullmoll, is it okay to use filename only? Perhaps it is better to use glob or full path (in case `a/libwhatever.so` needed but not `b/libwhatever.so`)?
@Pretch I just wanted to write that down :)
Full path would be the safest, yes.
I think we could add this to the the `common/=E2=80=A6` scripts, even if it=
's just another hack.
IMO better than modifying templates to entirely skip the dependency scannin=
g and fail on the next update due to a `depends=3D=E2=80=A6` entry missing.
--=20
You are receiving this because you are on a team that was mentioned.
Reply to this email directly or view it on GitHub:
https://github.com/voidlinux/void-packages/pull/12766#issuecomment-380149085=
@Pretch: it's there and sitting in the pipe. I could install my locally built android-studio-3.0.1_2 here. The builders are currently stalled, so it will take some time.
Now I need to document `skiprdeps` in the `Manual.md` file...
@pullmoll, awww, sorry. I thought you just closed this. Noticed just now that you actually commited.
I'am not that familiar with GitHub (or even contributing, seens it's my first one).
Thanks for investigation!
You're welcome. I uploaded my locally built xbps to https://repo.voidlinux.de/current/nonfree in case you want to try using `xbps-install -R <thatrepo>`.