<div>Hi,<br></div><div><br></div><div>Yea that's right, but, I think that is not where the problem is.<br></div><div><br></div><div>What seems to have happened is that someone got clever with <features.h> which is included in the beginning of  <sys/ucontext.h> and which must have changed between different versions of Linux.  So I'm on what is basically Ubuntu 20.4 and they have played around what __USE_GNU means.  Now it seams that the magic #define is _GNU_SOURCE.<br></div><div><br></div><div>The easiest patch I found is below and attached above.  I also attached features.h just so you can see the nightmare that has become.<br></div><div><br></div><div>diff --git a/build.linux64x64/<a href="http://squeak.cog.spur/build/mvm">squeak.cog.spur/build/mvm</a> b/build.linux64x64/<a href="http://squeak.cog.spur/build/mvm">squeak.cog.spur/build/mvm</a><br></div><div>index 29b710460..eb67f677e 100755<br></div><div>--- a/build.linux64x64/<a href="http://squeak.cog.spur/build/mvm">squeak.cog.spur/build/mvm</a><br></div><div>+++ b/build.linux64x64/<a href="http://squeak.cog.spur/build/mvm">squeak.cog.spur/build/mvm</a><br></div><div>@@ -34,7 +34,7 @@ test -f config.h || ../../../platforms/unix/config/configure --without-npsqueak<br></div><div>--with-src=spur64src \<br></div><div>TARGET_ARCH="-m64" \<br></div><div>CC=clang \<br></div><div>-   CFLAGS="$CFLAGS" \<br></div><div>+  CFLAGS="$CFLAGS -D_GNU_SOURCE=1" \<br></div><div>LIBS="$LIBS" \<br></div><div>LDFLAGS="$LDFLAGS"<br></div><div>rm -f vm/sqUnixMain.o # nuke version info<br></div><div id="editorUserSignature" style="display:none;"><br></div><div><br></div><div>I tried to play the same ifdef games currently with __USE_GNU in include_ucontext.h but I was not successful.<br></div><div><br></div><div>This builds both with clang and with gcc on Ubuntu 20.4 on x86_64.<br></div><div><br></div><div>cheers<br></div><div><br></div><div>bruce<br></div><div><br></div><div><i>24 March 2021 20:58 "David T. Lewis" <lewis@mail.msen.com> wrote:</i><br></div><blockquote class="infmailquote"><div><br></div><div>On Wed, Mar 24, 2021 at 11:54:55AM -0700, Eliot Miranda wrote:<br></div><div> ><br></div><div> > Hi David,<br></div><div> ><br></div><div> > On Mon, Mar 22, 2021 at 4:14 PM David T. Lewis wrote:<br></div><div> ><br></div><div> > ><br></div><div> > > On Mon, Mar 22, 2021 at 11:46:27AM +0100, Bruce O'Neel wrote:<br></div><div> > > ><br></div><div> > > ><br></div><div> > > > Hi,<br></div><div> > > ><br></div><div> > > > That fixed one problem I was tripping over on the ARMv8 build.<br></div><div> > > ><br></div><div> > > > There still seems to be a problem with the x86-64 build.????<br></div><div> > > ><br></div><div> > > > Thanks.<br></div><div> > > ><br></div><div> > > > bruce<br></div><div> > ><br></div><div> > > I see the same issue on my Linux x86-64 PC. I cannot spot the exact cause<br></div><div> > > of<br></div><div> > > the problem, but it seems to have been introduced in this commit:<br></div><div> > ><br></div><div> > > commit 6d74c4b652c7780110fe327f97e98aaef5242fbc<br></div><div> > > Author: Eliot Miranda<br></div><div> > > Date: Wed Feb 10 21:41:31 2021 -0800<br></div><div> > ><br></div><div> > > Revisions to core include files to get EXPORT defined correctly at the<br></div><div> > > relevant points.<br></div><div> > > Essentially move the default EXPORT definitions from sq.h to<br></div><div> > > sqMemoryAccess.h.<br></div><div> > > Include fbdev support in build.linux32ARMv6 builds and add -m32 to<br></div><div> > > their CFLAGS<br></div><div> > > to attempt to get the 32-bit VMs to be compilable on 64-bit ARM. [ci<br></div><div> > > skip]<br></div><div> > > cuz new cogit files will arrive soon.<br></div><div> > ><br></div><div> > ><br></div><div> > > The changes seem straightforward, but for some reason the header files must<br></div><div> > > not be getting included properly.<br></div><div> > ><br></div><div> > > Dave<br></div><div> > ><br></div><div> > > ><br></div><div> > > /home/edoneel/tmp/opensmalltalk-vm/platforms/unix/vm/sqUnixMain.c:926:35:<br></div><div> > > error: use of undeclared identifier 'REG_RBP'<br></div><div> > ><br></div><div> ><br></div><div> > If you have a look at the code here the file is trying to<br></div><div> > - find out what platform it is on<br></div><div> > - pull in the relevant version of ucontext.h containing the relevant<br></div><div> > defines for extracting register values from an interrupt context<br></div><div> > - print out the registers for a crash report<br></div><div> > So please look to<br></div><div> > - find out if platforms/unix/vm/include_ucontext.h is working correctly on<br></div><div> > this platform<br></div><div> > - find out what are the platform defines (-E -dM is your friend here)<br></div><div> > - find out how ucontext.h defines the registers in a ucontext<br></div><div> ><br></div><div> <br></div><div> Hi Eliot,<br></div><div> <br></div><div> I think that platforms/unix/vm/include_ucontext.h is working correctly.<br></div><div> Using -E -dM, I can confirm:<br></div><div> <br></div><div> #define __linux__ 1<br></div><div> #define __x86_64 1<br></div><div> <br></div><div> Also, include_ucontext.h was not modified in commit 924a24bb54870a621c5283f23631261d5a792000<br></div><div> which is where I think the issue originates(?).<br></div><div> <br></div><div> So there is something else going wrong with the includes for Linux, but<br></div><div> I am blind and cannot spot it.<br></div><div> <br></div><div> Dave<br></div><div> <br></div></blockquote><div><br></div>