Allegro.cc - Online Community

Allegro.cc Forums » Installation, Setup & Configuration » Weird problem with _draw_sprite and others

This thread is locked; no one can reply to it. rss feed Print
Weird problem with _draw_sprite and others
Paul whoknows
Member #5,081
September 2004
avatar

Using MSVC 6, Allegro 4.2.1, WindowsXP
I have followed these instructions

STATIC COMPILATION
In release mode I get these errors:

Linking... LINK : warning LNK4049: locally defined symbol "_draw_sprite" imported LINK : warning LNK4049: locally defined symbol "_allegro_message" imported LINK : warning LNK4049: locally defined symbol "_al_findnext" imported LINK : warning LNK4049: locally defined symbol "_al_findfirst" imported LINK : warning LNK4049: locally defined symbol "_make_absolute_filename" imported LINK : warning LNK4049: locally defined symbol "_set_gfx_mode" imported LINK : warning LNK4049: locally defined symbol "_load_bitmap" imported character.obj : error LNK2001: unresolved external symbol __imp__draw_sprite_h_flip OLAF___Win32_Release/OLAF.exe : fatal error LNK1120: 1 unresolved externals Error executing link.exe. OLAF.exe - 2 error(s), 7 warning(s)

This is the line that makes the error

draw_sprite_h_flip(dibuja, animation.e_frame[act_frame].e_map ,abs(animation.e_frame[act_frame].x_offset + x) ,abs(y));

I tried using the 3 static modes, and I get the same results

DYNAMIC COMPILATION
In release mode I get these errors:

Linking... alleg.lib(alleg42.dll) : error LNK2005: _draw_sprite already defined in olaf.obj olaf.obj : error LNK2001: unresolved external symbol _allegro_error olaf.obj : error LNK2001: unresolved external symbol _key olaf.obj : error LNK2001: unresolved external symbol _screen olaf.obj : error LNK2001: unresolved external symbol _font OLAF___Win32_Dynamic_Debug/OLAF.exe : fatal error LNK1120: 4 unresolved externals Error executing link.exe. OLAF.exe - 6 error(s), 2 warning(s)

____

"The unlimited potential has been replaced by the concrete reality of what I programmed today." - Jordan Mechner.

Matthew Leverton
Supreme Loser
January 1999
avatar

When using static builds, you need to set up the static define so Allegro knows what's going on. Regarding the dynamic link (and possibly the static one as well), it looks like you need to do a clean rebuild.

Paul whoknows
Member #5,081
September 2004
avatar

I am doing things well now, and set up six configurations for realease, debug and profile in dynamic and static modes.
But there is a problem is driving me crazy:

In dynamic debug mode I get this
compiling... character.cpp file_name_generator.cpp frame.cpp maps.cpp olaf.cpp timer.c Linking... OLAF.exe - 0 error(s), 0 warning(s)

But in static debug mode I get this:

Compiling... character.cpp file_name_generator.cpp frame.cpp maps.cpp olaf.cpp timer.c Linking... LINK : warning LNK4049: locally defined symbol "_draw_sprite" imported LINK : warning LNK4049: locally defined symbol "_destroy_bitmap" imported LINK : warning LNK4049: locally defined symbol "_allegro_message" imported LINK : warning LNK4049: locally defined symbol "_al_findnext" imported LINK : warning LNK4049: locally defined symbol "_al_findfirst" imported LINK : warning LNK4049: locally defined symbol "_make_absolute_filename" imported LINK : warning LNK4049: locally defined symbol "_set_gfx_mode" imported LINK : warning LNK4049: locally defined symbol "_load_bitmap" imported character.obj : error LNK2001: unresolved external symbol __imp__draw_sprite_h_flip OLAF___Win32_Debug/OLAF.exe : fatal error LNK1120: 1 unresolved externals Error executing link.exe. Creating browse info file... OLAF.exe - 2 error(s), 8 warning(s)

WHY??? I followed the instructions, I tried several combinations, but it doesn't work.
Compiling in release static mode works fine but add some warnings.
In every configuration I get different results, I hate that.

____

"The unlimited potential has been replaced by the concrete reality of what I programmed today." - Jordan Mechner.

bhagabhi
Member #1,660
November 2001

In what order are you linking the libs?

[edit]
Not that I know if that would make a difference, but it certainly does on MinGW...
[/edit]

Go to: