Try ldconfig -p | grep libmmal
. On raspbian you should get:
libmmal_vc_client.so (libc6,hard-float) => /opt/vc/lib/libmmal_vc_client.so
libmmal_util.so (libc6,hard-float) => /opt/vc/lib/libmmal_util.so
libmmal_core.so (libc6,hard-float) => /opt/vc/lib/libmmal_core.so
libmmal_components.so (libc6,hard-float) => /opt/vc/lib/libmmal_components.so
libmmal.so (libc6,hard-float) => /opt/vc/lib/libmmal.so
If not, add to your question the contents of the few short files in /etc/ld.so.conf.d
. If you are not using raspbian, you should give your OS.
This means the relevant libraries are available on the system and if you build an executable linking them, there should not be a problem. However, there may be a problem building the executable; in this case it seems when gcc
invokes the linker, /opt/vc/lib
is not in its path even though it is in the runtime loader path (they are not quite the same). If you use gcc -v
, you'll see there are some non-standard paths being used as options (e.g., /usr/lib/gcc/arm-linux-gnueabihf
), but not that one. However, you can specify it yourself:
gcc test.c -L/opt/vc/lib -lmmal
Should work. You can also:
export LIBRARY_PATH=/opt/vc/lib
This variable is probably not predefined but you'll see those other paths added to it in gcc -v
output. Note it is not the same as LD_LIBRARY_PATH
, which is used by the runtime loader.