When running client code against a locally-built libgccjit, three environment variables need to be set up:
libgccjit.so is dynamically linked into client code, so if running against a locally-built library,
LD_LIBRARY_PATH
needs to be set up appropriately. The library can be found within the “gcc” subdirectory of the build tree:
$ file libgccjit.so* libgccjit.so: symbolic link to `libgccjit.so.0' libgccjit.so.0: symbolic link to `libgccjit.so.0.0.1' libgccjit.so.0.0.1: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, not stripped
The library uses a driver executable for converting from .s assembler
files to .so shared libraries. Specifically, it looks for a name
expanded from
${target_noncanonical}-gcc-${gcc_BASEVER}${exeext}
such as x86_64-unknown-linux-gnu-gcc-5.0.0
.
Hence PATH
needs to include a directory where the library can
locate this executable.
The executable is normally installed to the installation bindir (e.g. /usr/bin), but a copy is also created within the “gcc” subdirectory of the build tree for running the testsuite, and for ease of development.
The driver executable invokes the linker, and the latter needs to locate support libraries needed by the generated code, or you will see errors like:
ld: cannot find crtbeginS.o: No such file or directory ld: cannot find -lgcc ld: cannot find -lgcc_s
Hence if running directly from a locally-built copy (without installing),
LIBRARY_PATH
needs to contain the “gcc” subdirectory of the build
tree.
For example, to run a binary that uses the library against a non-installed build of the library in LIBGCCJIT_BUILD_DIR you need an invocation of the client code like this, to preprend the dir to each of the environment variables:
$ LD_LIBRARY_PATH=$(LIBGCCJIT_BUILD_DIR):$(LD_LIBRARY_PATH) \ PATH=$(LIBGCCJIT_BUILD_DIR):$(PATH) \ LIBRARY_PATH=$(LIBGCCJIT_BUILD_DIR):$(LIBRARY_PATH) \ ./jit-hello-world hello world