I am having a problem with fpc picking up linking directories on my Raspberry Pi.

I have a this lib:

/opt/vc/lib/libGLESv2.so

When I execute "ldconfig -v" it shows both "/opt/vc/lib/" as a ld link directory, and the file libGLESv2.so as a linkable library.

But when I use this code in a unit:

procedure glActiveTexture(texture: GLenum); external 'libGLESv2.so';

I get this linker error during compile:

/usr/lib/ld: cannot lind -lGLESv2

But when I compile adding -Fl/opt/vc/lib the compile works without error, What's the deal? Why am I getting the ld error when when "/opt/vc/lib" is clearly in my linking path?

Anthony Walter wrote on Fri, 11 Dec 2015:

I am having a problem with fpc picking up linking directories on my Raspberry Pi.

It's unrelated to FPC. The same will happen with GCC or Clang.

ldconfig shows the paths where the dynamic linker looks for libraries. The dynamic linker is invoked when a program starts, to look for the libraries on which the program depends as encoded by the static linker.

The static linker does not use the dynamic linker's configuration, because it's a completely different and unrelated program with a different purpose. In particular, you generally do not want it to automatically pick up library overrides that may be specific to your system or even current run.

E.g., when running the static linker under Valgrind, you don't want it to automatically link in the valgrind library in the target program, even though the dynamic linker has been configured to inject it in every process, nor do you want it to find the Valgrind libraries even though they are in the dynamic linker's search path during the current execution.

A very important property of builds is that they are predictable and should depend as little as possible on the run time environment. As a result, you always have to explicitly specify any non-standard search paths.

Jonas

Thanks for the explanation.

I guess I'll create symlinks in the standard locations (/usr/lib) for these libraries and put that in an install script. Either that or add to fpc.cfg, I'm not sure which is better.

Explanation: I'm creating a series of Pi examples for GLES2 and SDL2 along the lines on NeHe, but with Free Pascal at the command line. Making the compilation of these examples as simple as "fpc example01.pas" is what I'm want to give to Pi users trying out Free Pascal.

edit fpc.cfg and add the line
-Fl/opt/vc/lib

Regards,

Andrew

Anthony Walter wrote

I guess I'll create symlinks in the standard locations (/usr/lib) for these libraries and put that in an install script. Either that or add to fpc.cfg, I'm not sure which is better.

Definitely the latter. Everything under /usr belongs exclusively to the OS/distribution, apart from /usr/local and what's below it. You could add symlinks in /usr/local/lib, but then it would be better to just install the library there.

Jonas

Jonas, well the thing is on Raspbian the GLESv2 implementation, which works with the Pi GPU, is at /opt/vc/lib by default. It's owned by root and there is no install. The install I was referring to is building and installing of SDL2 from sources. I already have to tell SDL2 build to find the correct includes at /opt/vc/include and was considering making the GLESv2 symlinks in /usr/lib, since that's where SDL2 gets put by default. But, maybe I'll modify the SDL build to use $HOME/lib and create symlinks to the required GL libs in $HOME/lib as well.

Thanks for the advice.

The proper way is to add simply the necessary directories to the library search paths in that case. Don't add symlinks, if only because it will make the build environment non-standard and if people need help, they can only come to you because you're the one that created this custom build environment.

Jonas