[Vm-dev] nuSqueak source

Nicolas Cellier nicolas.cellier.aka.nice at gmail.com
Mon Oct 26 13:45:33 UTC 2020


Hi Eliot,

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

>
> Hi Nicolas,
>
> On Oct 25, 2020, at 2:49 PM, Nicolas Cellier <
> nicolas.cellier.aka.nice at gmail.com> wrote:
>
> 
> 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)
>
>
> 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 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/20201026/6ca0c0e4/attachment-0001.html>


More information about the Vm-dev mailing list