Hi Eliot,

Le lun. 26 oct. 2020 à 03:52, Eliot Miranda <eliot.miranda@gmail.com> a écrit :
 
Hi Nicolas,

On Oct 25, 2020, at 2:49 PM, Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com> wrote:


Hi Yoshiki, Eliot,
I confirm the problem, 32 bit linux build fails, on x86 too. it appears on travis log:
In file included from /usr/include/features.h:367:0,
                 from /usr/include/pthread.h:21,
                 from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62,
                 from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
                 from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/usr/include/stdio.h:781:12: error: conflicting types for ‘fseeko’
 extern int __REDIRECT (fseeko,
            ^
In file included from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16:0,
                 from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:109:22: note: previous declaration of ‘fseeko’ was here
 #define fseek(s,o,w) fseeko(s,o,w)
                      ^
In file included from /usr/include/features.h:367:0,
                 from /usr/include/pthread.h:21,
                 from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:62,
                 from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16,
                 from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/usr/include/stdio.h:784:18: error: conflicting types for ‘ftello’
 extern __off64_t __REDIRECT (ftello, (FILE *__stream), ftello64);
                  ^
In file included from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/Cross/vm/sqAssert.h:16:0,
                 from /home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/aio.c:35:
/home/travis/build/OpenSmalltalk/opensmalltalk-vm/platforms/unix/vm/sqPlatformSpecific.h:108:18: note: previous declaration of ‘ftello’ was here
 #define ftell(s) ftello(s)

Right.  These macros have to go.  They are examples of the counter argument to Tobias’s “include sqConfig.h first” suggestion and shows why it can’t work.  C headers don’t provide encapsulation, therefore a hack (such as the above define) which works in one release may break in another.

+1. In the meantime, I have published a simple workaround that works,
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/1fde5ab77f6b4ef677014676e7925a4005471bc5

a) we have to change our client code to adapt to the platform, not the other way around. We can do this with macros, but they must come *after* system headers not before.

b) this implies that at the very least HAS_CONFIG_H must be defined in the compiler command line either as -UHAS_CONFIG_H, -DHAS_CONFIG_H, or my preference  -DHAS_CONFIG_H=0 or   -DHAS_CONFIG_H=1 since
#if HAS_CONFIG_H
is more concise and precise than

#ifdef HAS_CONFIG_H/#if defined( HAS_CONFIG_H)

c) I have realized (thanks David) that static line functions are often better than macros. They’re more powerful and more debuggable (in the debug build).

OK, let's use modern C features

Makefile:252: recipe for target 'aio.o' failed

We are doing horrible things with C macro : #define ftell(s) ftello(s) because ftell is a different function with its own signature.
If we include stdio.h AFTER this macro, then we are causing big trouble mixing the signatures...
We can cheat as long as we do not get caught... It seems to me that we are caught red-handed!
Compilation appears to pass on x64 linux.


Le dim. 25 oct. 2020 à 21:59, Yoshiki Ohshima <Yoshiki.Ohshima@acm.org> a écrit :
 
Hi Eliot,


On Sat, Oct 24, 2020 at 5:45 PM Eliot Miranda <eliot.miranda@gmail.com> wrote:
 
Hi Yoshiki,

On Sat, Oct 24, 2020 at 2:00 PM Yoshiki Ohshima <Yoshiki.Ohshima@acm.org> wrote:
 
Hi Eliot,

For build.linux64ARMv8/squeak.cog.spur/build.debug, i get the following error. I think I followed the steps in the instructions, including running updateSCCSVersion and mvm. How can I fix it?

I don't understand.  It's there:

$ git remote get-url origin
$ git status
On branch Cog
Your branch is up-to-date with 'origin/Cog'.
$ git log spur64src/vm/cogitARMv8.c
commit 883fab5c30cff36aeb93129030e8f7bfa692a697
Author: Eliot Miranda <eliot.miranda@gmail.com>
Date:   Sat Oct 17 19:27:21 2020 -0700

etc

maybe you're on a different branch?

The last commit (two commits) on the  branch I am working with is like this:

commit 4f54eed845a8daef7681d17c01f004c3a7b50c9d

Author: Nicolas Cellier <nicolas.cellier.aka.nice@gmail.com>

Date:   Fri Oct 23 22:46:36 2020 +0200


    Fix https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/531


    The return type of `currentUTCMicroseconds` was lost.

    For some reason, the cygwin/mingw takes this compilation path


    `#else // _WIN32_WINNT >= _WIN32_WINNT_WIN8`


commit efb4b1c82fd81798221d9811faa65f7bfb9c71be

Author: Eliot Miranda <eliot.miranda@gmail.com>

Date:   Tue Oct 20 19:01:17 2020 -0700


    Add stdio.h to sqWin32NewNet.c for its debug printing.


And I do see 883fab5c30cff36 in the ancestor chain.  Maybe a macro name like __arm64__ or __arm_something__ is missing or different?


For the composition input problem, I have a hacky version of code that makes it not crash.  It comes down to the line:

  /* 24-bit UCS */
-  if ((keysym & 0xff000000) == 0x01000000) return keysym & 0x00ffffff;
+  if ((keysym & 0xff000000) == 0x01000000) {
+    return 0; // keysym & 00x00ffffff;
+  }

I cannot tell when it gets "24-bit UCS" as keysym... keysym often does not store a code point like that, if I'm not mistaken.

There are other problems which I believe I introduced while ago to misunderstood a debugging macro DCONV_FPRINTF(), which adds stderr as the first argument but many calls to it were adding stderr by themselves. 

--
-- Yoshiki