Allegro.cc - Online Community

Allegro.cc Forums » Installation, Setup & Configuration » Error building with Raspberry Pi Debug Build

This thread is locked; no one can reply to it. rss feed Print
Error building with Raspberry Pi Debug Build
Kev Callahan
Member #6,022
July 2005
avatar

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'

#SelectExpand
1/pi/dev/allegro-5.2.0.0/build_rpid/examples && /usr/bin/cmake -E cmake_link_script CMakeFiles/ex_acodec.dir/link.txt --verbose=no 2../lib/liballegro-debug-static.a(ogl_bitmap.c.o): In function `ogl_lock_compressed_region': 3/pi/dev/allegro-5.2.0.0/src/opengl/ogl_bitmap.c:792: undefined reference to `glGetCompressedTexImage' 4/pi/dev/allegro-5.2.0.0/src/opengl/ogl_bitmap.c:836: undefined reference to `glPopClientAttrib' 5collect2: error: ld returned 1 exit status 6examples/CMakeFiles/ex_acodec.dir/build.make:123: recipe for target 'examples/ex_acodec' failed

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

SiegeLord
Member #7,827
October 2006
avatar

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).

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Kev Callahan
Member #6,022
July 2005
avatar

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'

#SelectExpand
1[root] 21:31:45 allegro-5.2.0.0 nm ./build_rpi/CMakeFiles/allegro.dir/src/opengl/ogl_bitmap.c.o | grep CompressedTex 2 U glCompressedTexSubImage2D 3[root] 21:31:56 allegro-5.2.0.0 nm ./build_rpid/CMakeFiles/allegro.dir/src/opengl/ogl_bitmap.c.o | grep CompressedTex 4 U glCompressedTexSubImage2D 5 U glGetCompressedTexImage <---!

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." ]

SiegeLord
Member #7,827
October 2006
avatar

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.

"For in much wisdom is much grief: and he that increases knowledge increases sorrow."-Ecclesiastes 1:18
[SiegeLord's Abode][Codes]:[DAllegro5]:[RustAllegro]

Kev Callahan
Member #6,022
July 2005
avatar

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...

Go to: