It's easiest to just use complete paths to your image files and not relative ones.
This is a terrible idea, as it requires the files always existing in a fixed directory. When giving the program to someone else, they either have to go through and change all the directories in the source, or they need to recreate the original directory tree (which may not be feasible if the original directory used a weird drive letter)
@ Disch: OK, but on that note why would you distribute it without compiling the images into the binary? I was assuming that we weren't at the distribution stage yet.
EDIT: I should have mentioned that DURING DEVELOPMENT using complete paths makes one less thing you need to think about. I should have mentioned that you need to come back and address it when you distribute your package. So yes Disch is right.
@ Disch: Now that I think about it, I can see what you mean. I just thought it would simplify things for the end user and one way or another the image would take up roughly the same amount of space on the disk. But putting them into the binary would mean you can't unload images you aren't using.
As for why you would ever do it? Because you can, and at least a dozen programs that I use everyday do. I guess I just thought it was a common enough practice.
obj\Debug\main.o: In function `Z10load_imageSs':
C:/Documents and Settings/devonrevenge/
My Documents/My Music/sdlproject#1.2/main.cpp:18: undefined reference to `IMG_Load'
collect2.exe: error: ld returned 1 exit status