On 2018-03-19 02:16 +0000, Wookey wrote:
OK. I'm working from 0.8.1 now.
I've now uploaded the build I propose to upload to debian to my repo: http://wookware.org/software/repo/pool/main/libo/libopencsd/ or with deb [ trusted=yes ] http://wookware.org/software/repo unstable main
It includes all the patches I've posted here, and a couple of small changes that are largely debian-specific.
(e.g. 'tests' removed from the 'all' target because it makes it easier to build it without tests when so requested, always setting $CROSS_COMPILE to the host architecture so gcc/g++/ld/ar is always architecture-qualified, removing the per-arch flags and build dir, and changing the docs to match that layout).
When you've looked at the rest of my patch pile and done a new release I can hopefully drop most of my patches.
There is one remaining issue that I am finding most perplexing.
If I do a clean build in a clean chroot (exactly as wil happen on the debian buildds) it fails with: ... cd /<<PKGBUILDDIR>>/decoder/build/linux/ref_trace_decode_lib && make make[3]: Entering directory '/<<PKGBUILDDIR>>/decoder/build/linux/ref_trace_decode_lib' x86_64-linux-gnu-g++ -g -O2 -fdebug-prefix-map=/<<PKGBUILDDIR>>=. -fstack-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -c -Wall -DLINUX -Wno-switch -fpic -std=c++11 -g -O2 -DNDEBUG -I/<<PKGBUILDDIR>>/decoder/include -I/<<PKGBUILDDIR>>/decoder/source -MMD /<<PKGBUILDDIR>>/decoder/source/ocsd_code_follower.cpp -o builddir/ocsd_code_follower.o /<<PKGBUILDDIR>>/decoder/source/ocsd_code_follower.cpp:159:1: fatal error: opening dependency file builddir/ocsd_code_follower.d: No such file or directory
i.e the .d dependency files are all missing.
I got this when I switched from 0.8.0 to 0.8.1 and failed to work out what's going on. Eventually I did something and it started working (i.e. the .d files got generated) and I thought it was fixed, but it seems not.
My understanding is that because of the -MMD option the .d files should be built alongside the .o files as part of the compilation. Why might that not happen?
So there is no explicit (or implicit) rule for making .d files, just this for generating the list of files: DEPS := $(OBJECTS:%.o=%.d)
-include $(DEPS)
The exact same source tree still builds fine in my test chroot. This suggests that the issue is a missing dependency, or something else persistent in the chroot?
Solving this is hopefully the only thing stopping me from doing an initial upload.
Wookey