[Cuis-dev] Updates to VectorGraphics and VectorEnginePlugin

stes@PANDORA.BE stes at telenet.be
Thu Jul 15 00:55:38 PDT 2021


Based on experience with building 32bit and 64bit UNIX vm,
See http://docs.openindiana.org/handbook/community/squeak/index.html
using gcc and SunPro cc/c89, the error you post *COULD* be related to the behavior of fseek() and ftell()

       int fseek(FILE *stream, long offset, int whence);

       int fseeko(FILE *stream, off_t offset, int whence);

The difference being the off_t type and it is definition.

You could check on Windows the definition of off_t and how it is subject to -D flags.

>From lfcompile and lf64 (large file compile support on 32bit) on UNIX says :

       Applications  wishing  to  access  fseeko() and ftello() as well as the
       POSIX and X/Open specification-conforming interfaces should define  the
       macro  _LARGEFILE_SOURCE  to be 1 and set whichever feature test macros
       are appropriate to obtain the desired environment (see standards(5)).

In the past, the Squeak configure script detected the lfcompile flags (or it still does),
but unfortunately I think some files do not #include "config.h", and then they don't have the right -D flags,
we have to make sure largefile support is enabled in the 32bit case on UNIX at least
(apparently, I'm not sure why this is the case).

Basically this comes down to using c89 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 

       The  following example compiles a program with a "large" off_t and uses
       fseeko(), ftello(), and yacc(1).

         $ c89 -D_LARGEFILE_SOURCE                \
               -D_FILE_OFFSET_BITS=64 -o foo      \


So what could be happening in the Windows 32bit case, is that the necessary defines are missing.

It's possible.

A few months ago, I could build a 32bit VM with "autoconf" configure would use/find the correct settings in config.h.

But this stopped working a while ago, when some header/include files were moved/cleaned up.

It is very easy to break unintentionally one platform while fixing the header/include files for another platform, unfortunately ... !

David Stes

----- Op 15 jul 2021 om 9:31 schreef cuis-dev cuis-dev at lists.cuis.st:

> I tried the latest Cog revision.
> 64-bit works, 32-bit gives the following error
> message when reading the an image:
> "Image file read problem (0 out of 4 bytes read).
> 
> I also tried Marcel Taumel's action branch to no avail.
> 
> So still no 32bit windows vm.
> 
> 
> Best Regards,
> 
> Gerald
> 
> 
> 
> On 7/15/21 8:28 AM, Gerald Klix via Cuis-dev wrote:
>> Hi Juan,
>> 
>> On 7/14/21 8:21 PM, Juan Vuletich via Cuis-dev wrote:
>>> Hi Gerald,
>>>
>>> On 7/7/2021 5:26 PM, Gerald Klix via Cuis-dev wrote:
>>>> Juan,
>>>>
>>>> do you need a 32-bit Windows build?
>>>> I am considering to do this anayways, because build
>>>> for my favorite 32-bit platform -- RasPi -- are broken.
>>>> Just tell me if you need it by tomorrow.
>>>>
>>>> HTH,
>>>>
>>>> Gerald
>>>
>>> A 32 bit Windows build would be really useful to me.
>>>
>>> Thanks,
>>>
>> In a nutshell: "No working 32-bit-Windows build".
>> 
>> 
>> The details:
>> 
>> I thought that you would like to have a 32-bit VM
>> and started to build a 32-bit VM on Windows a week ago.
>> Wonders over wonders, after installing the appropriate 32bit-clang
>> compiler and setting the "right" environment variable
>> (COMPILER_TO_USE), the build succeeded.
>> The resulting VM was not able to read the image, it complained
>> about not being able to read bytes 0 (maybe 1) to 4.
>> I decided to dowmload the community version of Visual Studio 2019
>> and give it shot. Alas, here I got compilation errors
>> for the first file.
>> A (disturbing) side-note: If you use gcc for windows
>> 32-bit builds it looks like the build system uses
>> the 64-bit compiler, which complains about
>> bad printf-format strings (using "%d" to print
>> a pointer cast to an integer). Needless to say,
>> that this VM does not even reach the point
>> where it can complain about not being
>> able to read the image ...
>> 
>> I refrained from posting these results on the mailing-list,
>> it would have been another rant of mine about
>> "cargo-cult programming".
>> 
>> While I am writing this I tried again to build
>> a 32-bit VM with the latest
>> Cog revision, without any patches an of course no plugin.
>> Let's see were this will lead to.
>> 
>> 
>> Best Regards,
>> 
>> Gerald
> --
> Cuis-dev mailing list
> Cuis-dev at lists.cuis.st
> https://lists.cuis.st/mailman/listinfo/cuis-dev


More information about the Cuis-dev mailing list