I've managed to build LibC++ and link it against the libcinternal using the CXX branch, had few things such as std string/array/atomic working(they probably dont even need the library itself (?) ). but it failed to link when using std::threads due to undefined __dso_handle.
so I've few questions.
would the sdk resolve symbols ptr that are not functions, as is the case above?
if so would that work the same as functions, aka $(eval $(call generateModule, libScePsm, __dso_handle)).
lastly according to this that symbol is in libScePsm.sprx could you confirm that? I would have guessed this would be in Libc or libCInternal :/
edit:
as per this post while not linking to shared libraries it's safe to define __dso_handle manually, so would that be true in our case or would the stub be considered shared libraries, atlas would they be in the case of __dso_handle :/
P.S Zer0xFF
I've managed to build LibC++ and link it against the libcinternal using the CXX branch, had few things such as std string/array/atomic working(they probably dont even need the library itself (?) ). but it failed to link when using std::threads due to undefined
__dso_handle.so I've few questions.
would the sdk resolve symbols ptr that are not functions, as is the case above?
if so would that work the same as functions, aka
$(eval $(call generateModule, libScePsm, __dso_handle)).lastly according to this that symbol is in libScePsm.sprx could you confirm that? I would have guessed this would be in Libc or libCInternal :/
edit:
as per this post while not linking to shared libraries it's safe to define
__dso_handlemanually, so would that be true in our case or would the stub be considered shared libraries, atlas would they be in the case of__dso_handle:/P.S Zer0xFF