Hi Wookey,
Sorry for the delayed response.
-----Original Message----- From: CoreSight coresight-bounces@lists.linaro.org On Behalf Of Wookey Sent: 04 April 2018 18:20 To: coresight@lists.linaro.org Subject: Re: Debian packaging - .d file generation problem
On 2018-03-22 02:59 +0000, Wookey wrote:
On 2018-03-19 02:16 +0000, Wookey wrote:
http://wookware.org/software/repo/pool/main/libo/libopencsd/
It includes all the patches I've posted here, and a couple of small changes that are largely debian-specific.
When you've looked at the rest of my patch pile and done a new release I can hopefully drop most of my patches.
Hi Mike. I'm sure you have a load of stuff after connect, and I don't wish to hassle you, but I'd love some feedback on a) the missing .d file problem (which is preventing upload to Debian) and b) all these patches.
b) I grabbed the complete set from the link you provided - most applied no problem but there were a couple that did not. I've been adding them manually and will produce an updated patch for you to check. I'm also looking at a compromise for the /linux64/dbg directory thing too - perhaps having a separate dev makefile that feeds a PLAT_DIR into the main makefile which will default to the single builddir - that should satisfy everyones requirement.
In short - no problem with the content of the patches - just need them to apply correctly.
The .d problem:
There is one remaining issue that I am finding most perplexing.
If I do a clean build in a clean chroot (exactly as will 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?
Not sure - that is my understanding too.
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?
They are definitely cleaned each time, so are being properly regenerated on each build in the 'good' chroot.
Solving this is hopefully the only thing stopping me from doing an initial upload.
Not managed to reproduce this yet - but will revisit as soon as I get back from vacation (Mon 9th).
Mike
Wookey
Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/
CoreSight mailing list CoreSight@lists.linaro.org https://lists.linaro.org/mailman/listinfo/coresight
Wookey -- Principal hats: Linaro, Debian, Wookware, ARM http://wookware.org/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.