openal-soft doesn't build without pthread-emb about psplibraries

[sharkwouter]

https://github.com/pspdev/psptoolchain/projects/1#card-36352804 seems related to this

[isage]

Since pthread is implemented by newlib

Is it, though? newlib implements posix-threads only when targeting windows (cygwin).

[sharkwouter]

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]

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]

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]

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]

It doesn't make upgrading newlib more difficult. Headers live in sys/psp.

[fjtrujy]

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]

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]

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]

Here is the related issue: #83

[fjtrujy]

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.