Hatari 2.1.0 has been released

[npomarede]

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]

Try with #gcc -v

[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.

[npomarede]

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) 

[npomarede]

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 ?

[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]

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

[ThorstenOtto]

Are you sure of this ?

Quite sure because i just grepped the headers

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.

[npomarede]

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]

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]

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.

[npomarede]

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]

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.

[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]

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)

[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 ?

[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]

how do i run GFA basic? the open file option is greyed out. neat emulator though. my grandmother had one. still remember the keyboard

[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.

[solskogen]

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!

[Eero Tamminen]

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]

its in german, in red

[MrPixel]

it works on steem

[Eero Tamminen]

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.)

[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.