[Vm-dev] nuSqueak source

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Sun Oct 25 21:49:40 UTC 2020


Hi Yoshiki, Eliot,
I confirm the problem, 32 bit linux build fails, on x86 too. it appears on
travis log:
https://travis-ci.org/github/OpenSmalltalk/opensmalltalk-vm/jobs/738800749

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)

                  ^

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 at acm.org> a
écrit :

>
> Hi Eliot,
>
>
> On Sat, Oct 24, 2020 at 5:45 PM Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>>
>> Hi Yoshiki,
>>
>> On Sat, Oct 24, 2020 at 2:00 PM Yoshiki Ohshima <Yoshiki.Ohshima at 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
>> https://github.com/OpenSmalltalk/opensmalltalk-vm.git
>> $ 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 at 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 at 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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20201025/3d50e5a3/attachment.html>


More information about the Vm-dev mailing list