forums.ps2dev.org

I recently installed the Win32 PS2dev setup by 'Loser', as found on this site. It came with PS2LIB, which I have kept for backwards compatibility. I've then installed PS2SDK, also as found on this site. (Naturally I keep those libs in separate folders to avoid conflicts.) Thereafter I have compiled some projects for each of those lib collections to verify that the basic installation of all this was successful. So far so good. The basic installation is OK.

However, as I proceeded to test various projects I found several problems, most of which are due to deprecated and conflicting compilation options. For example, I have major problems in trying to compile the 'Boredom' demo (as found on this site). Some of this I can solve myself, but I can't solve it all without some help, so I'll describe the details below, in the hope that some of you can recognize what I need to do.

'makefile.native' contains three variables to control the options sent to the compilation tools, ASFLAGS, CFLAGS, LDFLAGS, for assembler, compiler and loader, respectively. The last of them is not a problem (yet ;) ), but the first two are. Both contain an option '-mcpu' although this is differently defined for gas and gcc. For gas, I changed it from "-mcpu=5900" to "-cpu-type=r5900" which I HOPE (but don't know) is the right thing to do now that the '-mcpu' option of gas is deprecated. Assemblies do seem to work with that anyway. For gcc I keep this option unchanged as "-mcpu=r5900" as that remains valid, and that too works fine for 'pure' C code, but I kept getting more errors.

One error which confused the issue was due to the gcc flag "-fnonnull-objects" for which I found conflicting info on the net. Some docs don't mention it at all, but instead mention an option "-fno-nonnull-objects" with the opposite effect, so apparently different compiler versions have different default behaviour. This issue is further confused by the fact that many sites refer to that option as deprecated, but never say this about the first option, even though it certainly seems to be deprecated in our version of gcc (unrecognized option). Whatever, my only recourse here is to simply remove that option, at risk of decreasing code efficiency by some redundant NULL checks. Doing this did eliminate those errors anyway, but now as I got past those I found a much worse problem.

"main.c" contains some inline assembly code, which had been entered as one long quoted string, which is a deprecated format. Fortunately that was easy to fix by removing the existing quotes and inserting '"' at the start of each asm line and adding '/n"' at the end of each such line. But even though this eliminated that error, another error persisted. I'm quoting this error on the line below, as it is the one thing I have NO cure for.

"/cygdrive/e/PS2_Dev/gcc/ee/bin/../lib/gcc-lib/ee/3.2.2/../../../../ee/bin/as: unrecognized option '-mcpu=r5900'"

This looks a bit confusing, but it simply means that the gas version stored as "/cygdrive/e/PS2_Dev/gcc/ee/ee/bin/as" has been invoked with that option, even though I already changed the ASFLAGS variable to avoid that. This is logical too, considering that the 'make' tool isn't really involved in the automatic invocation of the assembler to deal with inline assembly, but that raises the question of where the heck this FAULTY option is defined, as that component must be modified now that this option is deprecated.

I have no definite answer to that question myself, and even if I did there isn't much I could do about it... I strongly suspect it's gcc itself that contains this option, hardcoded into the routine that invokes gas.

I hope someone else can come up with a more definite answer, and (better yet) a remedy.

Best regards: dlanor

Your post was a bit wordy, so I didn't read through all of it but here's what I got:

I'm trying to build ancient projects with ancient tools and link them with modern libraries.

Those ancient projects need major retrofitting to work with ps2sdk. The ancient tools aren't so much a problem today, but the libraries seem to be shifting to work with GCC 3.x only, so those ancient tools could stop working in the future.

If you're looking for demos or apps to compile with ps2sdk, search these forums for the emulators or the recent news items of ps2dev.org.

Well, all these issues are "well known". Moving from the old toolchain to the new one did break lots of old packages which nobody ever bothered porting. So, hum, please, feel free to submit any porting patch to any old package :) And also, feel free to look at newer packages to see how to do (like ps2link)

mrbrown wrote:Your post was a bit wordy, so I didn't read through all of it but here's what I got:

It was a bit wordy, but if I don't describe both what works and what doesn't, I know that I'll only get queries about that instead of a proper answer. (And rightly so, as proper answers require those facts.)

I'm trying to build ancient projects with ancient tools and link them with modern libraries.

Just for the record, that isn't a quote of anything I wrote.

The Boredom demo project may well be ancient, but I don't see why you call my tools ancient as well. As stated in my last post, I used the Win32 installer by 'Loser' downloaded from ps2dev.org. This is the newest set of PS2DEV tools for Win32 available at this site, since the Lukasz package is based on older compiler versions, so how can my tools be too ancient ? I just don't get it...

Those ancient projects need major retrofitting to work with ps2sdk.

I'm sure that's true, but I was using PS2LIB, which that project was designed for.

The ancient tools aren't so much a problem today, but the libraries seem to be shifting to work with GCC 3.x only, so those ancient tools could stop working in the future.

But I use GCC version 3.2.2, so why is that a problem ?

If you're looking for demos or apps to compile with ps2sdk, search these forums for the emulators or the recent news items of ps2dev.org.

Thanks for the tip, but I already have lots of other sources from this site, some downloaded through CVS and some as normal ZIPs, so that's not my problem.

My real problem is that inline assembly resulted in an option being passed to gas in some way that I have no control over. What I really want to know is how to control that option.

Best regards: dlanor

pixel wrote:Well, all these issues are "well known".

Good! Can you please tell me how those options for gas are controlled ?
(I mean the options passed by gcc to gas for inline assemblies.)

Moving from the old toolchain to the new one did break lots of old packages which nobody ever bothered porting. So, hum, please, feel free to submit any porting patch to any old package :)

I don't think generic patches will be possible except for some few straight option replacements in makefiles. Really adapting an old project to use newer libs will probably require lots of individual patches not applicable to other projects. Note however that this is NOT what I was attempting to do. The Boredom demo was designed to use PS2LIB, and that is what I tried to compile it with as well.

And also, feel free to look at newer packages to see how to do (like ps2link)

I've been looking at lots of new packages too, but I'm still mystified by the error I described.

Best regards: dlanor

( http://forums.ps2dev.org/viewtopic.php?t=153 )

1) If you get an error about -mcpu, just change it to -march.

It sounds like -cpu-type is just a new way of saying -mcpu. *shrug*

ooPo wrote:( http://forums.ps2dev.org/viewtopic.php?t=153 )

1) If you get an error about -mcpu, just change it to -march.

Thanks! That does work, and I think I understand the problem now.

Apparently GCC associates some of its own options with corresponding GAS options, and uses this association to select options for inline asm. So when I used -mcpu for GCC (which is not deprecated) it passed that on to GAS (where it is deprecated). So the reason for my problems was that inconsistency in deprecation.

It sounds like -cpu-type is just a new way of saying -mcpu. *shrug*

I agree, and for invoking GAS directly it seems to work fine, but as this option isn't valid for GCC it must be better to use -march consistently for both.

The thing about this problem that was important to me wasn't to get the demo compiled with any particular options, but for me to understand why these asm options were used. I think I do understand it now, so this problem is solved.

Best regards: dlanor

A lot of these little problems came about by changing gcc 2.x to gcc 3.x. You should probably google around for what's changed to get an idea of what kind of problems you'll run into.

Enjoy!