forums.ps2dev.org

OK, Im trying to the the "hello world" from cvs to work with the scr_printf enabled, but it refuses to work out with just adding debug.h to the include.

So, to make it work, I went to the cvs, and took scr_printf.c, font.c and debug.h (renaming the .c to .h for convenience) and then included those instead, and now its working fine.

Did I miss the boat while searching the forum to find out what needed to be done to get scr_printf working? If someone recalls seeing an answer please let me know so I will keep looking instead of using this mess I came up with for Hello World on some other thing...

In which way didn't it work... ?

Maybe someone forgot to add -ldebug to EE_LIBS?

pixel - sorry, I was trying to figure out why the helloworld from cvs wouldnt compile without the scr_printf unREM'd

boomint - that was exactly what I was looking for, thanks!

any idea if these toggles are documented somewhere?

edit: time to do some makefile spelunking

pixel - sorry, I was trying to figure out why the helloworld from cvs wouldnt compile without the scr_printf unREM'd

Pixel was asking for the actual compilation error!

any idea if these toggles are documented somewhere?

These aren't toggles or switches but libraries you wish to link with. As a rule of thumb if you get an "undefined reference to function xxxxxx" chances are you've forgotten to link with the appropriate library, or you have a lib dependancy problem.

So in other words, even though I am using the debug.h I still have to include the "flag" for toggling the include of whatever libxxxx.a file is missing, if it produces errors like that?

Kinda redundant to have to include it separately but nice to know where the actual names of the flags are coming from.

It's not a flag, it's a library.

The header file is just definitions that provide information about how your code interacts with the library, the actual library, or "flag" as you keep calling it, is a binary which is then linked in with yours.

It's really not all that hard to understand...

There are only 15 libs for the ee in ps2sdk (at least in the version I have built). Three of them (libkernel, libsyscall, and libc) are loaded by default in the Makefile.eeglobal provided with ps2sdk.

The remainder are more 'special purpose' libs (e.g., libpad for the gamepad interface, libhdd for the hdd, etc.) For the most part, the libs are named in such a way that you should be able to figure out their purpose, libsbv_patches being the most obvious exception.

Maybe it's a little counter-intuitive that you need to explicitly include the debug lib if you want to have debugging code available (which is just scr_printf and screen capture, IIRC). Oh well, at least you won't get snagged by this again, consider it a learning experience...

Drako - are you trying to say that -ldebug is a library and not libdebug.a file? 7 characters is a little small for a library dont you think? I didnt call the library a flag, I called the -llibrary that needs to be included in the makefile a "flag" for lack of knowing a better word to call it. In a way it IS like a light switch, where including the library is by default OFF, but when you add/define a "flag" it is ON and therefore includes it in the linking. Is that all that hard to comprehend?

mharris - thank you very much for the more explicit info as to when each of these will be needed. I found the dir yesterday when I was reminded that the makefiles needed to be modded to include the librarys when compiling something even so simple as hello world.

(shouldnt the example from the samples dir in CVS/SDK have all this and some comments about it too? I personally would be happy to add in some for the next person who needs to know this info)

heres the patch/addin to the hello.c file

cory1492 wrote:(shouldnt the example from the samples dir in CVS/SDK have all this and some comments about it too? I personally would be happy to add in some for the next person who needs to know this info)

As ps2sdk is always in a state of flux, small problems creep into some areas. This is one such area and is easily remedied - perhaps someone with CVS write access can modify the makefile? :)

And with regard to terminology, lets not have a flame war :) Cory, have a read through the gcc manuals to acquaint yourself - there's plenty of material that you will also find extremely useful for future endeavours.

Cory: you're starting to have a harsh language here, which is quite not welcome where people are trying to explain you things you obviously are not getting right at all (even though I agree a bit on the fact that drakonite's reply was a bit rude).

As boomint suggested, you should indeed look at the gcc manual, since what you just said is completely out of the point and wrong. Compilation phase and linking phase are two completely different processes.


As for the compilation of examples, there's a huge lot more complex examples which actually do compile and run. For example, in the ps2sdk-ports package, there's the ucl library, and a small test program which should compile and run. And there are other mature softwares around which behave the same, like rinco's luagl asteroid port.

Cory: you're starting to have a harsh language here

please provide explicit/specific example(s) so I can avoid this mistake in the future. I do not wish to insult those that wish to help, but at the same time rudeness without info is kinda pointless - as is trying to correct an error that one does not perceive. As well, I apologize for any misunderstanding over terminology.

Compilation phase and linking phase are two completely different processes.

edit-compile-link-debug -took that up in '95 at devry
Both compile and link are done with the makefile - which specifies "flags" or "toggles" or "includes" or "variables" (havent really satisfied my desire to name the TEXT in the makefile that specifies the libraries to be linked, especially since they do not have the exact same name as the actual library - perhaps alias?).

http://www.delorie.com/djgpp/doc/ug/larger/archives.html wrote:To use the library, simply add it to your gcc link line just like you would any other object.
gcc main.c mystuff.a -o main.exe

there's a huge lot more complex examples which actually do compile and run

If I cant get a simple scr_printf going completely on my own, perhaps I have no further business here anyways. Even if there are huge complex programs to compile from CVS (that actually compile) they are useless to me until I get straight the method that was used to create them - from simple to large is generally the best way to go, and gaining some experiences such as checking the "alias' to included libs" in the make file before asking anyone anything or before going off on some odd excursion into manuals

At any rate thats my piece. Sorry if it has wasted any of your valuable dev time. Geeze, spent so long putting this post together and trying to find out what that operand is called I have none left to play with code tonite. Ah well. I should pay more attention to my sig.

edit: forgot to add, "Thanks for the help!!" (hope thats not flamey, thanking people that is), I will spend some time with GCC without an IDE (like the one I had at DeVry) and attempt some less confusing programming for the time being... DOS it is

Term: "compiler links object files into an executable output file" from gcc manual - by far a useful download, thanks again boomint ;)

oooh, they arent flags they are "options" lol

gcc linking options wrote:The linker searches a standard list of directories for the library, which is actually a file named liblibrary.a. The linker then uses this file as if it had been specified precisely by name.

Again, as boomint signaled, ps2sdk is something moving. One doesn't necessary bother fixing the samples, and they are too simple examples anyway. So, if you are not managing to compile a sample, that's prolly not your direct fault; just a proof that we are lazy ass. Anyway, gawd is currently in the process of providing test units to the sdk, which should avoid that kind of problem in the future. And you'll then have more examples of makefiles and code.

On gcc's (or ld) command line, having -lfoobar is the same as having libfoobar.a, and, as you said, the compilation AND the link phase are mixed up. But they are still two different process run separately by gcc, which will split the correct arguments for the correct phases. So, including "debug.h" will only influence on the compilation phase, and adding -ldebug will only influce on the link phase. Both are needed, and that can not be helped in any way.

Anyway, this is also a reason I am telling you to go fetch other projects, which are prolly maintained and working, unlike the very basic examples from the SDK, which we don't bother maintaining since we maybe will have to change them even more in the future (even though I think that a hello world, in the current state of the sdk, shouldn't change any further now...)



Last word: even boomint sensed some seeds of a flame war, so if you really didn't intend to be rude, you managed to be anyway.

I have now tried compiling the following, with directions given with each and with common sense when directions were not provided-please bear in mind I did not spend more than 1/2 hour on this trial-

freetype- compiles OK, not sure if the test file is for ps2 as there is no makefile (forgot to do the ./configure even) or info
libid3tag- compile errors, zlib.h not found in ps2sdk (ill need to see why) - fixed by compiling zlib and putting zlib.h in the sdk include dir (it did not copy itself during zlibs make install)
libjpeg- compile errors, parse errors for at least 3 header files
libmad- compiles, not sure if there is an install phase for ps2sdk though
libpng- a bunch of errors with the libpng.h file
madplay- a bunch of errors on compile
zlib-seems to be the one that works out ok

ucl - compiled, sample compiled, memory read error when run on ps2 via ps2link/inlink
sdl - compile errors, needs gskit files to work out
gskit - compile errors, could not get the libs for sdl... yet (I may have missed some oddly named reame)

so I think my point is this, using the toolchain built from ooPos script with cygwin does not seem to net anything (although I may find a use for zlib yet) that is working from the ports & gskit - and I do not know what is going on with them well enough at this point to really figure out why (aside from the lazyass syndrome that even I suffer from), so I beleive my approach is reasonable - looking at the origional src for ps2sdk and finding functions that I need as I need them and hopefully get them to work in a simple file, than move them into something more complex/ongoing. Of course this assumes that I dont update my local install of the sdk anymore or change versions of the source - which could be a problem if any new developments are forthcoming.

Thinking: do need to go back to an older toolchain that these were built with previously? Would I have better luck learning what I am trying to learn wrather than using the above method?

Freetype originally came from ( http://ps2dev.org/kb.x?T=950 ), which has sample code that draws on the screen. The freetype in cvs came from original port but was ported to the latest version before putting importing.

The only test I did on it myself was to see if a few of the functions in the library worked fine, like requesting a version/etc...

BTW, if you read the README.PS2, it has cut-and-pastable instructions on how to build and install it.

precisely how I did it ooPo, it didnt want to do anything until I did ;-)

It sure would be nice to see ps2link compilable with current sdk, as it has tonnes of code that would make a great sample - hint hint LOL

Ok, I figured Id try something a little more simple than ps2link, and I found some source from pukko for the biosdump util.
Here is what I have:
dumpbios_src
it is (now) working great with the current toolchain (I just recompiled the sdk march 5)

A simple sample I guess, with demonstration of file io and asm added to a c program, but it raises one question:
origional code that did not work: code I used that does work: I only hope that removing the O_WRONLY -or- O_TRUNC isnt going to cause problems - aside from the fact that it will not overwrite any file with the name bios.bin that is in the elf's dir, it will generate an error instead.

Question being: why would it not work with those options included as they were origionally? I note they are still a part of the SDK but am not entirely certain as to what they actually do.

O_WRONLY - open the file for writing only
O_TRUNC - truncate the file (set to zero length) if it already exists
O_CREAT - create the file if it doesn't exist

'man 2 open' or look in K&R for more info, these flags are from standard C

Don't know why dropping O_WRONLY would work, seems to me neither reading nor writing would be allowed in this case... *shrugs*

There might be a bug in the library, or more likely the client you're using. They may have different ideas on the values of the flags.

When you open a file with O_WRONLY, it opens the file with the pointer set to the beginning of the file. This is why you can write to it immediately. Also, some platforms may automatically create/truncate for you regardless of if you specify those options. O_CREAT may be assuming write access.

Thanks for the info, I was assuming the flags were from standard C or C++, but didnt know for certain (- woohoo _actual_flags).

I used the current downloadable (ps2dev.org) ps2link/inlink for server/client (maybe I should have tried xlink too? or ps2client from cygwin?)