VOGONS


First post, by superfury

User metadata
Rank l33t++
Rank
l33t++

When used for the armeabi-v7a and x86 architectures, they still compile, but I receive this warning:

X:/projects/unipcemu/android-project/jni_androidstudio/../jni/src/../../../UniPCemu/../commonemuframework/basicio/fopen64.c
:76:17: warning: implicit declaration of function 'fseeko' is invalid in C99 [-Wimplicit-function-declaration]
if (!(result = fseeko(b->f, pos, direction))) //Direction is constant itself!
^
X:/projects/unipcemu/android-project/jni_androidstudio/../jni/src/../../../UniPCemu/../commonemuframework/basicio/fopen64.c:78:17: warning: implicit declaration of function 'ftello' is invalid in C99 [-Wimplicit-function-declaration]
b->position = ftello(b->f); //Use our own position indicator!
^

Anyone knows how to fix this? It still compiles fine, other than that warning being produced, so it actually exists? Why isn't it defined(I've added all possible headers already to types.h:

#ifdef _FILE_OFFSET_BITS
#undef _FILE_OFFSET_BITS
#endif
#define _FILE_OFFSET_BITS 64

#ifdef _LARGEFILE_SOURCE
#undef _LARGEFILE_SOURCE
#endif
#define _LARGEFILE_SOURCE 1

#ifdef _LARGEFILE64_SOURCE
#undef _LARGEFILE64_SOURCE
#endif
#define _LARGEFILE64_SOURCE 1

#ifdef _POSIX_C_SOURCE
#undef _POSIX_C_SOURCE
#endif

#define _POSIX_C_SOURCE 200808L

64-bit platforms for Android take it without warnings?

Last edited by superfury on 2019-02-22, 15:44. Edited 3 times in total.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 1 of 8, by realnc

User metadata
Rank Oldbie
Rank
Oldbie

These are POSIX functions. They do exist in the C library, which is why linking doesn't fail, but at compilation time they are #ifdef'ed out in the system headers if the POSIX specific macro that guards them isn't being defined. Compiling in GNU mode usually defines all the needed macros automatically. That is, if you want to build in C99 mode, then use -std=gnu99 in your C compiler flags. For C11, use -std=gnu11. Same for C14 and C17.

With that, you should be able to just include stdio.h and get the prototypes for these functions.

Reply 2 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

Slightly related, I created a Virtualbox setup(with passthrough to Windows UniPCemu's folder since I couldn't manage to pull/clone the UniPCemu repository after installing git), then fixed various bugs trying to compile it for 64-bit Ubuntu(editing done in Windows). Eventually managed to fix all compiler warnings and errors but the issues with the 64-bit lseek/close/write file functions(no problems linking, though). Eventually found out a missing header on Linux(they need unistd.h too, after fcntl.h and sys/types.h). Then I needed to undefine the sleep macro for the unistd.h include(since it insists on definining a function called delay using a extern keyword). Luckily said macro(which is defined way earlier in the global headers of the project) isn't used in the fopen64 module.

Having fixed those coding warnings and errors, I see it compiling entirely without any errors or warnings on Ubuntu. So now, there's proper 64-bit file I/O support on Linux as well, while I can simply verify if building on Linux works by compiling it on the Ubuntu VM(with shared directories in Virtualbox as a replacement for the git repository support I couldn't get working properly on Ubuntu). 😁

Although I still have no idea how to distribute it, when built on Ubuntu and releasing through itch.io(other than compiling it yourself from source).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 3 of 8, by realnc

User metadata
Rank Oldbie
Rank
Oldbie
superfury wrote:

Slightly related, I created a Virtualbox setup(with passthrough to Windows UniPCemu's folder since I couldn't manage to pull/clone the UniPCemu repository after installing git)

If it's anything like VMware, then this is fixed by adding this line at the top of your ~/.ssh/config file:

IPQoS throughput

Reply 4 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

Now, with the latest commits, no more errors and warnings are thrown by the Ubuntu gcc compiler.

I also added proper autoconfiguration(configure script), according to the manual at https://thoughtbot.com/blog/the-magic-behind- … ke-make-install ).
Although instead of the usual automake, I have supplied a basic framework of the UniPCemu makefile as Makefile.in instead(although with more limited options than Dosbox's).

I also notice that the SDL(2) version isn't being populated in the Makefile that's generated by the configure script?

I created an autogen.sh file, which generates the proper configure script, the then generated configure script will properly generate a Makefile and build. Although the latter options (Everything below the SET_MAKE but SHELL and CC) aren't filed in.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 5 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

Hmmm.... 64-but file I-O seems to completely fail when build for Linux(defined IS_LINUX and not defined ANDROID):
https://bitbucket.org/superfury/commonemufram … sicio/fopen64.c

Can anybody see what's wrong with said 64-bit file I/O wrapper? Anyone?

Edit: Disabling 64-bit file I/O support(falling back to basic fopen/fread/fseek/fwrite/fclose) seems to log something interesting(cause: SDL2):
SDL Init error: %s: No available video device

It's compiled and running on the latest version of SDL2.0.9 and Ubuntu.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 6 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

Just added support for SDL_RWops in my 64-bit fopen implementation. Although I've only added it for Linux using SDL2 for the moment, as I can't find out yet if plain SDL supports them as well?

Edit: It now replaces fopen, fseek, (ftell is unused and is deferred from fseek and fread/fwrite results), fread, fwrite and fclose calls with their RWops-compatible variant, but somehow the 64-bit file I/O fails reading the files?

Edit: The bugfixes for the SDL_RW* functions to be defaulted to on SDL2 seems to have fixed all Linux problems(as well as Android compiler warnings on Linux lseek/ltell, which aren't needed in that case).

Now Linux just complains (as logged by my app) that it cannot create a window(SDL2 can't create a window on the Ubuntu VM within VirtualBox)?

Edit: Just rewrote(stripped) the entire 64-bit file I/O to completely use SDL's RWops for that. Except when directly calling fopen and related standard C++ functions(which happens for smaller files).

Edit: Just modified the used data files path on Linux to be defaulting to the current working directory, while automatically calling SDL_getPrefPath to use the organization "Superfury" and application name of "UniPCemu". On Linux(non-Android, since Android has it's own system) that will default it to "~/.local/share/Superfury/UniPCemu". Said directory is now automatically generated(if it doesn't exist or point somewhere else already) using a recursive mkdir command.
In my case I have it autogenerated, then remove it manually and symlink it using "ln -s" to the directory shared by the virtual machine with the project's folder I use for keeping the data files for testing the program.

On plain SDL it will simply default to the current working directory for looking for any redirect.txt file or use said directory for it's data files directly(not redirected).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 7 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

Having improved said mechanisms and error reporting(using the error.log file) with correct formats now, I see it logging the SDL message correctly(when calling SDL_Init):
"No available video device".

Having compiled the SDL2 code(2.0.9) from source according to the documentation, then fixing the Linux LDFLAGS to properly use the sdl(2)-config --(static-)libs instead of the old Windows libraries it had there before(originally being based on the Windows Makefile(The Makefile.win file)), compiling UniPCemu again on Ubuntu now makes it properly run on Ubuntu 😁

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 8 of 8, by superfury

User metadata
Rank l33t++
Rank
l33t++

Now largely replaced all fopen and related function calls with my emulator's emufopen64 and related function calls(which convert it to a SDL_RWops call) for maximum compatbility.

The only issue with that is that some calls(for parsing two text files when starting) require fscanf, which I can't implement (at least not yet, haven't figured out how to do that using the SDL_RWops yet) using the SDL_rwops features(others that were needed, like fgetc and fprintf, I have added to the RWops calls wrapper to use that method as well).

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io