#linuxcnc-devel Logs

Nov 22 2020

02:01 AM -!- #linuxcnc-devel mode set to +v by ChanServ
02:12 AM -!- #linuxcnc-devel mode set to +v by ChanServ
02:12 AM -!- #linuxcnc-devel mode set to +v by ChanServ
02:26 PM -!- #linuxcnc-devel mode set to +vv by hitchcock.freenode.net
04:14 PM dgarr: jepler: anyone? branch dgarr/tool_mmap builds and passes runtests but fails clang scan-build -- i'm stumped, any suggestions appreciated
04:57 PM rene_dev_21: dgarr what does it do?
04:58 PM dgarr: see the commit message https://github.com/LinuxCNC/linuxcnc/commit/7e47ac1b9ddb9a9e2b6cdde8e3bcf88464a81b48
05:06 PM rene_dev_21: (idx is the pocket-based index)
05:06 PM rene_dev_21: why not use the tool number?
05:09 PM rene_dev_21: I dont understand why you need the mmap. I have a working version that uses a sqlitedb for toolstorage, and passes only the tool number around.
06:25 PM jepler: dgarr: conjecture, but I notice the rule for tool_mmap_read executable calls out source files directly. This is unusual and maybe doesn't work as required here
06:26 PM jepler: The commandline for this step is hidden so I can't see, but if the include directory is not specified then it could account for this
06:30 PM jepler: Not only clang failed but also e.g. buster-python3, I didn't check them all (some did succeed though)
06:53 PM dgarr: the last 3 builds i tried were clang only according to this grid http://buildbot.linuxcnc.org/buildbot/grid
06:54 PM dgarr: i'll follow up with a test based on your conjecture, thanks
08:21 PM jepler: dgarr: this sequence seems to reproduce the build failure on my buster machine consistently: CAREFUL, the "git clean" command will delete all files not known to git! so don't run it blindly
08:21 PM jepler: jepler@babs:~/src/linuxcnc/src$ git clean -dxf .. && ./autogen.sh && ./configure --enable-non-distributable=yes && make ../bin/tool_mmap_read
08:21 PM jepler: The include-path of tool_mmap_read's build commandline is something like -I../include so if headers happen to have been copied there all is well; but if not, it fails
08:23 PM jepler: this include path differs from the one used to, say, build the object file objects/emc/tooldata/tooldata.o which has CFLAGS which to header files in their non-copied locations
08:24 PM jepler: most likely the failure is not 100% because particularly when make is invoked with multiple simultaneous jobs, there is no guarantee of the order of the evaluation of rules, and there is no explicit dependency in the makefile