reusability of your subprojects #366
Comments
|
Yes currently nothing is documented for other usages. Should I create a simple testproject for you? I agree the default manifest is very confusing to use for non Minecraft. Edit CMakeLists.txt if(NOT CMAKE_CXX_STANDARD)
set(CMAKE_CXX_STANDARD 17)
endif()
add_subdirectory(mcpelauncher-linker)
add_subdirectory(libc-shim)
add_executable(linkertest src/main.cpp)
target_link_libraries(linkertest linker libc-shim)main.cpp #include <mcpelauncher/linker.h>
#include <unordered_map>
#include <iostream>
#include <libc_shim.h>
int main(int argc, char const *argv[])
{
linker::init(); // this makes libdl.so available
std::unordered_map<std::string, void*> libc;
std::vector<shim::shimmed_symbol> shimed = shim::get_shimmed_symbols();
for(auto && l : shimed) {
libc[l.name] = l.value;
}
linker::load_library("libc.so", libc); // this makes a basic libc implementation available
linker::load_library("liblog.so", {}); // These are empty stubs libraries without defining any symbols
linker::load_library("libEGL.so", {});
linker::load_library("libstdc++.so", {});
linker::load_library("libm.so", {});
linker::load_library("libOpenSLES.so", {});
linker::load_library("libandroid.so", {});
auto libchandle = linker::dlopen("/path/to/libc++_shared.so", 0); // from android sdk for your cpu
void * handle = linker::dlopen("/path/to/a/cpplib.so", 0);
auto hiandy = (int(*)())linker::dlsym(handle, "hiandy");
std::cout << hiandy() << "/n";
return 0;
}Running this will print a verbose log message (until disabled by default in a cleanup) to stdout, with all error and success messages. |
|
thx, but even with "-m32 -fpermissive" it falls apart :( (this is x86 glibc system, will have to move to armv7 to test the actual .so I want to make work) |
|
my main concern is Worms2Armageddon (conveniently only has armv7 libs... fun, especially with musl having no multiarch, I hope to use qemu architectural chroot on x86 for testing), Ideally I'd like to start a massive project of reimplementing the entire android API atop bona fide linux (would need a lot of help though, it's big), since aside from getting dalvik to build outside old AOSP source tree, that's really the only thing needed to run those apps as natively as java SE (could even map the GUI to GTK to make it more fun for the contributors) |
|
I see you have a big Project, we currently use a fake java native interface and a fake android interface to run this opengl es game, but running an armv7 app is currently only working with libhybris (-m32 is required). Oh I forget to mention you need the clang compiler 9 (or newer), (google dropped gcc support for android, mcpelauncher-linker contains android source code) and c++17 for this project. |
Are you shure? I found · "Added compatibility for Android devices using x86 Intel architecture." To get that x86 apk
PS I don't own that game, but I got poor experience while using qemu-arm with Minecraft PE. |
|
secured x86 libs, no idea what weird version I have on my phone then ok, with clang, I can compile for x86_64 (except libc-shim/src/common.cpp:3:10: fatal error: 'log.h' file not found") I'm afraid clang->gcc and cpp->C is not viable? :P my Project has the issue that it will need a lot of manpower, and I personally don't even know Java, though shimming to C with jni straight away seems justifiable for performance reasons (will have to sacrifice help of Rust evangelistst and "C++ is not that bad reee" people anyway though |
|
[edit: solved] |
|
ouch, I'm stupid... that's the only C file in the whole project, and it needs CFLAGS :D so |
|
so I need to do something about |
|
75% additional of missing code already exist in the mcpelauncher-client.
libGLESv1_CM.so To give me an overview what your game expect to be provided by the launcher, please post the output of |
|
seems like a lot... how do you even filter trough this? also, I'd assume libEGL.so is not needed if it doesn't ask for it? |
Then this means the opengles1 surface was created with java code. Note: You might have luck, libWormsAndroid has a lot of debugging information, not like Minecraft without them. Your app may have more java code than you think.
I look for undefined / used symbols like Calling JNI_OnLoad with a fake, oracle jvm or whatever jvm will initialize the last part of the library, then most operations are java native interface based. MinecraftPE would go on with ANativeActivity_OnCreate, but your app has that in java code, which calls back to native via jni Some notes:
Reference old ndk: Java decompiler tells more const char* libGLESv1_CM_SYMBOLS = {
"glActiveTexture",
"glAlphaFunc",
"glAlphaFuncx",
"glAlphaFuncxOES",
"glBindBuffer",
"glBindFramebufferOES",
"glBindRenderbufferOES",
"glBindTexture",
"glBindVertexArrayOES",
"glBlendEquationOES",
"glBlendEquationSeparateOES",
"glBlendFunc",
"glBlendFuncSeparateOES",
"glBufferData",
"glBufferSubData",
"glCheckFramebufferStatusOES",
"glClear",
"glClearColor",
"glClearColorx",
"glClearColorxOES",
"glClearDepthf",
"glClearDepthfOES",
"glClearDepthx",
"glClearDepthxOES",
"glClearStencil",
"glClientActiveTexture",
"glClipPlanef",
"glClipPlanefIMG",
"glClipPlanefOES",
"glClipPlanex",
"glClipPlanexIMG",
"glClipPlanexOES",
"glColor4f",
"glColor4ub",
"glColor4x",
"glColor4xOES",
"glColorMask",
"glColorPointer",
"glColorPointerBounds",
"glCompressedTexImage2D",
"glCompressedTexSubImage2D",
"glCopyTexImage2D",
"glCopyTexSubImage2D",
"glCullFace",
"glCurrentPaletteMatrixOES",
"glDeleteBuffers",
"glDeleteFencesNV",
"glDeleteFramebuffersOES",
"glDeleteRenderbuffersOES",
"glDeleteTextures",
"glDeleteVertexArraysOES",
"glDepthFunc",
"glDepthMask",
"glDepthRangef",
"glDepthRangefOES",
"glDepthRangex",
"glDepthRangexOES",
"glDisable",
"glDisableClientState",
"glDisableDriverControlQCOM",
"glDiscardFramebufferEXT",
"glDrawArrays",
"glDrawElements",
"glDrawTexfOES",
"glDrawTexfvOES",
"glDrawTexiOES",
"glDrawTexivOES",
"glDrawTexsOES",
"glDrawTexsvOES",
"glDrawTexxOES",
"glDrawTexxvOES",
"glEGLImageTargetRenderbufferStorageOES",
"glEGLImageTargetTexture2DOES",
"glEnable",
"glEnableClientState",
"glEnableDriverControlQCOM",
"glEndTilingQCOM",
"glExtGetBufferPointervQCOM",
"glExtGetBuffersQCOM",
"glExtGetFramebuffersQCOM",
"glExtGetProgramBinarySourceQCOM",
"glExtGetProgramsQCOM",
"glExtGetRenderbuffersQCOM",
"glExtGetShadersQCOM",
"glExtGetTexLevelParameterivQCOM",
"glExtGetTexSubImageQCOM",
"glExtGetTexturesQCOM",
"glExtIsProgramBinaryQCOM",
"glExtTexObjectStateOverrideiQCOM",
"glFinish",
"glFinishFenceNV",
"glFlush",
"glFogf",
"glFogfv",
"glFogx",
"glFogxOES",
"glFogxv",
"glFogxvOES",
"glFramebufferRenderbufferOES",
"glFramebufferTexture2DMultisampleIMG",
"glFramebufferTexture2DOES",
"glFrontFace",
"glFrustumf",
"glFrustumfOES",
"glFrustumx",
"glFrustumxOES",
"glGenBuffers",
"glGenFencesNV",
"glGenFramebuffersOES",
"glGenRenderbuffersOES",
"glGenTextures",
"glGenVertexArraysOES",
"glGenerateMipmapOES",
"glGetBooleanv",
"glGetBufferParameteriv",
"glGetBufferPointervOES",
"glGetClipPlanef",
"glGetClipPlanefOES",
"glGetClipPlanex",
"glGetClipPlanexOES",
"glGetDriverControlStringQCOM",
"glGetDriverControlsQCOM",
"glGetError",
"glGetFenceivNV",
"glGetFixedv",
"glGetFixedvOES",
"glGetFloatv",
"glGetFramebufferAttachmentParameterivOES",
"glGetIntegerv",
"glGetLightfv",
"glGetLightxv",
"glGetLightxvOES",
"glGetMaterialfv",
"glGetMaterialxv",
"glGetMaterialxvOES",
"glGetPointerv",
"glGetRenderbufferParameterivOES",
"glGetString",
"glGetTexEnvfv",
"glGetTexEnviv",
"glGetTexEnvxv",
"glGetTexEnvxvOES",
"glGetTexGenfvOES",
"glGetTexGenivOES",
"glGetTexGenxvOES",
"glGetTexParameterfv",
"glGetTexParameteriv",
"glGetTexParameterxv",
"glGetTexParameterxvOES",
"glHint",
"glIsBuffer",
"glIsEnabled",
"glIsFenceNV",
"glIsFramebufferOES",
"glIsRenderbufferOES",
"glIsTexture",
"glIsVertexArrayOES",
"glLightModelf",
"glLightModelfv",
"glLightModelx",
"glLightModelxOES",
"glLightModelxv",
"glLightModelxvOES",
"glLightf",
"glLightfv",
"glLightx",
"glLightxOES",
"glLightxv",
"glLightxvOES",
"glLineWidth",
"glLineWidthx",
"glLineWidthxOES",
"glLoadIdentity",
"glLoadMatrixf",
"glLoadMatrixx",
"glLoadMatrixxOES",
"glLoadPaletteFromModelViewMatrixOES",
"glLogicOp",
"glMapBufferOES",
"glMaterialf",
"glMaterialfv",
"glMaterialx",
"glMaterialxOES",
"glMaterialxv",
"glMaterialxvOES",
"glMatrixIndexPointerOES",
"glMatrixIndexPointerOESBounds",
"glMatrixMode",
"glMultMatrixf",
"glMultMatrixx",
"glMultMatrixxOES",
"glMultiDrawArraysEXT",
"glMultiDrawElementsEXT",
"glMultiTexCoord4f",
"glMultiTexCoord4x",
"glMultiTexCoord4xOES",
"glNormal3f",
"glNormal3x",
"glNormal3xOES",
"glNormalPointer",
"glNormalPointerBounds",
"glOrthof",
"glOrthofOES",
"glOrthox",
"glOrthoxOES",
"glPixelStorei",
"glPointParameterf",
"glPointParameterfv",
"glPointParameterx",
"glPointParameterxOES",
"glPointParameterxv",
"glPointParameterxvOES",
"glPointSize",
"glPointSizePointerOES",
"glPointSizePointerOESBounds",
"glPointSizex",
"glPointSizexOES",
"glPolygonOffset",
"glPolygonOffsetx",
"glPolygonOffsetxOES",
"glPopMatrix",
"glPushMatrix",
"glQueryMatrixxOES",
"glReadPixels",
"glRenderbufferStorageMultisampleIMG",
"glRenderbufferStorageOES",
"glRotatef",
"glRotatex",
"glRotatexOES",
"glSampleCoverage",
"glSampleCoveragex",
"glSampleCoveragexOES",
"glScalef",
"glScalex",
"glScalexOES",
"glScissor",
"glSetFenceNV",
"glShadeModel",
"glStartTilingQCOM",
"glStencilFunc",
"glStencilMask",
"glStencilOp",
"glTestFenceNV",
"glTexCoordPointer",
"glTexCoordPointerBounds",
"glTexEnvf",
"glTexEnvfv",
"glTexEnvi",
"glTexEnviv",
"glTexEnvx",
"glTexEnvxOES",
"glTexEnvxv",
"glTexEnvxvOES",
"glTexGenfOES",
"glTexGenfvOES",
"glTexGeniOES",
"glTexGenivOES",
"glTexGenxOES",
"glTexGenxvOES",
"glTexImage2D",
"glTexParameterf",
"glTexParameterfv",
"glTexParameteri",
"glTexParameteriv",
"glTexParameterx",
"glTexParameterxOES",
"glTexParameterxv",
"glTexParameterxvOES",
"glTexSubImage2D",
"glTranslatef",
"glTranslatex",
"glTranslatexOES",
"glUnmapBufferOES",
"glVertexPointer",
"glVertexPointerBounds",
"glViewport",
"glWeightPointerOES",
"glWeightPointerOESBounds"
}; |
|
hmm, arc in general seems interesting, but https://chromium.googlesource.com/arc/arc/+/master/mods/android/bionic/libc/arch-nacl might be useful by itself... (bionic translation by google themselves, though not necessarily to glibc) and https://chromium.googlesource.com/arc/arc/+/master/mods/graphics_translation/gles/ |
|
@ChristopherHX so I tried to get libEGL and libGLESv1_CM out of the way, and unfortunately I get I used |
|
Have you created an OpenGL es 1.x Surface?
minecraft-linux uses OpenGL es 2.x which is incompatible with 1.x
|
|
If you have used the eglut backend try replacing EGLUT_OPENGL_ES2_BIT with EGLUT_OPENGL_ES1_BIT |
|
eglut backend complained about gamepad stuff so I just told it to use glfw |
|
Ok, then you can change glfwWindowHint(GLFW_CONTEXT_VERSION_MAJOR, 1);
glfwWindowHint(GLFW_CONTEXT_VERSION_MINOR, 1);// or 0 if it needs 1.0I hope this help you a bit, eglut has some more cross deps from the mcpelauncher-manifest. |
|
still: |
|
You didn't created a window with game-window? (In the same thread) |
|
oh, my bad now I just get |
|
I assume that can be solved by shimming libm.so akin to ? |
|
yes (https://github.com/minecraft-linux/mcpelauncher-core/blob/1a127120a1b7525b5cb86c749fddc1d3a3206483/src/minecraft_utils.cpp#L31, https://github.com/minecraft-linux/minecraft-imported-symbols/blob/master/include/minecraft/imported/libm_symbols.h) or dlopen("libm.so") from |
|
hmm, is there no way to make a generic maybe a macro that would turn to |
|
Is something wrong with your system's dlopen("libm.so.1", 0), dlsym (your resolver), dlclose?Macro should work too if you want.```#define MACRO(name) { #name , (void*)& name }```
|
looks like it might work, but it breaks if some of those functions are not provided |
|
hmm, if I remove the functions it complains about, and fix the macro: I get: (etc) |
well, I don't have any resolver other than the one I used for OpenGL, and I assume that one may be OpenGL specific |
|
ugly c++ mess... no such issues in C :/ |
|
well, finding android libm.so was much easier... next up is "fgetpos", so https://github.com/minecraft-linux/libhybris/blob/fde7864067a3722109b32441376dc2f40df1593d/src/hooks_io.c |
|
hmm, using |
|
It doesn't work, because io_hook.so is not referenced from the calling library. |
|
I've taken just https://github.com/minecraft-linux/libhybris/blob/fde7864067a3722109b32441376dc2f40df1593d/src/hooks_io.c, added missing functions and adapted it to work with linker::load_library, not sure why libc_shim didn't export those symbols |
|
it doesn't have a hard dependency on hybris |
|
next up I had to get real libz.so as well, |
|
@ChristopherHX: I think I may have solved all the undefined references, but I'm not sure I understand how I should proceed with calling |
|
Yes you need now some sort of jni, like fake-jni or openjdk etc. |
|
I think fake-jni might be the best option, but I have no idea where to start... |
|
ok, guess I've got something, but now I get and making a class that does define an entry point seems to not help at all |
|
Remove |
|
I can't help but notice that "vm.printStatistics" doesn't exist |
|
and neither does vm.getClasses... |
|
You are absolutly right, I thought the same same after reading barons readme. Add this to cmake to get debug output |
|
|
what next? |
|
Sorry for the late reply As I don't have the legal right to get your classes.dex of worms android I cannot help you much. To call native non static functions To call static function of a fakejni class call |
Open
Open
This was referenced Apr 18, 2022
Open
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi, the reason I am here is not really mcpe related - I just had a sad realization that libhybris doesn't actually work at all to help run bionic-expecting libs (as one would assume from some descriptions of it), it's actually only your project that managed to hack it to do that. Are you planning to provide (or do you already do so, it's just not documented) a generic (i.e not tied to mcpe) solution to that problem? Since libhybris is clearly not that...
I wanted to investigate, but anything I try to compile, be it the whole thing or just the subprojects, seems to fall apart while throwing random compiler errors. Is this expected on x86_64/aarch64?
The text was updated successfully, but these errors were encountered: