Error, could not fixup imports, stubs out of order.
Ensure the SDK libraries are linked in last to correct this error
C:\pspsdk\bin\make.exe: *** [ne0h_sdk.elf] Error 1
It means the link order is "wrong". You'll have to try shuffling things around and hoping you find the magic order that makes that error go away. Please note that sometimes it is just impossible to make that error go away.
Not always! There was a music playing prx I was trying work on, and it WOULD NOT work without linking pspkernel FIRST, but then you'd get that error. Trying to move pspkernel in the link order made three or four other libs fail to link. I tried every possible order and nothing would work. I thought about looking into updating the program that does that linking (I even started a thread on it), but it was too much hassle and I had more pressing issues. The fact of the matter is that sometimes you get those import errors and nothing you can do will fix them. :(
J.F. trust me on this, there is _always_ a way of getting it to work. I just guess you didn't understand the ramifications of how the linker does its job. Of course it is a limitation on the import system (I take responsibility) and its mechanism to handle stripped down imports, but it is better to get that error (and then you can fix it, trust me, even if you have to play with link orders) then before when it didn't check and it just created broken elfs :)
As for why it isn't working for ne0h I would assume some of it is down to the fact that you are using scePower_driver.o pspDecrypt_imports.o which I assume are import libraries which can cause weirdness with the import linker. You could try adding those to the end of the LIBS link, although what is it in scePower_drive.o which you need which isn't in the one in the SDK?
And another question:
I'm using the sceDisplaySetHoldMode for fadeout effect when launching something, but I haven't found this function prototipe in a library header, why? Or where I can find it?
Last edited by ne0h on Sun Oct 19, 2008 12:14 am, edited 1 time in total.
I didn't check for the NID but a person have sent me an e-mail to inform me that Xplora works great on cfw 5.00, so I think that the NID is not changed!
Pirata Nervo wrote:
sceDisplaySetHoldMode is not in the sdk probably because no one added it yet :P
TyRaNiD, another new question:
I'm using psplink to debug apps, but when a try to exit ( type reset or exit with sceKernelExitGame for main app) PSPLink won't reset!
I've see that it is because there's a module ( started by the main app ) that won't be onloaded, or something like this, I've try to do it by the pspsh, but for all the op I've have error "0xDEADBEEF" or similar ( I don't remember )!
Can I resolve this "error"?
Is not very comfortable to have to shutdown the PSP everytime...
Is the module it is starting a kernel one with its own thread? The usual cause of reset locking is down to some kernel thread which doesn't handle correctly a wait state returning an error and causing an infinite loop to occur.
If it is then about the only way to fix it is to try and suspend the thread, if it has its own unique name then thsusp @thread_name is good enough, if it doesn't then you might need to do it manually.
Sorry, I haven't understand...
I've the main module ( PBP ) in VSH mode ( 0x800 ) linked without ctr0, so at the startup it create a user thread, so it load two module, only one give me problems!
This have to do nothing ( only export some functions ), so I've writed some initialization of variables, because I cannot leave module_start black, and finally return...
Anyway this is the code:
ne0h wrote:I didn't check for the NID but a person have sent me an e-mail to inform me that Xplora works great on cfw 5.00, so I think that the NID is not changed!
Pirata Nervo wrote:
sceDisplaySetHoldMode is not in the sdk probably because no one added it yet :P
0x1007 would be kernel mode, unable to stop, single load and single start (which just means that the module can only be loaded and started once).
Is there some use in loading a module and not starting it? Suppose you give only SINGLE_START, then you can load, start and unload it, and then only load it a second time but not start it right?
If I were to guess, I would think that SINGLE_START refers to a singleton. i.e. Only one running in memory at one time. NOT only allowing the module to be run only one time.