Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Basilisk II doesn't build on Windows x64 #149

Open
SegHaxx opened this issue Dec 11, 2020 · 2 comments
Open

Basilisk II doesn't build on Windows x64 #149

SegHaxx opened this issue Dec 11, 2020 · 2 comments

Comments

@SegHaxx
Copy link

SegHaxx commented Dec 11, 2020

I'm doing wider ranging cleanup to BII, I fired up MSYS2 and building for x86_64 is very broken, and from the looks of it has never worked. The windows builds posted on the emaculation forum are 32bit. (What source code are those builds coming from?)

g++ -I../include -I. -I../CrossPlatform -I../uae_cpu -I../slirp -DHAVE_CONFIG_H  -DDIRECT_ADDRESSING -DUNALIGNED_PROFITABLE -DX86_64_ASSEMBLY -DOPTIMIZED_FLAGS -DUSE_JIT -DUSE_JIT_FPU -DFPU_IEEE -O2 -IC:/msys64/mingw64/include/SDL2 -Dmain=SDL_main -c cdenable/ntcd.cpp -o obj/ntcd.o
cdenable/ntcd.cpp: In function 'int CdenableSysReadCdBytes(HANDLE, DWORD, DWORD, char*)':
cdenable/ntcd.cpp:208:17: error: cast from 'HANDLE' {aka 'void*'} to 'DWORD' {aka 'long unsigned int'} loses precision [-fpermissive]
  208 |  in_buffer[0] = (DWORD)h;
      |                 ^~~~~~~~
cdenable/ntcd.cpp:211:17: error: cast from 'char*' to 'DWORD' {aka 'long unsigned int'} loses precision [-fpermissive]
  211 |  in_buffer[3] = (DWORD)buf;
      |                 ^~~~~~~~~~
make: *** [Makefile:148: obj/ntcd.o] Error 1

Looks like standard 64bit portability issues. If there's a bored windows programmer out there please take a look. :)

The other OSs are dropping 32bit support left and right, increasingly leaving Windows as the odd one out lingering on 32bit. flathub/flathub#1531

@SegHaxx
Copy link
Author

SegHaxx commented Dec 11, 2020

Okay macOS turned out to be less trouble than I thought so I took a whack at this myself. You can hack out the broken windows drivers, but then you run into issues which seem to stem from the fact that MSYS2 is on gcc 10 and debian/CentOS are still on gcc 8.

gcc 10 as usual tightens up standards requirements and doesn't like old code such as this.

@SegHaxx
Copy link
Author

SegHaxx commented Dec 16, 2020

Also note: it seems the guy doing the windows releases on emaculation has had a x64 patch for the native drivers? for some years? that's never been merged anywhere else? I'll take this on whenever I get around to fixing up the MSYS2 builds on the cebix repo. ;)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant