genodelabs/genode — Issue #65: Openjpeg library doesn't compile
Author: skalk
Created: 2012-01-05 12:33:17+00:00
State: open

our nightly running buildbot triggered this issue. I can also reproduce it on my system. Whenever one tries to compile the openjpeg-library e.g. by doing 'make test/libports/openjpeg' make doesn't find the c-files of the library:

Library openjpeg
COMPILE bio.o
genode-x86-gcc: error: bio.c: No such file or directory
genode-x86-gcc: fatal error: no input files
compilation terminated.
make[2]: *** [bio.o] Error 1
make[1]: *** [openjpeg.lib] Error 2
make: *** [gen_deps_and_build_targets] Error 2

It seems to be a tricky make issue. In the library makefile 'libports/lib/mk/openjpeg.mk' there are dependencies from $(SRC_C) to some headers normally constructed by configure, and in our case constructed on demand. If make doesn't has to consider these header dependencies (e.g. by removing the dependency rules) everything builds correctly.

While inspecting make's debugging output, I found the following:

Must remake target `bio.c'.
Ignoring VPATH name `/home/kalle/src/genode-labs/genode/libports/contrib/openjpeg-1.4/libopenjpeg/bio.c'.
Successfully remade target file `bio.c'.
Finished prerequisites of target file `bio.o'.
Must remake target `bio.o'.
Putting child 0x023581d0 (bio.o) PID 7760 on the chain.
Live child 0x023581d0 (bio.o) PID 7760
COMPILE bio.o
Reaping winning child 0x023581d0 PID 7760
/usr/local/genode-gcc/bin/genode-x86-gcc -DCONFIG_MAX_THREAD_BITS=10 -D__FreeBSD__=8 -fno-builtin-sin -fno-builtin-cos -fno-builtin-sinf -fno-builtin-cosf -ffunction-sections -fno-strict-aliasing -nostdinc -g -march=i686 -m32 -O2 -MMD -MP -MT 'bio.o bio.d' -Wno-unused-but-set-variable -fPIC -I. -I/home/kalle/pub/builds/genode/okl4-x86/include -I/home/kalle/src/genode-labs/genode/libports/contrib/openjpeg-1.4/libopenjpeg -I/home/kalle/src/genode-labs/genode/libports/include/openjpeg -I/home/kalle/src/genode-labs/genode/base/include/x86 -I/home/kalle/src/genode-labs/genode/base/include/x86_32 -I/home/kalle/src/genode-labs/genode/base/include/32bit -I/home/kalle/src/genode-labs/genode/libports/include/libc -I/home/kalle/src/genode-labs/genode/libports/include/libc-genode -I/home/kalle/src/genode-labs/genode/libports/include/libc-i386 -I/home/kalle/src/genode-labs/genode/base-okl4/include -I/home/kalle/src/genode-labs/genode/base/include -I/home/kalle/src/genode-labs/genode/os/include -I/home/kalle/src/genode-labs/genode/demo/include -I/home/kalle/src/genode-labs/genode/libports/include -I/usr/local/genode-gcc/bin/../lib/gcc/x86_64-elf/4.6.1/include -c bio.c -o bio.o

The interesting part is 'Ignoring VPATH name'. In the make documentation in section 'How directory searches are performed' it says:

"If the target does need to be rebuilt (is out-of-date), the pathname found during directory search is thrown away, and the
target is rebuilt using the file name specified in the makefile. In short, if make must rebuild, then the target is rebuilt locally,
not in the directory found via directory search."

By stating the header-files as prerequisite for $(SRC_C) does this rule apply? So I guess when the headers are freshly constructed, make assumes that $(SRC_C) needs to be rebuild and therefore the directory found via directory search is thrown away.