Brian Inglis writes: > Trying to package bison 3.8/.1 for Cygwin - previous releases to 3.7.6 > built and checked okay - bison 3.8.1 checked okay on 32 bit - all > tests segv on 64 bit!
Probably something messed up with the memory model somewhere? Got some warnings about pointers wrapping or something like that? > Reran build and check with bison 3.8 and 3.8.1 using gcc 10.2.0 and > 11.2.0 under Cygwin 64 with no change as all tests segv @ > 0x0000000100000000. That's a strangely specific address… > Build runs with autoreconf et al as per normal on 32 and 64 bit; > adding debug output allowed me see test commands to narrow down cause. > > Ran using gdb against tests/c/bistromathic/parse.y (see attached for > gdb command, script, and full log) getting the output below. > > It appears to be possible that `gl_lock_lock` expansion to > `pthread_in_use() ? pthread_mutex_lock(...)` -> `glthread_in_use() ? > ...` has avoided defining the latter in the build, or some underlying > dynamic library function may not be loaded? How did it link then in the first place? However, Cygwin definitely is not a GLib based system, so if Bison tries to use these function it probably has some compatibility shims somewhere that implement them for systems that don't have them. > This could result from Cygwin being neither fish nor fowl: none of > BSD, Sun, Windows, or Linux, although I notice some __CYGWIN__ > conditionals. Unless these have been upstreamed from Cygwin I'm often inclined to get rid of these and see what happens… :-} > ... > > Thread 1 "bison" hit Breakpoint 10, block_fatal_signals () at > /usr/src/debug/bison-3.8.1-1/lib/fatal-signal.c:318 > 318 if (mt) gl_lock_lock (fatal_signals_block_lock); > Continuing. > > Thread 1 "bison" received signal SIGSEGV, Segmentation fault. > 0x0000000100000000 in ?? () > #0 0x0000000100000000 in ?? () > Backtrace stopped: previous frame identical to this frame (corrupt stack?) Well, since you already know where the SEGV hits: what is the diff to the working 3.7.6 version? The sources for this get generated, so you need to check the build directories. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds