search

ptitSeb / box64

Box64 - Linux Userspace x86_64 Emulator with a twist, targeted at ARM64 Linux devices
https://box86.org
MIT License
3.73k stars 267 forks source link

Develop #1556

Closed zohanzephyr closed 3 months ago

ptitSeb commented 3 months ago

This is a C++ library, and cannot be wrapped easily. There is no mecanism for now, in box, to handle vtable and overloadeing, so this wrapping will not work, unless it stays empty, but I assume it's not the goal...

zohanzephyr commented 3 months ago

This is a C++ library, and cannot be wrapped easily. There is no mecanism for now, in box, to handle vtable and overloadeing, so this wrapping will not work, unless it stays empty, but I assume it's not the goal...

Yes, but it will be used when other library functions are relocated, and the current state of keeping it empty can satisfy the use of it, is it possible to first wrapped, and then add the function at a later stage?

ksco commented 3 months ago

Yes, but it will be used when other library functions are relocated, and the current state of keeping it empty can satisfy the use of it, is it possible to first wrapped, and then add the function at a later stage?

hmmm, what's the point if it stays empty? makes no sense.

zohanzephyr commented 3 months ago

Yes, but it will be used when other library functions are relocated, and the current state of keeping it empty can satisfy the use of it, is it possible to first wrapped, and then add the function at a later stage?

hmmm, what's the point if it stays empty? makes no sense.

Screenshot from 2024-06-03 18-04-58 It solves the problem of function relocation

ksco commented 3 months ago

maybe you misunderstood the error message? for example the symbol g_bytes_new_with_free_func does not come from libvips-cpp, it's the caller, not callee.

zohanzephyr commented 3 months ago

maybe you misunderstood the error message? for example the symbol g_bytes_new_with_free_func does not come from libvips-cpp, it's the caller, not callee.

Yes, it's the caller, the actual function definition is not in this library, it's in libglib-2.0.so.0, which involves function relocation, but when I wrapped libglib-2.0.so.0 and didn't wrap libvips-cpp.so.42 it doesn't find the location of the function that is actually defined

ptitSeb commented 3 months ago

All this doesn't changed the fact that c++ lib cannot be wrapped for now. I cannot accept this PR.

It would be more constructive too understand why there is a SEGFAUT when using wrapped glibc.