Well, I’m using what came with FreeBSD 4.10: gcc version 2.95.4
20020320 [FreeBSD] and GNU ld version 2.12.1 [FreeBSD] 2002-07-20. I
don’t know why ld didn’t yell about unresolved symbols, but I think
that has to do with with the way I was compiling my program.
Here’s my fixed Makefile:
CPP = g++
CC = gcc
OBJ = main.o sprite.o
LINKOBJ = main.o sprite.o
LIBS = -L/usr/local/lib -Wl,-rpath,/usr/local/lib -lSDL-1.1 -pthread
INCS =
CXXINCS =
BIN = cs
CXXFLAGS = -g -I/usr/local/include/SDL11 -I/usr/local/include
-D_REENTRANT -D_THREAD_SAFE
CFLAGS = -g -I/usr/local/include/SDL11 -I/usr/local/include
-D_REENTRANT -D_THREAD_SAFE
all: cs
clean:
rm -f $(OBJ) $(BIN)
$(BIN): $(LINKOBJ)
$(CPP) $(LINKOBJ) -o “cs” $(LIBS)
main.o: main.cpp
$(CPP) -c main.cpp -o main.o $(CXXFLAGS)
sprite.o: sprite.cpp
$(CPP) -c sprite.cpp -o sprite.o $(CXXFLAGS)
When I was getting the strange error, I had the LIBS variable set as
“LIBS= sdl11-config --libs” in the Makefile. It turns out that
backticks don’t work in the makefile and I wasn’t passing the right
flags to the compiler when it came to combining all the object files.
The linker didn’t yell about it tho, and it seems that it did link to
the sdl library (how else would i be able to get the backtrace from
the sdllib). I don’t know exactly why it worked and then I had that
strange error.
Hehe … i hope that statisfies your curiosity.
Cosmin.On Tue, 27 Jul 2004 08:37:03 -0400, Donny Viszneki wrote:
Just curious, but what linker and linker options are you using? Most
linkers will realize that you are referencing functions that don’t
exist at link time. (But, for instance, gnu ld will often miss
“externed” variable names that you failed to link to.)
Btw, if you plan on distributing your program as binary, you will want
to link to a dynamic library, not a static one (as you did.)
On Jul 26, 2004, at 10:42 PM, Cosmin Stroe wrote:
ahh … sorry for the trouble everyone … It turns out that while my
object files were being compiled correctly, when I was compiling my
object files into an executable, the -lSDL-1.1 was missing from the
command line parameters, and was causing the strange error.
All in all, it was a Makefile that had a typo.
Cosmin.
On Tue, 27 Jul 2004 02:22:40 +0000, Cosmin Stroe <@Cosmin_Stroe> wrote:
Hello everyone,
I’m using sdl 1.2.7 on FreeBSD 4.10. In my program, I need to
duplicate a SDL_Surface structure. After a little browsing, I found
the suggestion to use this little snipplet:
dupe = SDL_ConvertSurface(sprite, sprite->format, sprite->flags);
Where sprite is an SDL_Surface. After I compile and run, I get a
segfault inside the sdl library when I call that line. I compiled the
SDL library with debugging symbols and here’s the backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x2809ee89 in SDL_GetRGB (pixel=16711935, fmt=0x8075a80, r=0xbfbff7ff
“?”, g=0xbfbff7fe “??”, b=0xbfbff7fd “???”) at SDL_pixels.c:420
420 *r = fmt->palette->colors[pixel].r;
Current language: auto; currently c
(gdb) bt
#0 0x2809ee89 in SDL_GetRGB (pixel=16711935, fmt=0x8075a80,
r=0xbfbff7ff “?”, g=0xbfbff7fe “??”, b=0xbfbff7fd “???”) at
SDL_pixels.c:420
#1 0x280a0ec1 in SDL_ConvertSurface (surface=0x8075a40,
format=0x8075a80, flags=69632) at SDL_surface.c:867
#2 0x80492df in cs_rotate (sprite=0x8075a40, Theta=5) at
sprite.cpp:34
#3 0x8049280 in main (argc=1, argv=0xbfbff988) at main.cpp:180
Now, I was able to pinpoint where the segfault happens (at line 420):
(gdb) p fmt->palette->colors
$1 = (SDL_Color *) 0x8064c00
(gdb) p fmt->palette->colors[pixel]
Error accessing memory address 0xc024ffc: Bad address.
(gdb) p pixel
$2 = 16711935
That definetly looks wrong. Am I doing something wrong? Is there an
easier way to duplicate an SDL_Surface structure (most importantly the
surface->pixels)?
cosmin
SDL mailing list
SDL at libsdl.org
http://www.libsdl.org/mailman/listinfo/sdl
