forums.ps2dev.org

What cflags did you need to change? Please be more specific so we can actually be helpful to other people rather than just making your one setup work.

Regarding freetype, libtoolize should create config.guess but I suppose it's not. What version of libtool do you have?

It's in the Sony kernel on the PSP. It is missing many C functions.

libc should certainly include fopen, fclose, etc. Maybe the toolchain never finished building newlib?

No -- but since there have been no objections I'm gonna give it a try.
It's committed in rev 2470 now.

Also see http://forums.ps2dev.org/viewtopic.php? ... light=clip

You'd get that if you had an old version of the toolchain script. How did you obtain it? You should use the latest version from svn.

So, does anyone feel like rehashing the old bust-the-hypervisor-to-load-homebrew-code discussion? I'm not saying rush out and do it, I'm just observing that many arguments against it have just been made obsolete. :) I agree, I think this is the most likely side effect of their decision. In practice...

That sucks. I was going to get one... now it's a lot less tempting.

A preferable way to make the patch would be to make the changes to the SVN repository, running "svn add" etc to add new files, and then send the output of "svn diff".

coolkehon wrote:why didn't anyone add my ports of SDL libraries to the repos =(

Post a patch against svn to the patch submissions forums and someone will review & commit. Otherwise scattered postings are likely to get lost.

Was there ever a reason why the PSP SDL port wasn't submitted to Lantinga for inclusion into the official tree? Seems like it'd avoid bit rot better... Just laziness I suppose. To me, bit rot didn't seem like that big of a problem given that many of SDL's changelog entries relate to specific OS and...

You can try to track down why makeinfo wasn't detected, or follow instructions like http://forums.ps2dev.org/viewtopic.php? ... t=makeinfo to just work around the bug.

Install texinfo
(like it says)

As I already said, that does not show any actual errors. You'll have to find the actual error, which is probably in earlier output, or config.log, or any other generated files.

Disabling the stack protector should definitely fix the "gcc 4.4.1" trace that you posted -- with it disabled, such a trace should never happen. If you're still seeing it, I suspect your CFLAGS settings aren't getting applied to the binutils compilation correctly.

Another thing to try is adding to the CFLAGS. Or porting to the PSP a newer version of binutils that has the psp-ar bug fixed.

I don't think anyone is specifically working on it, but if you want to port the updates and post the patches, I'll look over and commit them.

First, it's failing at newlib, not binutils or gcc. Yes it is, it is psp-ar crashing while building newlib. psp-ar is part of binutils. Changing your build options when you build binutils will likely avoid the bug in psp-ar. The second post was showing that using a version of gcc newer than 4.1.2 c...

There are toolchain gcc/binutils bugs... Try modifying the scripts to add CFLAGS=-O0 when compiling the toolchain gcc and binutils, see if that helps anything.

You can find some info at http://hitmen.c02.at/files/yapspd/psp_doc/
In general, addresses like this and how they're used are found by reverse-engineering the Sony kernel and binaries to see how they work.

I start to understand what sceHprmEnd (and ather) call do but I did not find any documentation. Not even inside sdk's header files. Function prototype are declared at the top of code so I imagine locator will know (and solve) addresses to call.. Is there some function docs ? Where ? Prefix 'sce' st...

I think there was an earlier error that was omitted. Please post the full output (at least the last 100 lines).

You do need the @1088. Check the section Resurrecting Deleted Items in the Subversion book, as well as the difference between Peg and Operative Revisions.

Including all dependencies is done so that "make" works correctly. As you noticed, without proper dependencies, it can fail if (for example) the rules are in a different order.

This is kernel 2.6.27. Anyway, back to square one (or my first post in this thread rather). No, we're not back to square one, you're just not listening. On Linux, 128MiB is available immediately and the additional 112MiB is hotplugged during the boot process. All 240MiB is available to applications...

^ spam

I was trying to checkout libAac from revision 1088 which was deleted in 1089 but it keeps saying it doesn't exist. Can't seem to copy and past from this stupid window... I can checkout previous revisions of existing stuff though. It works fine here: svn co -r1088 svn://svn.ps2dev.org/psp/tr...

It's a hardware crypto engine. There's no crypto code executing on the MIPS CPU while it's waiting for the Kirk to come up with a result, so there's nothing that a CPU breakpoint could possibly see.

Since that's only used for compiling the toolchain itself and should have no effect on generated PSP binaries, maybe that should be default. It's certainly the easiest fix. Any objections?

Because you haven't provided a proper patch in the "Patch Submissions" forum.