undefined reference to `bcm_host_init'

[ChayMahajj]

Helo everyone,

I need help.
I have cross compiled rpi userland source code and install it successfully.
I developed a simple application that used the rpi userland libraries and create its Makefile as following

CFLAGS = -I/opt/vc/include \
	-I/opt/vc/include/interface/vcos/pthreads \
	-I/opt/vc/include/interface/vmcs_host \
	-I/opt/vc/include/interface/vmcs_host/linux
LDFLAGS = -L/opt/vc/lib -rdynamic -lbcm_host -Wl,-rpath,/opt/vc/lib

myapp: myapp.c

The application was being compiled successfully in Debian 10 (Linux Kernel 5.10) but after upgrading to Debian 11 and Linux Kernel 6.1 it fails and all references are undefined.

I checked the difference between Debian 10 and debian 11 but not something related to the issue.
Any idea?

Thank you.

[6by9]

What API are you trying to use over bcm_host? Almost all of them are deprecated from direct access, which is why userland isn't installed by default on Bullseye (Debian 11) or Bookworm (Debian 12).

[ChayMahajj]

Thank you for your quick reply.

I am using the following APIs :
vc_dispmanx_...
bcm_host_init
And I include the following :
#include <bcm_host.h>

[popcornmix]

dispmanx was deprecated on bullseye, and we're not supporting it on bookworm.
You really should move to the supported APIs (e.g. drm/kms).
Or stick with the older OS if you need your legacy app to continue working.

[macmpi]

Would help to have a statement in README on what is deprecated (and eventually move it away on a said sub-directory or have an updated makefile or something).
Thanks for consideration.

[ChayMahajj]

Thank you for the response but can you please explain more how ?
how to change to switch to these APIs and which libraries should be used and so on. @popcornmix

[popcornmix]

Maybe start with DRM.

modetest is one the sample test apps that could perhaps be used for inspiration.

But it depends on what you were using dispmanx for.

[ChayMahajj]

I am using it to get video snapshot and copy it to the framebuffer

[popcornmix]

Okay, that's non-trivial under DRM.
In theory the DRM writeback connector can write the contents of a display to memory,
but that would assume you have access to the code of the DRM master that drives the display.

[6by9]

The main use case I'm aware of for having to do that was fbcp which tried copying the HDMI (potentially faked) display to an SPI display.

Support for DRM drivers for those SPI displays is increasing (largely it's just sorting overlays), and Wayfire will then just render to them directly.

What's the app driving the main output that you're cloning?

DispmanX does not exist in any form on Pi5, therefore you are looking at a dead end if you're still relying on it.

[ChayMahajj]

Hello everyone,

Thank you for your response and help regarding my question. I will no longer use this appllication. I will be looking for an alternative.
I have another question regarding this context. (Maybe it is not the right place to ask) But I think you are well informed about the change of the GPU libraries and so on on Bullseye.
I am working on an application that displayes msg and images using framebuffer and QPaint. It was running well om Compute module 3 with Bullseye. After switching to Compute Module 4 my application is not showing th eimages and messages in right way and it cruches.

I am asking here since maybe it is something related to the changes.
I would be pleased if you provide me a help and an answer.

Thank you.