| View previous topic :: View next topic |
| Author |
Message |
astfgl
Joined: 13 Jul 2007
Posts: 7
|
 Posted: Mon Jun 21, 2010 11:32 pm Post subject: undefined reference to SDL_ReadLE32 |
 |
|
Hi again,
(I thought two seperate threads might be a good idea...)
I got the idea of porting Maze of Galious to the PS2. First problem is it uses "SDL_sound" lib, hence my first thread. (I worked around that by commenting SDL_sound-calls...)
The second problem is I get strange error I can't interpret...
I'd read them as if the linker can't find some libs (e.g. for reading .bmp). And it seems they are not found while it's linking against SDL libs (which are installed).
Do I have to compile some extra libs from the svn-repo?
If anyone could give me a hand:
Error output
Standard output
Makefile
Thanks a lot!
PS: There are some warnings in the beginning... Feel free to ignore them for now (though I'd like to get rid of those, too). I don't think they are of much priority. |
|
| Back to top |
|
 |
astfgl
Joined: 13 Jul 2007
Posts: 7
|
| Posted: Tue Jun 22, 2010 11:47 pm Post subject: |
|
|
hmm...
After fiddling around the whole night, it seems to work now:
The problem seems to be in the Makefile...
I changed
| Code: |
SDL_LIBS = -lsdl -lsdlmain -lsdlmixer -lSDL_image -lSDL_gfx
|
to
| Code: |
SDL_LIBS = -lsdlmixer -lSDL_image -lSDL_gfx -lsdl -lsdlmain
|
and it seems to work.
Could anybody tell me why that happens?
Why is the order EE_LIBS are loaded important?
Before I ordered those libs from left to right (since I thought that's the order it's parsed), to somehow reflect dependencies (meaning sdl_mixer needs SDL) ... is that wrong?!
Hope somebody can enlighten me! |
|
| Back to top |
|
|
Mega Man
Joined: 18 Jun 2005
Posts: 274
|
| Posted: Fri Jun 25, 2010 9:08 am Post subject: |
|
|
| The order represents the dependencies. Sometimes you need to add a library twice times at different positions to reflect the dependencies. The used linker can also have a reversed order when you are using a higher or lower version of the linker. There are also linker flags which have influence on the behaviour (--start-group). |
|
| Back to top |
|
|
cosmito
Joined: 04 Mar 2007
Posts: 314
Location: Portugal
|
| Posted: Sun Jun 27, 2010 2:01 am Post subject: |
|
|
| Mega Man wrote: | | The order represents the dependencies. Sometimes you need to add a library twice times at different positions to reflect the dependencies. The used linker can also have a reversed order when you are using a higher or lower version of the linker. There are also linker flags which have influence on the behaviour (--start-group). |
I'm also a novice when comes to fighting with makefiles so allow me to take the opportunity to ask you if the order of the EE_OBJS is important. |
|
| Back to top |
|
|
Mega Man
Joined: 18 Jun 2005
Posts: 274
|
| Posted: Mon Jun 28, 2010 7:19 am Post subject: |
|
|
| The order of the object files has influence on the created elf file, but this normally makes no difference as the linker script of the PS2 toolchain is correct. Normally there should be no problems with the order of the object files. |
|
| Back to top |
|
|
astfgl
Joined: 13 Jul 2007
Posts: 7
|
| Posted: Thu Jul 08, 2010 8:58 pm Post subject: |
|
|
| Mega Man wrote: | | The order represents the dependencies. Sometimes you need to add a library twice times at different positions to reflect the dependencies. The used linker can also have a reversed order when you are using a higher or lower version of the linker. There are also linker flags which have influence on the behaviour (--start-group). |
Thanks for the answer!
In the end that's exactly what I thought would have happened - it made me play with the order and thus I found a working one... But still I can't see the logic behind it. Is there a trick to see which is the right order!?
As far as I can tell the order is reversed (right to left): sdl_mixer depends on sdl ... not the other way around, right?
While searching for a solution I even found the grouping stuff you mentioned. I could not get that to work either. As far as I understood, one can define a group of libs, and the linker will repeat reading them until a) all dependencies are satisfied or b) nothing was added in the previous read. Is that correct?
If it was: Shouldn't I be able to group all libs and by that forget about their order?
(Atleast that's what I tried ... didn't work.)
Btw: Could you explain what you meant by | Quote: | | a higher or lower version of the linker |
?
Last edited by astfgl on Thu Jul 08, 2010 9:15 pm; edited 1 time in total |
|
| Back to top |
|
|
astfgl
Joined: 13 Jul 2007
Posts: 7
|
| Posted: Thu Jul 08, 2010 9:10 pm Post subject: |
|
|
| cosmito wrote: | | I'm also a novice when comes to fighting with makefiles so allow me to take the opportunity to ask you if the order of the EE_OBJS is important. |
Hmm... Out of curiosity, did you happen to notice such a problem!? Or why did you ask that question?
Makefiles are still a little bit of a mystery to me:
I wanted to use some conditional stuff like
| Code: | ifdef PS2SDK
FOO=bar
endif |
This indeed works, but only above the "rules". Somehow the rules themselves work like shell-scripts, while the upper part does not.
Btw: Is there a good flag to check whether it's the PS2 compiler or not?
Linux (and other Unix) compilers have __UNIX__
MacOSX has __APPLE__
Windows compilers usually have WIN32/_WIN32/__WIN32__
AFAIK you can even check whether it's GCC, or not...
The PSPSDK has one, too (named PSP ;) )
Which one is for the PS2? |
|
| Back to top |
|
|
cosmito
Joined: 04 Mar 2007
Posts: 314
Location: Portugal
|
| Posted: Sat Jul 10, 2010 7:42 am Post subject: |
|
|
| Mega Man wrote: | | The order of the object files has influence on the created elf file, but this normally makes no difference as the linker script of the PS2 toolchain is correct. Normally there should be no problems with the order of the object files. |
Thanks you Megaman for the answer. I admit it's a bit of a lazy question, but I would like to hear from you and your experience. |
|
| Back to top |
|
|
cosmito
Joined: 04 Mar 2007
Posts: 314
Location: Portugal
|
| Posted: Sat Jul 10, 2010 7:46 am Post subject: |
|
|
| astfgl wrote: | | cosmito wrote: | | I'm also a novice when comes to fighting with makefiles so allow me to take the opportunity to ask you if the order of the EE_OBJS is important. |
Hmm... Out of curiosity, did you happen to notice such a problem!? Or why did you ask that question? |
Yes I was only asking, it never happened to me. The order of the libs issue however happens occasionally and that makes me not to be very fond of makefiles and to search for alternatives. cmake seems to have some fans and misfire started to make scripts for the ps2sdk. |
|
| Back to top |
|
|
ragnarok2040
Joined: 09 Aug 2006
Posts: 230
|
| Posted: Sat Jul 10, 2010 5:45 pm Post subject: |
|
|
I did experience some problems with textures converted into source using bin2c. Changing the order of the objects would result in some sort of corruption with the texture. It seemed to only happen if the function had a local uninitialized variable or something like that. I think it had an effect with the data or pointers somehow becoming unaligned...
As for libraries, I always envisioned an arrow starting with the symbol->definition. Any libraries that shared a library or group of libraries were grouped to the left, first, with the shared group to the right.
Also, if you have two libraries that share the same symbols, the first encountered definitions will override any definitions later encountered unless the symbol attributes are weak. That's for essentially simple things like -lstdc++ -lc -ln, where one is ps2sdk's libc and the other is newlib's libc renamed to libn. You get libstdc++ using ps2sdk's libc, first, supplemented by newlib's libc giving you a pretty feature complete libc setup.
I'm not sure what happens if you were to link in a different order, for example, -lc -lstdc++ -ln. I think only the ps2sdk libc definitions that have been filled prior to libstdc++ would override the newlib definitions, with the rest being fulfilled by newlib's libc as the linker will only look at it's current pool of symbols->definitions and libn. As far as I know, the linker doesn't pull every symbol definition out of a library, just the definition it currently needs for a specific symbol.
That's how I understand it anyway, heh, :D. |
|
| Back to top |
|
|
Jim
Joined: 02 Jul 2005
Posts: 487
Location: Sydney
|
| Posted: Sun Jul 11, 2010 9:19 am Post subject: |
|
|
| Quote: | | Changing the order of the objects would result in some sort of corruption with the texture. |
Sounds like you had/have something corrupting memory, but by moving the textures around you were/are overwriting something less visible!
Jim
_________________
http://www.dbfinteractive.com |
|
| Back to top |
|
|
ragnarok2040
Joined: 09 Aug 2006
Posts: 230
|
| Posted: Sun Jul 11, 2010 10:25 pm Post subject: |
|
|
Probably. I wasn't sure how large the corruption was, for example, a single dmatag being corrupted during texture transfers could have caused it. Or, if it was random data being copied into memory addresses inside the texture's buffer.
I have a suspicion it might be an alignment boundary issue with using reference tags in the dmachain, since I hadn't added any alignment attribute to the source file. Textures read from files are generally put into 64/128 byte aligned buffers, but I thought that was just to optimize it for the cacheline, heh. |
|
| Back to top |
|
|
Mega Man
Joined: 18 Jun 2005
Posts: 274
|
| Posted: Mon Jul 12, 2010 2:02 am Post subject: |
|
|
| astfgl wrote: |
Btw: Could you explain what you meant by | Quote: | | a higher or lower version of the linker |
? |
In general a library provides symbols which are needed by the program or other libraries. You need to put the libraries in the correct order, so the linker will find the missing symbols. You detected that the order is left to right. If you use a newer or older version of the linker the order is right to left. As far as I know there is no version used for PS2 which reverts the order.
@ragnarok2040: The alignment of data and code can change if you change the order of the object files. To get around this you need to specify the ".align" or __attribute__((aligned(16))) directives. |
|
| Back to top |
|
|
astfgl
Joined: 13 Jul 2007
Posts: 7
|
| Posted: Mon Jul 12, 2010 5:11 am Post subject: |
|
|
| ragnarok2040 wrote: | | As for libraries, I always envisioned an arrow starting with the symbol->definition. Any libraries that shared a library or group of libraries were grouped to the left, first, with the shared group to the right. |
This would conclude to "read right-to-left" as Mega Man explained. Great! :)
| ragnarok2040 wrote: | | Also, if you have two libraries that share the same symbols, the first encountered definitions will override any definitions later encountered unless the symbol attributes are weak. |
Ah okay, I know how this works. That's done by the ifdef/define stuff you usually find in header-files. If no lib providing X is loaded, load this lib providing X.
| ragnarok2040 wrote: | | I'm not sure what happens if you were to link in a different order, for example, -lc -lstdc++ -ln. I think only the ps2sdk libc definitions that have been filled prior to libstdc++ would override the newlib definitions, with the rest being fulfilled by newlib's libc as the linker will only look at it's current pool of symbols->definitions and libn. As far as I know, the linker doesn't pull every symbol definition out of a library, just the definition it currently needs for a specific symbol. |
I think this should result in:
a) It works, since the definitions are compatible, or
b) it won't work since there are e.g. functions not defined in one version of the lib, that a part of the other thinks are there.
| Mega Man wrote: | | In general a library provides symbols which are needed by the program or other libraries. You need to put the libraries in the correct order, so the linker will find the missing symbols. |
Okay, this is the obvious part: I already got that ;)
| Mega Man wrote: | | You detected that the order is left to right. If you use a newer or older version of the linker the order is right to left. As far as I know there is no version used for PS2 which reverts the order. |
Hmm. I thought it would be left-to-right*. I found it was right-to-left. So I think my linker is acting "normal" ...
*I'd still think this would be the "intuitive" way: The way a person reads it!?
Still: Is there a precompiler flag for the PS2? |
|
| Back to top |
|
|
cheriff
Regular
Joined: 23 Jun 2004
Posts: 262
Location: Sydney.au
|
| Posted: Mon Jul 12, 2010 11:59 am Post subject: |
|
|
| astfgl wrote: | Hmm. I thought it would be left-to-right*. I found it was right-to-left. So I think my linker is acting "normal" ...
*I'd still think this would be the "intuitive" way: The way a person reads it!?
|
It is left to right, if you think in terms of 'X is satisfied by Y', so X comes before Y on the linker line.
So if you have -lfoo -lbar -lbaz, the linker will process all of your .o files, and keep a list of any symbols not yet satisfied. First up it sees libfoo.a - if a function in there matches anything on the 'still missing list' then we pull it in to the executable and scratch the symbol off the list. Of course pulling this code may have other dependancies so we might add new unstatsfied symbols to the list, and hope that one of the latter libraries (bar or baz) can fill them in.
This repeats for each -l option, and if the lists is not empty by the time we get to the end, we meet out friend the "undefined symbol" error.
The reason ordering matters, is that if something in libbaz.a calls bar_hello() in libbar.a - then that symbol will not yet be on the list at the time -lbar is processed, so it gets skipped. LD only recognises it needs that symbol when -lbaz is processed, by which timer we'ver already passed by the library that provides it.
--start-group and --end-group will cause the linker to keep looping around the included libraries for as long as the list of required symbols is changing, which can be a nicer way of dealing with circular dependancies than multiple -lfoo options.
In the case of SDL, it makes sense that SDL_image will use core functionality provided by SDL_gfx (note that i don't know SDL internals all that well) so it should be first - otherwise the linker will not know what is missing and needs to be obtained from libSDL_image.a and then in turn libsdl.a
In the order asrfgl originally had it, ld would only get from libsdl.a the symbols** explicitly mentioned in the .o files of his project. Although his files may call SDL_image_ stuff, there's no way of knowing at this time if they in turn need things in the core SDL library. If they do, ld finds out too late and the link fails.
** NB: i simplified it a little - ld doesn't pull things from libraries symbol by symbol, rather the entire .o from inside the library that surrounds the required symbol comes along for the ride, whether needed or not, which may give rise to false dependancies and unused symbols being included. But thats a small detail here, and good libraries generally have one exported function per .o anyway, to reduce the amount of 'dead' code in final executables.
_________________
Damn, I need a decent signature! |
|
| Back to top |
|
|
cheriff
Regular
Joined: 23 Jun 2004
Posts: 262
Location: Sydney.au
|
| Posted: Mon Jul 12, 2010 12:34 pm Post subject: |
|
|
| astfgl wrote: | Btw: Is there a good flag to check whether it's the PS2 compiler or not?
Linux (and other Unix) compilers have __UNIX__
MacOSX has __APPLE__
Windows compilers usually have WIN32/_WIN32/__WIN32__
AFAIK you can even check whether it's GCC, or not...
The PSPSDK has one, too (named PSP ;) )
Which one is for the PS2? |
Its PS2
Also _PS2 for some reason, and there's _EE to differentiate from the IOP.
See: http://svn.ps2dev.org/filedetails.php?repname=ps2&path=/trunk/ps2sdk/ee/Rules.mak
It ends up adding "-DPS2=1" to the gcc command line. You should see this when running make and attempting a compile?
_________________
Damn, I need a decent signature! |
|
| Back to top |
|
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
