-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this 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?
It just happens when you try to link with libandroid.
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. |
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 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
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: Sometimes, SDL2 "can't find" OpenGL ES, and then that can become a problem. but if everything is working, then everything is OK! |
Thanks for the info and your time! So what do you think? |
BTW what is ld-android.so? |
To be honest I'd say add |
I am pretty sure that 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,
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.
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. What do you think, Is this fine? |
# 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" |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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