PengZheng commented on PR #441:
URL: https://github.com/apache/celix/pull/441#issuecomment-1241842269
> Nice, yes this can work. Around 2011-2013 we did some experiment with
updating the NEEDED and SONAME flags and in that experiment it did work. But
updating the NEEDED/SONAME entry is difficult of the string size needs to
increased, so for the experiment we only updated NEEDED to something small
(libfoo->ab1, libbar->ab2, etc).
> If I remember correctly we did not follow up this approach, because we had
bigger things to tackle. But I agree if we can tackle this we are creating
something "magical" for the C/C++ word :).
Unlike `chrpath`, `patchelf` has no such limitation. For example:
```peng@hackerlife:~/Downloads/hello_solib/cmake-build-debug/impl1$ readelf
-d libhello.so
Dynamic section at offset 0x2e10 contains 25 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000e (SONAME) Library soname: [libhello.so]
peng@hackerlife:~/Downloads/hello_solib/cmake-build-debug/impl1$ patchelf
--set-soname libhello.so.1.0.0 ./libhello.so
peng@hackerlife:~/Downloads/hello_solib/cmake-build-debug/impl1$ readelf -d
libhello.so
Dynamic section at offset 0x2e10 contains 25 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000000e (SONAME) Library soname: [libhello.so.1.0.0]
```
> I also did some experiment with dlmopen, but because this start with a
completely clean symbol space (so no symbols from the executable) IMO this is
also not a real solution.
If accessing symbol from the executable is a requirement, there is a
conflict here: any shared object imported as bundle can not be linked to the
main executable or any of the executable's link-time dependencies, otherwise it
will pollute the global link-map list (aka namespace). That means shared
objects exported by bundles can only be used within the celix framework, once
it's used, any external use will be forbidden. Given that, why not just export
its functionality as service at the first place?
On Linux, I think there is another way of doing this without such
limitations. Use the dark Linux magic `man 7 rtld-audit`:
```
la_symbind*()
The return value of la_symbind32() and la_symbind64() is the address
to which control should be passed after the function returns. If the auditing
library is simply monitoring symbol bindings, then it should return
sym->st_value. A different value may be returned if
the library wishes to direct control to an alternate location.
```
Theoretically, we can get complete control of dynamic symbol resolution,
bind any symbol reference to wherever we want. But this feature is not
available on MacOS.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
