Skip to content

enhance(ndk-multilib): Adding more libraries. closes #25201 #25202

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

MohammedKHC0
Copy link
Contributor

@MohammedKHC0 MohammedKHC0 commented Jun 29, 2025

Adding libraries that are supported by Android 7.
EGL, GLES(v1,v2,v3), vulkan, camera2ndk, mediandk, jnigraphics, OpenMAXAL OpenSLES.
See https://developer.android.com/ndk/guides/stable_apis
This libraries are needed when cross compiling some stuff.

Closes: #25202

Copy link
Contributor

@robertkirkman robertkirkman left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this would be needed for some things when you are cross-compiling from one Android architecture to another Android architecture. however there are also other files like libmediandk.so and libOpenSLES.so and libGLESv2.so that can sometimes be needed for some programs, but for that other architecture.

however this package was supposed to be minimal so, to me, it seems ok to add additional libraries only when they are needed for something, and mark what they are needed for.

Based on that, this seems OK to me, but could you just add a comment stating which command it is you run, that needs this specific libandroid.so to work (build), but builds successfully while using this PR?

@MohammedKHC0
Copy link
Contributor Author

It just happens when you try to link with libandroid.
And most libraries link against it.
This command reproduces it

echo "int main() {return 0;}" > main.c
cc main.c -target x86_64-linux-android -landroid                   
ld.lld: error: /system/lib64/libandroid.so is incompatible with elf_x86_64
cc: error: linker command failed with exit code 1 (use -v to see invocation)

BTW yes it might be worth it to add libGLESv2. But I didn't test it.

In my case I was trying to build macroquad (Rust game library) using a sample project.
And as it seems it does not link against libGLESv2. But it uses Open gl. Is that even possible?

@robertkirkman
Copy link
Contributor

robertkirkman commented Jun 29, 2025

And as it seems it does not link against libGLESv2. But it uses Open gl. Is that even possible?

It is possible for some kinds of programs. It can happen if the program depends on a windowing framework or engine, that itself depends on libGLESv2, but abstracts it so that the main() function of the program itself does not directly depend on Opengl.

Here is an interesting example I have collected:

cat > non-gl.c << 'EOF'
// Code in this file obtained from Darkyre

#include <stdio.h>
#include <SDL2/SDL.h>

const int WIDTH = 800, HEIGHT = 600;

int main(int argc, char *argv[]) {
  SDL_Window *window;
  SDL_Renderer *renderer;
  if(SDL_Init(SDL_INIT_EVERYTHING) < 0) {
    printf("SDL_Init failed: %s\n", SDL_GetError());
    return 1;
  }
  printf("SDL Initialized\n");
  window = SDL_CreateWindow("Hello, World!",
                                        SDL_WINDOWPOS_UNDEFINED,
                                        SDL_WINDOWPOS_UNDEFINED,
                                        WIDTH, HEIGHT,
                                        SDL_WINDOW_ALLOW_HIGHDPI);
  if(window == NULL) {
    printf("Could not create window: %s\n", SDL_GetError());
    return 1;
  }
  printf("Window Created\n");

  renderer = SDL_CreateRenderer(window, -1, 0);
  SDL_SetRenderDrawColor(renderer, 255, 0, 0, 255);
  SDL_RenderClear(renderer);

  SDL_RenderPresent(renderer);
  
  printf("SDL_GetCurrentVideoDriver: %s\n", SDL_GetCurrentVideoDriver());

  SDL_Event event;
  while(1) {
    if(SDL_PollEvent(&event)) {
      if(event.type == SDL_QUIT) {
        break;
      }
    }
  }

  SDL_DestroyWindow(window);

  SDL_Quit();
  return 0;
}
EOF
clang -o non-gl non-gl.c $(pkg-config --libs sdl2) $(pkg-config --cflags sdl2)
./non-gl
	libSDL2-2.0.so => /data/data/com.termux/files/usr/lib/libSDL2-2.0.so
	libdl.so => /system/lib64/libdl.so
	libc.so => /system/lib64/libc.so
	libm.so => /system/lib64/libm.so
	libiconv.so => /data/data/com.termux/files/usr/lib/libiconv.so
	libX11.so => /data/data/com.termux/files/usr/lib/libX11.so
	libXext.so => /data/data/com.termux/files/usr/lib/libXext.so
	libXcursor.so => /data/data/com.termux/files/usr/lib/libXcursor.so
	libXi.so => /data/data/com.termux/files/usr/lib/libXi.so
	libXfixes.so => /data/data/com.termux/files/usr/lib/libXfixes.so
	libXrandr.so => /data/data/com.termux/files/usr/lib/libXrandr.so
	libXss.so => /data/data/com.termux/files/usr/lib/libXss.so
	libwayland-egl.so => /data/data/com.termux/files/usr/lib/libwayland-egl.so
	libwayland-client.so => /data/data/com.termux/files/usr/lib/libwayland-client.so
	libwayland-cursor.so => /data/data/com.termux/files/usr/lib/libwayland-cursor.so
	libxkbcommon.so => /data/data/com.termux/files/usr/lib/libxkbcommon.so
	libdecor-0.so => /data/data/com.termux/files/usr/lib/libdecor-0.so
	ld-android.so => /system/lib64/ld-android.so
	libxcb.so => /data/data/com.termux/files/usr/lib/libxcb.so
	libXau.so => /data/data/com.termux/files/usr/lib/libXau.so
	libXdmcp.so => /data/data/com.termux/files/usr/lib/libXdmcp.so
	libandroid-support.so => /data/data/com.termux/files/usr/lib/libandroid-support.so
	libXrender.so => /data/data/com.termux/files/usr/lib/libXrender.so
	libffi.so => /data/data/com.termux/files/usr/lib/libffi.so

you can notice that it doesn't link directly to Opengl, but it's internally rendered by Opengl. That's because SDL2 is actually what's Dynamically Loading OpenGL ES:

https://github.com/libsdl-org/SDL/blob/2bc3ec44b1b41fdd41b97d17afa16754579c1502/src/video/x11/SDL_x11opengles.c#L56

https://github.com/libsdl-org/SDL/blob/4217d62fa20195959489afec32ed2d9d8753c96e/src/video/SDL_egl.c#L353-L360

Sometimes, SDL2 "can't find" OpenGL ES, and then that can become a problem. but if everything is working, then everything is OK!

@MohammedKHC0
Copy link
Contributor Author

Thanks for the info and your time!
I really appreciate that all of you guys always provide strangers (like me) with informations and takes from your time. For free!

So what do you think?
Should we add LIBGLESV2 Just in case. Or maybe even add all libraries but into another package.
In either way i think libandroid.so should be available inside ndk-multilib since most libraries would choose to link to it.

@MohammedKHC0
Copy link
Contributor Author

BTW what is ld-android.so?
It seems that sdl2 links against it.

@robertkirkman
Copy link
Contributor

So what do you think?
Should we add LIBGLESV2 Just in case. Or maybe even add all libraries but into another package.
In either way i think libandroid.so should be available inside ndk-multilib since most libraries would choose to link to it.

To be honest I'd say add libGLESv2.so and libmediandk.so to it also, just in case they are needed (for cross-compiling), and then if anyone ever needs one of the other ones that isn't covered by that, they could open an issue and we would find out. I don't think these folder paths interfere with any non-cross-compilation situation.

@robertkirkman
Copy link
Contributor

robertkirkman commented Jun 29, 2025

BTW what is ld-android.so?

I am pretty sure that /system/lib64/ld-android.so is Android's nearly equivalent file to GNU/Linux's file /usr/lib64/ld-linux-x86-64.so.2.

It is a kind of loader library for the C and C++ programming languages.

https://man7.org/linux/man-pages/man8/ld.so.8.html

(all C and C++ programs and even other programs)

Here is an example of a Rust program, oxlint is a Rust program:

~/code $ ldd $(command -v oxlint)
	libdl.so => /system/lib64/libdl.so
	libm.so => /system/lib64/libm.so
	libc.so => /system/lib64/libc.so
	ld-android.so => /system/lib64/ld-android.so
~/code $ 

Even Rust programs have a dependency on C or C++ - On operating systems that are written in C or C++.

There is, for Rust, basically a way to get around this by using a Rust-only operating system, the largest example of which is Redox OS, so one of the neat abilities of Redox OS is that C is optional in it as far as I'm aware, and all the core programs are not linked to libc or the C loader at all.

That is pretty much the extent of what I know about this unfortunately but I am happy it was helpful for you.

Adding all the libraries that are supported by Android 7.
@MohammedKHC0
Copy link
Contributor Author

MohammedKHC0 commented Jun 29, 2025

Thanks @robertkirkman for your explanation, and your time. Again i really appreciate it.

After some rethinking i think we should add all libs that are supported by Android 24.
see https://developer.android.com/ndk/guides/stable_apis
The libs are not that much actually and it's size is very low.
This adds about 1.5mb to the size of the uncompressed files. I doubt that this will effect the .deb size.
the libraries are EGL, GLES(v1,v2,v3), vulkan, camera2ndk, mediandk, jnigraphics, OpenMAXAL OpenSLES.

What do you think, Is this fine?

@MohammedKHC0 MohammedKHC0 changed the title enhance(ndk-multilib): Adding libandroid.so. closes #25201 enhance(ndk-multilib): Adding more libraries. closes #25201 Jun 29, 2025
# Those are all the *other* libs that are supported by android api 24.
libs+=" lib{camera2ndk,mediandk,jnigraphics}.so"
libs+=" lib{EGL,GLESv1_CM,GLESv2,GLESv3,vulkan}.so"
libs+=" lib{OpenMAXAL,OpenSLES}.so"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Unfortunately, when I look at the build artifact, it contains some strange files, I think it might be because of the {,} symbols being inside the "" symbols here,

it might be necessary to figure out a different way to write this part that doesn't attempt to use the {,} symbols inside of the "" symbols.

image

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you need help to do this, I could try pushing into this branch to fix that problem, let me know if that's ok with you,

There is also another question/concern I have after this, but I don't like to overwhelm with too many comments at once so I take the testing one step at a time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants