<div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-size:small">Hi Tobias, Hi All,</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Mar 25, 2021 at 3:04 AM Tobias Pape <<a href="mailto:Das.Linux@gmx.de">Das.Linux@gmx.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi Bruce, all<br>
<br>
<br>
> On 25. Mar 2021, at 10:32, Bruce O'Neel <<a href="mailto:bruce.oneel@pckswarms.ch" target="_blank">bruce.oneel@pckswarms.ch</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> I've attached sqUnixMain.i from the command below.<br>
<br>
Thanks, that helps.<br>
<br>
The problem is here:<br>
<br>
# 1 "/home/edoneel/tmp/opensmalltalk-vm/platforms/unix/vm/sqUnixMain.c" 2<br>
# 36 "/home/edoneel/tmp/opensmalltalk-vm/platforms/unix/vm/sqUnixMain.c"<br>
# 1 "/home/edoneel/tmp/opensmalltalk-vm/platforms/Cross/vm/sq.h" 1<br>
# 12 "/home/edoneel/tmp/opensmalltalk-vm/platforms/Cross/vm/sq.h"<br>
# 1 "/usr/include/stdio.h" 1 3 4<br>
# 27 "/usr/include/stdio.h" 3 4<br>
# 1 "/usr/include/x86_64-linux-gnu/bits/libc-header-start.h" 1 3 4<br>
# 33 "/usr/include/x86_64-linux-gnu/bits/libc-header-start.h" 3 4<br>
# 1 "/usr/include/features.h" 1 3 4<br>
# 439 "/usr/include/features.h" 3 4<br>
# 1 "/usr/include/stdc-predef.h" 1 3 4<br>
<br>
<br>
This is due to aafcb78371c7e576073a8dbf2f1f32667568e05e, Where the include of "sqConfig.h" was demoted to _after_ stdio.h and such.<br>
<br>
This seems to deal with an interdependency between EXPORT and sqPlatformSpecific.h <br>
but I don't understand what that has to do with sqConfig.h<br>
<br>
I see that _only_ win32 is doing a lot of stuff in sqConfig.h (via sqWin32.h) which _most probably_ would belong in sqPlatformSpecific.h in the first place.<br>
<br>
Since Eliot strongly-worded to not change that, I wont commit a fix.<br></blockquote><div><br></div><div class="gmail_default" style="font-size:small">I am trying to maintain a complex product across Windows and MacOS, and soon enough linux ARMv8.  In doing this I hade to change the order of includes for sqPlatformSpecific.h to get the EXPORT & IMPORT macros correctly defined to be able to share variables and functions between the VM and dlls on Windows.  This *must not* be broken.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I do not object to including a config.h file before any platform includes, provided that that config.h is generated *and only defines values meaningful to the platform include files*.  I find sqConfig.h noise at best.  Its purpose is unclear and differs across platforms.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I said many years ago that I find the current automake code in platforms/unix/config a disaster:</div><div class="gmail_default" style="font-size:small">- it does not run reliably on many linuxes</div><div class="gmail_default" style="font-size:small">- it does not produce the same configure script when run on different distros and different versions of the same distro</div><div class="gmail_default" style="font-size:small">- it is two phase, one must first compile, and then configure</div><div class="gmail_default" style="font-size:small">- the makefiles it produces are awal: they don't include dependency information so one must manually delete objects to get proper recompilation</div><div class="gmail_default"><font face="arial, sans-serif"><br></font></div><div class="gmail_default"><font face="arial, sans-serif">I have said on numerous occasions that I believe that the right way to tackle these problems is to</font></div><div class="gmail_default"><font face="arial, sans-serif">- discard the automake nonsense in favour of a small configure script that generates a sqConfig.h in the root of the relevant build directory (e.g. build.linux64x64/sqConfig.h, <span style="color:rgb(0,0,0)">build.linux64ARMv8/sqConfig.h, etc). -- we can't call it configh.h wit5hout affecting plugins that include code which has its own config.h</span></font></div><div class="gmail_default" style="font-size:small">- use proper static makefiles that are parameterised by <a href="http://plugins.int">plugins.int</a>, plugins.ext and the mvm script</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">But no one is stepping up to help.  So I'm just going to ensure that Terf works (it includes everything Squeak does and then much more) on the platforms we care about at the moment, and try and try and address the structural problems with the current platform sources when I have time, or when (as the IMPORT/EXPORT issue did) issues force addressing them.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I've written and maintained the static makefiles for MacOS.  I've written the static MSVC Makefiles for WIndows.  I've maintained with Nicholas the static Makefiles for MinGW/Cygwin that Andreas contributed.  I've spent far too long struggling with the autoconf mess on unix.  Anybody prepared to step up and move to statuic makefiles, a config.h in every build directory and move all generated and platform source files to conform to the template</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">#include "sqConfig.h"</div><div class="gmail_default" style="font-size:small">#include <platform headers></div><div class="gmail_default" style="font-size:small">#include "our readers</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">?</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">and test across at least 64-bit macos, windows, msvc & mingw/cygwin, & at least one linux platform?</div><div class="gmail_default" style="font-size:small"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">best<br>
        -tobias<br>
<br>
<br>
<br>
> <br>
> And yes it is in config.h<br>
> <br>
> <br>
> #ifndef _GNU_SOURCE<br>
> # define _GNU_SOURCE 1<br>
> #endif<br>
> <br>
> Thanks.<br>
> <br>
> bruce<br>
> <br>
> <br>
> <br>
> 25 March 2021 10:14 Tobias Pape <<a href="mailto:Das.Linux@gmx.de" target="_blank">Das.Linux@gmx.de</a>> wrote:<br>
> Hi Bruce and all<br>
> <br>
> > On 25. Mar 2021, at 09:43, Bruce O'Neel wrote:<br>
> ><br>
> > Hi,<br>
> ><br>
> > Yea that's right, but, I think that is not where the problem is.<br>
> ><br>
> > What seems to have happened is that someone got clever with which is included in the beginning of 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.<br>
> <br>
> <br>
> > Now it seams that the magic #define is _GNU_SOURCE.<br>
> <br>
> This is so quite a long time already.<br>
> I just checked a system frozen in time in 2012, it is the same there.<br>
> All __USE_* get undefined in features.h and only set with the respective _*_SOURCE options.<br>
> <br>
> The __USE_GNU dance in<br>
> <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/4f6b75b56b314c20b1842078872bd845d61344a4/platforms/unix/vm/include_ucontext.h#L15" rel="noreferrer" target="_blank">https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/4f6b75b56b314c20b1842078872bd845d61344a4/platforms/unix/vm/include_ucontext.h#L15</a><br>
> <br>
> is hence sadly ineffective.<br>
> <br>
> <br>
> ><br>
> > 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>
> ><br>
> > diff --git a/build.linux64x64/squeak.cog.spur/build/mvm b/build.linux64x64/squeak.cog.spur/build/mvm<br>
> > index 29b710460..eb67f677e 100755<br>
> > --- a/build.linux64x64/squeak.cog.spur/build/mvm<br>
> > +++ b/build.linux64x64/squeak.cog.spur/build/mvm<br>
> > @@ -34,7 +34,7 @@ test -f config.h || ../../../platforms/unix/config/configure --without-npsqueak<br>
> > --with-src=spur64src \<br>
> > TARGET_ARCH="-m64" \<br>
> > CC=clang \<br>
> > - CFLAGS="$CFLAGS" \<br>
> > + CFLAGS="$CFLAGS -D_GNU_SOURCE=1" \<br>
> > LIBS="$LIBS" \<br>
> > LDFLAGS="$LDFLAGS"<br>
> > rm -f vm/sqUnixMain.o # nuke version info<br>
> ><br>
> Configure should define that!<br>
> <br>
> AC_USE_SYSTEM_EXTENSIONS in<br>
> <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/4f6b75b56b314c20b1842078872bd845d61344a4/platforms/unix/config/configure.ac#L42" rel="noreferrer" target="_blank">https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/4f6b75b56b314c20b1842078872bd845d61344a4/platforms/unix/config/configure.ac#L42</a><br>
> does exactly that: if GNU Extensions are avaialbe, define _GNU_SORUCE.<br>
> <br>
> This define should be in config.h<br>
> <br>
> This is the unconfigured file: <a href="https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/config/config.h.in#L392" rel="noreferrer" target="_blank">https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/config/config.h.in#L392</a><br>
> <br>
> Once you run ./configure, it _will_ define _GNU_SOURCE.<br>
> <br>
> However, it must be sur that config.h is included.<br>
> This is done unconditionally in sqMemoryAccess.h and conditionally (HAVE_CONFIG_H) in sqConfig.h (which is pulled by sq.h)<br>
> (HAVE_CONFIG_H is set as I see in your email from 2 days ago)<br>
> <br>
> <br>
> Based on your command in your email, can yous please send the output of<br>
> <br>
> clang -Wall -g -O2 -DNDEBUG -DDEBUGVM=0 -msse2 -DCOGMTVM=0 -pthread -DLSB_FIRST=1 -m64 -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN -I/home/edoneel/tmp/opensmalltalk-vm/build.linux64x64/squeak.cog.spur/build -I/home/edoneel/tmp/opensmalltalk-vm/build.linux64x64/squeak.cog.spur/build -I/home/edoneel/tmp/opensmalltalk-vm/platforms/unix/vm -I/home/edoneel/tmp/opensmalltalk-vm/platforms/Cross/vm -I/home/edoneel/tmp/opensmalltalk-vm/spur64src/vm -I/usr/local/include -I/home/edoneel/tmp/opensmalltalk-vm/platforms/Cross/vm -I/home/edoneel/tmp/opensmalltalk-vm/platforms/unix/vm -I/home/edoneel/tmp/opensmalltalk-vm/spur64src/vm -I/home/edoneel/tmp/opensmalltalk-vm/platforms/Cross/plugins/FilePlugin -I/home/edoneel/tmp/opensmalltalk-vm/platforms/unix/plugins/B3DAcceleratorPlugin -m64 -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -E -o sqUnixMain.i /home/edoneel/tmp/opensmalltalk-vm/platforms/unix/vm/sqUnixMain.c<br>
> <br>
> and the resulting sqUnixMain.i?<br>
> <br>
> <br>
> Best regards<br>
> -Tobias<br>
> <br>
> <br>
> > I tried to play the same ifdef games currently with __USE_GNU in include_ucontext.h but I was not successful.<br>
> ><br>
> > This builds both with clang and with gcc on Ubuntu 20.4 on x86_64.<br>
> ><br>
> > cheers<br>
> ><br>
> > bruce<br>
> ><br>
> > 24 March 2021 20:58 "David T. Lewis" wrote:<br>
> ><br>
> > On Wed, Mar 24, 2021 at 11:54:55AM -0700, Eliot Miranda wrote:<br>
> > ><br>
> > > Hi David,<br>
> > ><br>
> > > On Mon, Mar 22, 2021 at 4:14 PM David T. Lewis wrote:<br>
> > ><br>
> > > ><br>
> > > > On Mon, Mar 22, 2021 at 11:46:27AM +0100, Bruce O'Neel wrote:<br>
> > > > ><br>
> > > > ><br>
> > > > > Hi,<br>
> > > > ><br>
> > > > > That fixed one problem I was tripping over on the ARMv8 build.<br>
> > > > ><br>
> > > > > There still seems to be a problem with the x86-64 build.????<br>
> > > > ><br>
> > > > > Thanks.<br>
> > > > ><br>
> > > > > bruce<br>
> > > ><br>
> > > > I see the same issue on my Linux x86-64 PC. I cannot spot the exact cause<br>
> > > > of<br>
> > > > the problem, but it seems to have been introduced in this commit:<br>
> > > ><br>
> > > > commit 6d74c4b652c7780110fe327f97e98aaef5242fbc<br>
> > > > Author: Eliot Miranda<br>
> > > > Date: Wed Feb 10 21:41:31 2021 -0800<br>
> > > ><br>
> > > > Revisions to core include files to get EXPORT defined correctly at the<br>
> > > > relevant points.<br>
> > > > Essentially move the default EXPORT definitions from sq.h to<br>
> > > > sqMemoryAccess.h.<br>
> > > > Include fbdev support in build.linux32ARMv6 builds and add -m32 to<br>
> > > > their CFLAGS<br>
> > > > to attempt to get the 32-bit VMs to be compilable on 64-bit ARM. [ci<br>
> > > > skip]<br>
> > > > cuz new cogit files will arrive soon.<br>
> > > ><br>
> > > ><br>
> > > > The changes seem straightforward, but for some reason the header files must<br>
> > > > not be getting included properly.<br>
> > > ><br>
> > > > Dave<br>
> > > ><br>
> > > > ><br>
> > > > /home/edoneel/tmp/opensmalltalk-vm/platforms/unix/vm/sqUnixMain.c:926:35:<br>
> > > > error: use of undeclared identifier 'REG_RBP'<br>
> > > ><br>
> > ><br>
> > > If you have a look at the code here the file is trying to<br>
> > > - find out what platform it is on<br>
> > > - pull in the relevant version of ucontext.h containing the relevant<br>
> > > defines for extracting register values from an interrupt context<br>
> > > - print out the registers for a crash report<br>
> > > So please look to<br>
> > > - find out if platforms/unix/vm/include_ucontext.h is working correctly on<br>
> > > this platform<br>
> > > - find out what are the platform defines (-E -dM is your friend here)<br>
> > > - find out how ucontext.h defines the registers in a ucontext<br>
> > ><br>
> ><br>
> > Hi Eliot,<br>
> ><br>
> > I think that platforms/unix/vm/include_ucontext.h is working correctly.<br>
> > Using -E -dM, I can confirm:<br>
> ><br>
> > #define __linux__ 1<br>
> > #define __x86_64 1<br>
> ><br>
> > Also, include_ucontext.h was not modified in commit 924a24bb54870a621c5283f23631261d5a792000<br>
> > which is where I think the issue originates(?).<br>
> ><br>
> > So there is something else going wrong with the includes for Linux, but<br>
> > I am blind and cannot spot it.<br>
> ><br>
> > Dave<br>
> ><br>
> ><br>
> ><br>
> <br>
> <br>
> <br>
> <sqUnixMain.i><br>
<br>
<br>
</blockquote></div><br clear="all"><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div></div></div>