Hatari 2.1.0 has been released

A forum about the Hatari ST/STE/Falcon emulator - the current version is v2.2.0

Moderators: simonsunnyboy, thothy, Moderator Team

User avatar
npomarede
Atari God
Atari God
Posts: 1336
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Re:

Post by npomarede »

solskogen wrote:How's your mingw build? Give me the configure options for gcc/binutils and mingw that you use, and I'll check mine ASAP.
I didn't build it myself ; I use the one provided by my linux distro.
Do you have some commands you want me to type that would report how this mingw was built ?

Nicolas

solskogen
Atari freak
Atari freak
Posts: 62
Joined: Sun Jul 27, 2008 4:03 pm

Re: Hatari 2.1.0 has been released

Post by solskogen »

Try with #gcc -v

ThorstenOtto
Atari God
Atari God
Posts: 1103
Joined: Sun Aug 03, 2014 5:54 pm

Re: Hatari 2.1.0 has been released

Post by ThorstenOtto »

How gcc was configured does not have much influence on this. It's more related which Win32 header files were used. The header files from the Mingw32 project do not have any option to make the type off_t 64-bit, you have to use explicit functions like fseeko64()/ftello64. Unlike unix, there is no way to automatically get 64-bit support for all file operations by defining _LARGEFILE_SOURCE and/or _FILE_OFFSET_BITS.

User avatar
npomarede
Atari God
Atari God
Posts: 1336
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari 2.1.0 has been released

Post by npomarede »

solskogen wrote:Try with #gcc -v
When compiling for 32 bit Windows :

Code: Select all

i686-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-w64-mingw32/4.8.1/lto-wrapper
Target: i686-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-mageia-linux-gnu --host=x86_64-mageia-linux-gnu --with-gnu-as --with-gnu-ld --verbose --without-newlib --disable-multilib --disable-plugin --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-languages=c,c++,objc,obj-c++,fortran --with-bugurl=http://bugzilla.redhat.com/bugzilla --with-threads=posix --enable-libgomp --target=i686-w64-mingw32 --with-sysroot=/usr/i686-w64-mingw32/sys-root --with-gxx-include-dir=/usr/i686-w64-mingw32/sys-root/mingw/include/c++
Thread model: win32
gcc version 4.8.1 20130531 (Fedora MinGW 4.8.1-7.mga5) (GCC) 
For 64 bit Windows :

Code: Select all

x86_64-w64-mingw32-gcc -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-w64-mingw32/4.8.1/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-mageia-linux-gnu --host=x86_64-mageia-linux-gnu --with-gnu-as --with-gnu-ld --verbose --without-newlib --disable-multilib --disable-plugin --with-system-zlib --disable-nls --without-included-gettext --disable-win32-registry --enable-languages=c,c++,objc,obj-c++,fortran --with-bugurl=http://bugzilla.redhat.com/bugzilla --with-threads=posix --enable-libgomp --target=x86_64-w64-mingw32 --with-sysroot=/usr/x86_64-w64-mingw32/sys-root --with-gxx-include-dir=/usr/x86_64-w64-mingw32/sys-root/mingw/include/c++
Thread model: win32
gcc version 4.8.1 20130531 (Fedora MinGW 4.8.1-7.mga5) (GCC) 

User avatar
npomarede
Atari God
Atari God
Posts: 1336
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari 2.1.0 has been released

Post by npomarede »

ThorstenOtto wrote:How gcc was configured does not have much influence on this. It's more related which Win32 header files were used. The header files from the Mingw32 project do not have any option to make the type off_t 64-bit, you have to use explicit functions like fseeko64()/ftello64. Unlike unix, there is no way to automatically get 64-bit support for all file operations by defining _LARGEFILE_SOURCE and/or _FILE_OFFSET_BITS.
Are you sure of this ? Because I don't explicitly uses fseeko64/ftello64 and yet my version has 64 bit offsets.
Or maybe it's some mingw's headers that alias fseeko to fseeko64 in my case and not in Christer's case ?

EDIT : the mingw's include file handles _FILE_OFFSET_BITS, see sys-root/mingw/include/stdio.h

Code: Select all

 #if (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64))
#define fseeko fseeko64
#endif /* (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64)) */
And then I see that Hatari's cmake define both -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 (if you looks in the files "flags.cmake" in various directory) :
src/tools/hmsa/CMakeFiles/hmsa.dir/flags.make

Code: Select all

C_FLAGS =  -Wcast-qual -Wbad-function-cast -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wall -Wwrite-strings -Wsign-compare -Wformat-security -O3 -DNDEBUG -I/home/npomarede/src/hatari-work/src -I/home/npomarede/src/hatari-work/src/includes -I/home/npomarede/src/hatari-work/src/debug -I/usr/include/SDL   -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
So, maybe sthg is missing in Christer's stdio.h for mingw ?
Last edited by npomarede on Tue Mar 06, 2018 1:47 pm, edited 1 time in total.

solskogen
Atari freak
Atari freak
Posts: 62
Joined: Sun Jul 27, 2008 4:03 pm

Re: Hatari 2.1.0 has been released

Post by solskogen »

I got this from the mingw-w64 guys:
"We cannot change the definition of off_t without breaking compatibility,
so use off64_t explicitly instead.

Or try recompiling with -D_POSIX=1 -D_FILE_OFFSET_BITS=64."

So I'll try that now.

solskogen
Atari freak
Atari freak
Posts: 62
Joined: Sun Jul 27, 2008 4:03 pm

Re: Hatari 2.1.0 has been released

Post by solskogen »

That seems to work. I stopped when the avi file was 4.4GB.

ThorstenOtto
Atari God
Atari God
Posts: 1103
Joined: Sun Aug 03, 2014 5:54 pm

Re: Hatari 2.1.0 has been released

Post by ThorstenOtto »

npomarede wrote:Are you sure of this ?
Quite sure because i just grepped the headers ;)
npomarede wrote: EDIT : the mingw's include file handles _FILE_OFFSET_BITS, see sys-root/mingw/include/stdio.h

Code: Select all

 #if (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64))
#define fseeko fseeko64
#endif /* (defined(_FILE_OFFSET_BITS) && (_FILE_OFFSET_BITS == 64)) */
But that redefines only fseeko(), which is already a non-standard function (because fseek takes a long argument, which is always 32-bit only even on Windows64). It does not make the type off_t 64 bit. Similar for lseek64(), which is only available as separate function, and takes an off64_t offset, but there is no attempt to map that function to lseek(), or the off64_t type to off_t or loff_t.

I didn't look at the png sources, but without taking that situation into account on windows, you won't have 64bit support for file operations there.

User avatar
npomarede
Atari God
Atari God
Posts: 1336
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari 2.1.0 has been released

Post by npomarede »

ThorstenOtto wrote: But that redefines only fseeko(), which is already a non-standard function (because fseek takes a long argument, which is always 32-bit only even on Windows64). It does not make the type off_t 64 bit. Similar for lseek64(), which is only available as separate function, and takes an off64_t offset, but there is no attempt to map that function to lseek(), or the off64_t type to off_t or loff_t.

I didn't look at the png sources, but without taking that situation into account on windows, you won't have 64bit support for file operations there.
I just posted one part of the header as an example, I didn't look, but it's likely off_t is redefined to off64_t too.
Fact is that my Hatari build has 64 bit support under Windows, and Christer's one too since its latest change, so 64 bit offset support can be achieved with mingw even when just using fseeko/ftello/off_t in Hatari's sources :)

ThorstenOtto
Atari God
Atari God
Posts: 1103
Joined: Sun Aug 03, 2014 5:54 pm

Re: Hatari 2.1.0 has been released

Post by ThorstenOtto »

npomarede wrote:I didn't look, but it's likely off_t is redefined to off64_t too.
That's altogether possible. I was grepping the header files from the Mingw32 distribution, which don't even have that define you quoted. The files from the Mingw64 distribution are a bit different though, and might have better support. So the problem is that you have to be careful which environment is used.

czietz
Hardware Guru
Hardware Guru
Posts: 1188
Joined: Tue May 24, 2016 6:47 pm

Re: Hatari 2.1.0 has been released

Post by czietz »

ThorstenOtto wrote: But that redefines only fseeko(), which is already a non-standard function
Depends whether you consider POSIX.1-2008 a "non-standard": http://pubs.opengroup.org/onlinepubs/96 ... fseek.html.

User avatar
npomarede
Atari God
Atari God
Posts: 1336
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari 2.1.0 has been released

Post by npomarede »

ThorstenOtto wrote:
npomarede wrote:I didn't look, but it's likely off_t is redefined to off64_t too.
That's altogether possible. I was grepping the header files from the Mingw32 distribution, which don't even have that define you quoted. The files from the Mingw64 distribution are a bit different though, and might have better support. So the problem is that you have to be careful which environment is used.
Well, that's the reason : Christer and I are using mingw64, not mingw32 (as far as I understand mingw32 main development was halted in 2013 (according to wikipedia))
mingw64 was created to provide 64 bit support amongst other things.

Nicolas

solskogen
Atari freak
Atari freak
Posts: 62
Joined: Sun Jul 27, 2008 4:03 pm

Re: Hatari 2.1.0 has been released

Post by solskogen »

My guess is that your distribution patches mingw-w64 somehow, so that off_t is the same as off64_t.
Could you check if you CFLAGS have -D_FILE_OFFSET_BITS=64 when cross compiling hatari? I wonder why I have to set it, and not you.

User avatar
npomarede
Atari God
Atari God
Posts: 1336
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari 2.1.0 has been released

Post by npomarede »

I had a look and in fact it's cmake that set -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
For example, after running

Code: Select all

./configure --cross-compile-win64_32
A file src/CMakeFiles/hatari.dir/flags.make is created with :

Code: Select all

C_FLAGS =  -Wcast-qual -Wbad-function-cast -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wall -Wwrite-strings -Wsign-compare -Wformat-security -O3 -DNDEBUG   -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64
I'm using cmake 3.11.0-rc2 (but it already worked this way for less recent cmake)
Maybe cmake has some implicit flags when compiler is mingw64, can't tell at the moment.

In all cases, we could add "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" by default to Hatari's cmake I think. It would be ignored if target/compiler has no 64 bit support and else it would ensure 64 bit offsets are enabled.

solskogen
Atari freak
Atari freak
Posts: 62
Joined: Sun Jul 27, 2008 4:03 pm

Re: Hatari 2.1.0 has been released

Post by solskogen »

On my system it looks like this:

Code: Select all

C_FLAGS =  -Wcast-qual -Wbad-function-cast -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wall -Wwrite-strings -Wsign-compare -Wformat-security -O3 -DNDEBUG
I use cmake 3.9.1 (Ubuntu 17.10)

User avatar
npomarede
Atari God
Atari God
Posts: 1336
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari 2.1.0 has been released

Post by npomarede »

On an older cmake 3.0.2 I get

Code: Select all

C_FLAGS =  -Wcast-qual -Wbad-function-cast -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wall -Wwrite-strings -Wsign-compare -Wformat-security -O3 -DNDEBUG @CMakeFiles/hmsa.dir/includes_C.rsp
So maybe more recent cmake are adding 64 bit file support when "SET(CMAKE_SYSTEM_NAME Windows)" is present ?

User avatar
npomarede
Atari God
Atari God
Posts: 1336
Joined: Sat Dec 01, 2007 7:38 pm
Location: France

Re: Hatari 2.1.0 has been released

Post by npomarede »

I just added better support to enable Large File Support in Hatari's cmake : C_FLAGS is now forced to "-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64" and size of off_t is checked to ensure it's at least 8 bytes.

A warning message will be displayed if Large File Support is not available (but compilation will still be possible)

You can try to remove the extra flags you added previously to see if this new cmake fixes the problem on your builds.

Nicolas

MrPixel
Captain Atari
Captain Atari
Posts: 202
Joined: Mon Jan 08, 2018 4:31 am

Re: Hatari 2.1.0 has been released

Post by MrPixel »

how do i run GFA basic? the open file option is greyed out. neat emulator though. my grandmother had one. still remember the keyboard
Atari: King
Sega: Queen
Nintendo: squeaky clean
Phillips CDI: Agony beam :lol:

MrPixel
Captain Atari
Captain Atari
Posts: 202
Joined: Mon Jan 08, 2018 4:31 am

Re: Hatari 2.1.0 has been released

Post by MrPixel »

can't get GFA basic to run. i have it in the same directory as the emulator but the program won't read it. all options to run files are greyed out, leaving just screen and file directory options for a and b.
Atari: King
Sega: Queen
Nintendo: squeaky clean
Phillips CDI: Agony beam :lol:

solskogen
Atari freak
Atari freak
Posts: 62
Joined: Sun Jul 27, 2008 4:03 pm

Re: Hatari 2.1.0 has been released

Post by solskogen »

npomarede wrote: You can try to remove the extra flags you added previously to see if this new cmake fixes the problem on your builds.
Yeap, it works! Thanks!

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2126
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 2.1.0 has been released

Post by Eero Tamminen »

MrPixel wrote:can't get GFA basic to run. i have it in the same directory as the emulator but the program won't read it. all options to run files are greyed out, leaving just screen and file directory options for a and b.
From your description it wasn't clear how you tried to run GFA, but it works fine for me:

Code: Select all

 hatari -m gfabasic.35/gfabasic.prg
Both with EmuTOS and normal TOS. I just click "Load" in the GFA interpreter, click on the GFA file, it gets loaded, and I can run it.

MrPixel
Captain Atari
Captain Atari
Posts: 202
Joined: Mon Jan 08, 2018 4:31 am

Re: Hatari 2.1.0 has been released

Post by MrPixel »

its in german, in red
Atari: King
Sega: Queen
Nintendo: squeaky clean
Phillips CDI: Agony beam :lol:

MrPixel
Captain Atari
Captain Atari
Posts: 202
Joined: Mon Jan 08, 2018 4:31 am

Re: Hatari 2.1.0 has been released

Post by MrPixel »

it works on steem
Atari: King
Sega: Queen
Nintendo: squeaky clean
Phillips CDI: Agony beam :lol:

User avatar
Eero Tamminen
Fuji Shaped Bastard
Fuji Shaped Bastard
Posts: 2126
Joined: Sun Jul 31, 2011 1:11 pm

Re: Hatari 2.1.0 has been released

Post by Eero Tamminen »

MrPixel wrote:can't get GFA basic to run. i have it in the same directory as the emulator but the program won't read it. all options to run files are greyed out, leaving just screen and file directory options for a and b.
MrPixel, please be more explicit in describing what you're trying to do. What is the "program" you refer above? Hatari or GFA interpreter program?

What is grayed out and in where? On what OS you're running Hatari? Which version of Hatari? Which version of GFA?

Are you trying to run GFA from (floppy or hard disk) image, or from GEMDOS HD emulation?

(I think the issue is that you're trying to do something wrong, Hatari should have no problem running GFA.)

User avatar
troed
Atari God
Atari God
Posts: 1460
Joined: Mon Apr 30, 2012 6:20 pm
Location: Sweden

Re: Hatari 2.1.0 has been released

Post by troed »

My guess is that the folder with the .prg hasn't been added as GEMDOS emulated drive in Hatari's preferences. Without adding a "hard drive", there's no place (but disk images) to run things from within the emulated ST environment.

Post Reply

Return to “Hatari”