Hi,

Seem to have an issue (RPI with 5.2.0.0) whereby linking with 'RelWithDebInfo' Allegro build works fine,
but if I build the 'Debug' version of Allegro and then try linking with it I get the following error (building
in this case ex_acodec - the first example file) -

Undefined references to `glGetCompressedTexImage' and `glPopClientAttrib'

CMAKE commands used -

OKAY: cmake .. -DSHARED=off -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchain-raspberrypi.cmake
FAILS: cmake .. -DSHARED=off -DCMAKE_TOOLCHAIN_FILE=../cmake/Toolchain-raspberrypi.cmake -DCMAKE_BUILD_TYPE=Debug

Any ideas..?

Guess the debug build includes (or excludes) something that causes this issue..?
Specific library..?
_____________________________________________________________

EDIT:
Just tried also with 5.2.1.1 release - same issue..

EDIT2:
Changing the 'link.txt' to use the non-debug version liballegro-static.a (rather than the debug version) means it links.
So it's something (probably unsurprisingly) to do with the makeup of liballegro-debug-static.a ...

include/allegro5/platform/alplatf.h are identical on each build (ie OPENGL(ES) defines).

EDIT3:
Adding -lGL to the link lines for examples allows them to build..
However if I add the same to my (working without debug allegro) build, it crashes with an opengl extensions error (print_extensions) ..
So don't think this is the answer.. All I want is a build with the allegro.log output so I can check whether the bitmaps are accelerated, etc..

Looks to me that enabling the DEBUG build causes some other compiler switch that means I need these other functions (which I guess aren't available with GLES?).
_____________________________________________________________

Kev

This is concerning, but if the only thing you want is allegro.log, you can turn that on even in the release binary. Just do al_set_config_value(al_get_system_config(), "trace", "level", "debug")) somewhere before al_init (or maybe just after, I forget).

Ah that's useful, thanks SiegeLord, will investigate that.

Yeah a bit concerning, hoped someone else could at least verify the issue.. It may just be one of my libraries has an issue I suppose, but can't see why it would manifest like this...

I'm using a yocto build.., would be good if someone who uses raspbian or whatever could check.

EDIT:
Using nm on /opt/vc/lib/libGLESv2.so (where I was expecting glGetCompressedTexImage to be defined) there appears no mention of it...

So it looks like enabling Debug is pulling in the OpenGL A5 file ogl_bitmap.c
Does the RelWithDebInfo one not ..

Aarrgghh .. Look..! First one 'normal', second one 'debug'

EDIT2:
Okay.. Why are these so different between RelWithDebInfo and Debug?

[root] 21:41:45 allegro-5.2.0.0 diff ./build_rpi/CMakeFiles/allegro.dir/flags.make
                                     ./build_rpid/CMakeFiles/allegro.dir/flags.make
5c5
< C_FLAGS = -march=armv6 -mfpu=vfp -mfloat-abi=hard 
            -W -Wall -Wpointer-arith -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes 
            -O2 
            -g -DNDEBUG 
            -I/opt/vc/include 
            -I/opt/vc/include/interface/vcos/pthreads 
            -I/opt/vc/include/interface/vmcs_host/linux 
            -I/vend/allegro-5.2.0.0/include 
            -I/vend/allegro-5.2.0.0/build_rpid/include       
            -DALLEGRO_SRC -DALLEGRO_STATICLINK -DALLEGRO_LIB_BUILD
---
> C_FLAGS =  -W -Wall -Wpointer-arith -Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes 
             -g -DDEBUGMODE=1 -DD3D_DEBUG_INFO 
             -I/opt/vc/include 
             -I/opt/vc/include/interface/vcos/pthreads 
             -I/opt/vc/include/interface/vmcs_host/linux 
             -I/vend/allegro-5.2.0.0/include 
             -I/vend/allegro-5.2.0.0/build_rpid/include     
             -DALLEGRO_SRC -DALLEGRO_STATICLINK -DALLEGRO_LIB_BUILD

Starting to look like an issue with the TOOLCHAIN incorrect on the debug build..?
I'll do a complete fresh cmake tomorrow for both and report back - hopefully it's all just me being an idiot.

** UPDATE:
Rebuilt completely via cmake and the same problem, so it's (probably) not my setup.
diff between the CMakeCache.txt files all look sensible (ie pathnames and CMAKE_BUILD_TYPE as expected).

The flags.make differences are few now (ie -DNDEBUG as opposed to -DDEBUGMODE=1 -DD3D_DEBUG_INFO) - I guess these are sensible (although don't know why RPI needs -DD3D_DEBUG_INFO).

So issue not yet resolved.
Any ideas what else is worth looking at anyone..?
My reason for this investigation is not so desperate now, but happy to follow it up if it helps A5 development).

[ Out of interest, the original issue that I was investigating is now not a problem - I was losing major FPS when in portrait mode and it's not A5, but using 'display_rotate=1' in /boot/config.txt kills FPS. Apparently due to the non-GPU way it does it "when the display is portrait, the HVS doesn't composite on-the-fly. It has to write a landscape buffer to memory. It then has to use the transposer hardware to convert the landscape image to a portrait image, involving another memory read and write. It then finally fetches this portrait image and outputs to the display." ]

Perhaps what's happening is that -O2 removes the unused function call, thus removing the need to link to that function. I filed an issue about it: https://github.com/liballeg/allegro5/issues/677

What you could do in the short term is to add !defined ALLEGRO_RASPBERRY_PI on line 720, so this function isn't compiled in.

That or when I get the opportunity (more than likely not till end of next week now unfortunately) I'll maybe add the optimisation flag to the debug build and see what effect that has.. Suppose it's a possibility...