|
Post by Pjot on Jun 30, 2019 20:25:33 GMT 1
All, BaCon version 3.9.1 has just been released and can be obtained from the BaCon website. Please try to refresh your browser cache if the new package is not visible in your browser immediately. This is a maintenance release aiming at stability and bugfixes. Thanks to everybody who has contributed to this latest release, both forum members and also people who have reached out to me by e-mail. See the full list of changes for more details (please refresh your browser cache to see the latest). Best regards Peter
|
|
|
Post by vovchik on Jul 1, 2019 12:41:50 GMT 1
Dear Peter, Thanks for the update, enhancements and fixes. Everything works nicely, as far as I can tell, on Mint 19.1 (64 bit) and RPI3. The compiler did throw the same error in gcc and g++ on RPI3, though, but everything got compiled and runs: /build-cpp' Compiler error:
In file included from /usr/include/string.h:494:0, from print.bac.generic.h:25, from bacon.exec.c:1: In function ‘void* memcpy(void*, const void*, size_t)’, inlined from ‘char* __b2c__exec(int, int, char*, char*, ...)’ at bacon.exec.c:12:7: /usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34:71: warning: ‘void* __builtin_memcpy(void*, const void*, unsigned int)’: specified size 4294967295 exceeds maximum object size 2147483647 [-Wstringop-overflow=] return __builtin___memcpy_chk (__dest, __src, __len, __bos0 (__dest)); ^ /usr/include/arm-linux-gnueabihf/bits/string_fortified.h:34:71: warning: ‘void* __builtin_memcpy(void*, const void*, unsigned int)’: specified size 4294967295 exceeds maximum object size 2147483647 [-Wstringop-overflow=] Puzzling... With kind regards, vovchik Attachments:print.bac.log (884 B)
|
|
|
Post by Pjot on Jul 1, 2019 17:27:04 GMT 1
Thanks vovchik, The error seems to occur in the code for EXEC$ and this code was not changed since BaCon 3.4. So the previous version of BaCon would have caused the same compiler warning. Did you install a new version of RPI3 using GCC8? Because since GCC 8 there error check '-Wstringop-overflow=' seems to be enabled by default. Cause: a variable used in the memcpy function is declared as 'signed size_t' type, while memcpy actually expects 'size_t' type. Therefore, the variable can hold values between -2147483648 and 2147483647 while the memcpy parameter handles values from 0 to 4294967295. But in this particular code, the variable can contain values '-1' or '0' or some positive value up to 2147483647. The code only arrives at the memcpy function if the variable has some positive value which does not exceed 2147483647, and that's ok - memcpy can handle up to 4294967295. Therefore, in this specific situation, the warning cannot cause a real problem. Nevertheless, I will put it on the list to fix in a next version. Thanks again, Peter
|
|
|
Post by vovchik on Jul 1, 2019 22:20:47 GMT 1
Dear Peter,
I have indeed changed the RPI3's software. I installed Joe's xubuntu (18.03.2 LTS) and have gcc v. 7.4.0. Joe prepared that version so that we could have the same webkit version that we have on intel platforms and Mint/Ubuntu. I did not get that error on Mint 19.1 (same gcc version as for PI). I wonder whether Joe has encountered that same problem. In any case, thanks for the upcoming fix....
With kind regards, vovchik
|
|
|
Post by bigbass on Jul 2, 2019 17:21:24 GMT 1
hello guys I did get the same warning but I upgraded my system and figured since it still compiles with the latest compiler I could ignore the warning for now I did however notice a problem for me in my installer script that is now fixed which was because I relied on just one source tar.gz at www.basic-converter.org/stable/I just added a filter so no problem if it stays that way now *it "may be" a 32 bit 64 bit warning since it only applies to the rpi3 if we find a way to fix it or turn off the warning it could be easily added during the build Joe Yes,vovchik the idea to use an ubuntu 18.04 base was so that we could better follow the latest bacon development and still use our raspberry pi and offer feedback the good news is bacon compiles with the latest compilers #!/bin/bash
#====================================================================== result_ARCH=$(getconf LONG_BIT) #====================================================================== if test "$result_ARCH" 2>/dev/null; then echo -e " Your LONG_BIT = $result_ARCH" echo -e " You are running a $result_ARCH bit system " else echo -e " getconf failed to detect LONG_BIT" fi
./getarch Your LONG_BIT = 32 You are running a 32 bit system
|
|
|
Post by bigbass on Jul 28, 2019 5:42:19 GMT 1
Hello Peter just a technical update using your latest fossil beta we were getting a warning on 32 bit raspberry pi3 when using gcc and g++ so I thought to try clang and clang++ to see if I could get some more detailed info the final report is clang and clang++ compile cleanly if I remove one line from the makefile old original threw a error for clang CFLAGS = -g -O2 -fno-var-tracking-assignments new modified CFLAGS = -g -O2 I passed your BSD complile line from your readme (works fine on xubuntu too) just added prefix=/usr CPPFLAGS="$(fltk-config --cxxflags)" CXXFLAGS="$(fltk-config --cxxflags) -x c++" LDFLAGS="$(fltk-config --ldflags)" CC=clang CXX=clang++ ./configure prefix=/usr --enable-gui-fltk what this all means is clang compiles without warnings and produces correctly working executable bacon and bacon-fltk gui so gcc is at the heart of this warning on arm with the latest gcc Joe attached is the terminal output of the build from clang so you can have some more info and a confirmation of a correct build build-info-rpi3.tar.gz (3.93 KB)
|
|
|
Post by Pjot on Jul 28, 2019 7:05:15 GMT 1
Thanks bigbass,
The reason for this 'no-var-tracking-assignments'-parameter is that older GCC versions like 4.8.4 sometimes seem to hang in case the system is low on memory. Therefore, compiling without the parameter is OK. The check simply is used to prevent any stalling or hanging during compile time.
From your logging I can see the following:
So, the parameter should have been skipped during configuration time, which is fine, and from your compile sequence I can see that it is actually not used by clang.
BR Peter
|
|