sharkwouter
commented
2 years ago https://github.com/pspdev/psptoolchain/projects/1#card-36352804 seems related to this
Open sharkwouter opened 2 years ago
sharkwouter
commented
2 years ago https://github.com/pspdev/psptoolchain/projects/1#card-36352804 seems related to this
isage
commented
2 years ago Since pthread is implemented by newlib
Is it, though? newlib implements posix-threads only when targeting windows (cygwin).
sharkwouter
commented
2 years ago I'm not quite sure what it implements, but it's not enough to drop pthread-emb, but installing pthread-emb will overwrite a header file from newlib. This makes it so psp-pacman cannot install it, so it was a blocker there. I think @fjtrujy has found a solution for it in his fork of the psp toolchain.
fjtrujy
commented
2 years ago I'm not quite sure what it implements, but it's not enough to drop pthread-emb, but installing pthread-emb will overwrite a header file from newlib. This makes it so psp-pacman cannot install it, so it was a blocker there. I think @fjtrujy has found a solution for it in his fork of the psp toolchain.
Exactly, so the current Pthread embedded overrides some headers from newlib, it has issues when using pacman, but using the override property, it works
isage
commented
2 years ago newlib header files should be synchronized with pthread-emb. pthread-emb should override newlib headers, as it's the only working implementation (newlib only has headers). honestly, i think pthread-emb should be part of toolchain, not a separate package
fjtrujy
commented
2 years ago newlib header files should be synchronized with pthread-emb. pthread-emb should override newlib headers, as it's the only working implementation (newlib only has headers). honestly, i think pthread-emb should be part of toolchain, not a separate package
I think that synchronize newlib header with pthread embedded headers is a waste of time.... making future upgrades of newlib more difficult.
The problem is that for compiling pthread embedded you require to have pspsdk already, however with the new toolchain implementation one of the major points is to separate the dependency between the toolchain and the pspsdk, so I think that pthread can not be part of the toolchain, unfortunately.
In my opinion, the only valid and perfect way of using pthread is to include them as part of the pspsdk where we just implement the pthread as it is defined in the newlib headers, that's all (but it requires a lot of work and dedication).
Thanks
isage
commented
2 years ago It doesn't make upgrading newlib more difficult. Headers live in sys/psp.
fjtrujy
commented
2 years ago It doesn't make upgrading newlib more difficult. Headers live in sys/psp.
I know, but you have a bigger newlib patch. I prefer to have thing as much as possible mainstream, to see if they can be merged.
Anyway, what do you earn putting "legacy pthread headers" in "newlib"?
isage
commented
2 years ago How are they legacy, pthread-emb being the only working impl? R/n buildscripts fail to even build pthread-emb. The one in pspsdk and the one in vitasdk (which i kept compatible and buildable with pspsdk and they were working fine like couple of months ago)
fjtrujy
commented
2 years ago I don't know where you want to go.....
As probably you know I'm doing a big change in the whole psptoolchain, making it more POSIX.
If there are things that you don't like, as usual PR are more than welcome.
I just can tell you that with my current approach (still pending to create all the PRs) RetroArch which uses pthread is working as expected, not sure if there are other issues
sharkwouter
commented
2 years ago Here is the related issue: https://github.com/pspdev/psplibraries/issues/83
fjtrujy
commented
2 years ago This is why I still think that the best solution is to do a new pthread implementation in pspsdk repo, generating libpthread.a that satisfies the newlib headers.
However this isn't a easy task.
Since pthread is implemented by newlib, it would make sense if openal-soft could build without the pthread-emb library installed. This is unfortunately not the case.
Here the build log: