Peter Pronai (May 14 2018 at 21:52): Peter Pronai (May 14 2018 at 21:52):Someone modified the signature of some function and that did this:
[ 33%] Building C object src/libbu/CMakeFiles/libbu-obj.dir/heap.c.o
/home/rain/Sync/gsoc/brlcad-code/src/libbu/heap.c: In function ‘bu_heap_log’:
/home/rain/Sync/gsoc/brlcad-code/src/libbu/heap.c:99:38: error: cast between incompatible function types from ‘void (*)(const char *, ...)’ to ‘int (*)(const char *, ...)’ [-Werror=cast-function-type]
static bu_heap_func_t heap_log = (bu_heap_func_t)&bu_log;
^
/home/rain/Sync/gsoc/brlcad-code/src/libbu/heap.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-c11-extensions’ [-Werror]
Peter Pronai (May 15 2018 at 17:22):@starseeker so, I have this problem and idk how to fix it and I can't build mged because of it, did I do something wrong? I try to keep my local gsoc branch up to date with the master, maybe I shouldn't??
Peter Pronai (May 15 2018 at 21:21):well. that was a gcc bug.
starseeker (May 16 2018 at 00:39):What compiler/version are you trying with? And did you have a working build broken by a recent commit?
Peter Pronai (May 16 2018 at 02:20):I'm using the archlinux packages, the gcc and gcc-libs versions were 8.1.0 and I rolled back to 7.3.1
I could build it a few commits ago, I even wrote a script that tried to go back further and further to find a commit that would work, but it didn't find any, so that pretty much proved that the error was not in the code. Clang could also build that part of the code (but not some C++ parts), so that was also suspicious.
Peter Pronai (May 16 2018 at 02:21):(corr: it didn't find any within a reasonable timeframe, obviously I didn't wait for it to go back into the 80's)
starseeker (May 16 2018 at 03:40):8.1 is pretty new - I don't know if we're tested there yet
starseeker (May 16 2018 at 03:41):If your main distro is too unstable, an alternative might be to set up a VM - you don't want to spend too much time fighting your build environment
Peter Pronai (May 16 2018 at 12:44):I don't have too much space on my machine, but I'll try to figure something out.
So far I had a much better experience with clang, so I'd use that if the C++ parts of the code worked with it. I'm pretty sure Clang also has bugs but GCC did something completely crazy for the second time (I had a uni assignment that it crashed on), so I trust Clang way more.
Sean (May 16 2018 at 13:32):@starseeker so, I have this problem and idk how to fix it and I can't build mged because of it, did I do something wrong? I try to keep my local gsoc branch up to date with the master, maybe I shouldn't??
if you run "svn diff" what are your changes? that error is a strictness warning (we turn warnings into errors) that we don't seem to see anywhere else just yet -- what's your compiler version? confirm what changes you have locally -- nothing changed recently that I"m aware of that would affect that
Sean (May 16 2018 at 13:33):well. that was a gcc bug.
i wouldn't be so sure -- the message is true
Sean (May 16 2018 at 13:34):8.1 is pretty new - I don't know if we're tested there yet
ah that would probably explain it -- it's likely a new compiler check that we're getting tripped up on. the fix would be to either change the signature or wrap bu_log in a function matching the callback
Peter Pronai (May 16 2018 at 14:03):I'm using git svn, I compared my branch with master, there was nothing that touched the relevant files. I tried to build master on its own, I wrote that script that went back further and further, and it always failed.
starseeker (May 17 2018 at 01:31):@Peter Pronai Try compiling with -DBRLCAD_ENABLE_STRICT=OFF and see if that lets you get a working build.
starseeker (May 17 2018 at 01:32):(option to CMake)
Peter Pronai (May 17 2018 at 01:33):I'll try that tomorrow, but I gotta get some shuteye
starseeker (May 17 2018 at 01:38):Sounds good. Oh, can you upload a version of your patch that doesn't use git formatting for the diff? Right now we need to apply it in SVN
starseeker (May 17 2018 at 01:53):I'll see if I can take gcc 8.1 for a spin, since it's adding new checks
starseeker (May 17 2018 at 02:44):Urk. This will take longer than I thought...
Sean (May 17 2018 at 03:38):Urk. This will take longer than I thought...
@starseeker patch isn't right -- we either need to introduce a bu_vlog function that takes a va_list, expand the wrapper, eliminate the logger, or change bu_log and friends to return an int
Sean (May 17 2018 at 03:49):fixed, expanded the wrapper
Sean (May 17 2018 at 03:49):@Peter Pronai it should be fixed now -- give it a try (without disabling strict)
starseeker (May 17 2018 at 11:28):OK, thanks Sean. (Yeesh - I did the same sort of thing in nirt, looked at that for an example, and totally zoned on bu_log not being va_list based. Apparently trying to do more than three things at once is a bad idea...)
starseeker (May 17 2018 at 11:30):I managed to try a gcc 8 build on another machine, and there are several more errors of the function pointer casting variety (at at least one other new one about memsetting a complex data structure.)
Peter Pronai (May 17 2018 at 16:30):it fails to compile a different part:
/home/rain/Sync/gsoc/brlcad-code/src/libbu/parallel.c: In function ‘bu_parallel’:
/home/rain/Sync/gsoc/brlcad-code/src/libbu/parallel.c:696:38: error: cast between incompatible function types from ‘void (*)(struct thread_data *)’ to ‘void * (*)(void *)’ [-Werror=cast-function-type]
if (pthread_create(&thread, &attrs, (void *(*)(void *))parallel_interface_arg, &thread_context[x])) {
^
/home/rain/Sync/gsoc/brlcad-code/src/libbu/parallel.c: At top level:
cc1: error: unrecognized command line option ‘-Wno-c11-extensions’ [-Werror]
cc1: all warnings being treated as errors
starseeker (May 18 2018 at 01:42):@Peter Pronai does compiling non-strict work?
Peter Pronai (May 18 2018 at 01:43):@starseeker yep, but it shows a few other warnings too, idk if those are bad??? they are abour a GNU specific printf format
starseeker (May 18 2018 at 01:44):@Peter Pronai worth fixing, but if they're not in your immediate code path don't worry about it yet - we need to check what we want to do about the new error category
starseeker (May 18 2018 at 01:50):Yep, patch applied - committed as revision 70970
Cezar (Jun 28 2018 at 21:17):in malloc.h, i think bu_prmem and bu_mem_barriercheck are useless/broken. in bu_prmem, there two checks before any work happens. one is if (bu_memdebug_len > 0), and the other is if (bu_memq != BU_LIST_NULL). however, they are initially set to 0/BU_LIST_NULL and never modified, so the conditions are never true and nothing really happens in that function, except for a few prints. am i missing anything?
Cezar (Jun 28 2018 at 21:21):and i think bu_mem_barriercheck has a segfault in there. it's doing &bu_memdebug[bu_memdebug_len-1], but bu_memdebug_len is never greater than 0. and even if it were, it's not doing any checks before the access. it's actually the first line in that function
Sean (Jul 04 2018 at 04:47):in
malloc.h, i thinkbu_prmemandbu_mem_barriercheckare useless/broken. inbu_prmem, there two checks before any work happens. one isif (bu_memdebug_len > 0), and the other isif (bu_memq != BU_LIST_NULL). however, they are initially set to 0/BU_LIST_NULL and never modified, so the conditions are never true and nothing really happens in that function, except for a few prints. am i missing anything?
I committed a removal of all our old barrier check code a couple weeks ago. I may have missed some details, but there were two public functions that couldn't be directly removed without going through deprecation (bu_ck_malloc_ptr, bu_mem_barriercheck -- see CHANGES). so their implementations now seem silly, but they're basically no-op functions until we can remove them.
Sean (Jul 04 2018 at 04:48):sounds like I probably didn't make bu_mem_barriercheck too safe for no-op -- feel free to fix or reduce it further or ignore it. ;)
Last updated: Oct 09 2024 at 00:44 UTC