I can't compile bsnes 0.020 under Fedora 7 [solved]

Announce new emulators, discuss which games run best under each emulator, and much much more.

Moderator: General Mods

Post Reply
belegdol
Hazed
Posts: 68
Joined: Tue Dec 07, 2004 10:24 am

I can't compile bsnes 0.020 under Fedora 7 [solved]

Post by belegdol »

I am hitting the following error:
[jsikorski@snowball src]$ make PLATFORM=x-gcc-lui-x64
g++ -O3 -fomit-frame-pointer -ffast-math -DPLATFORM_X -DCOMPILER_GCC -DPROCESSOR_X86_64 -DUI_LUI `pkg-config --cflags gtk+-2.0` -c ui/main.cpp -o main.o
ui/lui/ui_main.cpp: In member function ‘virtual int MainWindow::message(uint, void*)’:
ui/lui/ui_main.cpp:13: error: cast from ‘void*’ to ‘int’ loses precision
ui/lui/ui_main.cpp:18: error: cast from ‘void*’ to ‘int’ loses precision
ui/lui/settings/ui_inputconfig.cpp: In member function ‘virtual int InputCaptureWindow::message(uint, void*)’:
ui/lui/settings/ui_inputconfig.cpp:165: error: cast from ‘void*’ to ‘uint’ loses precision
make: *** [main.o] Error 1
[jsikorski@snowball src]$
I saw a discussion in these forums where byuu claims that gcc is too strict. Is it possible to suppress its strictness somehow, or do I have to use an older version? I am at gcc (GCC) 4.1.2 20070502 (Red Hat 4.1.2-12) now. Cheers.
Last edited by belegdol on Tue Jun 05, 2007 2:43 am, edited 2 times in total.
Thristian
Hazed
Posts: 76
Joined: Tue Feb 07, 2006 11:02 am

Post by Thristian »

gcc can be strict, but in this instance it's quite right: it looks like you're using a 64-bit version of Linux, and casting a 64-bit 'void*' to a 32-bit 'int' throws half of it away and is almost guaranteed to do Bad Things. If you were using a 32-bit version of Linux, it would be trying to cast a 32-bit 'void*' to a 32-bit 'int' and it probably wouldn't care.

Somebody else has had the same problem, I suggest you watch that thread for updates and replies.
belegdol
Hazed
Posts: 68
Joined: Tue Dec 07, 2004 10:24 am

Post by belegdol »

I created a separate thread to avoid this problem being lost among lots of replies, so that once it is solved it will be much easier to find a solution. Thanks for the reply anyway.

[edit] Solved with latest reuploaded version.
byuu

Post by byuu »

Thristian wrote:gcc can be strict, but in this instance it's quite right: it looks like you're using a 64-bit version of Linux, and casting a 64-bit 'void*' to a 32-bit 'int' throws half of it away and is almost guaranteed to do Bad Things. If you were using a 32-bit version of Linux, it would be trying to cast a 32-bit 'void*' to a 32-bit 'int' and it probably wouldn't care.
That's exactly right. I found the proper solution, using uintptr_t, but that will have to wait for the next release. The new .tar.bz2 at least resolves this specific issue with a quick fix.

However, this is not always a bad thing. In my case, I was passing a 16-bit keycode through the void* parameter, so casting the void* back to 16-bit was not unsafe, hence I declared the cast explicitly, GCC just chose to give an error rather than a warning. It was not less safe than uint16 x = (uint32)y, which GCC doesn't even warn you about. Now, had I tried to cast the uint16 back to a void* implicitly, I could see it getting a little picky ...

Example:

Code: Select all

struct Control {
  int data;
};

void exproc() { printf("function\n"); }

void message(uint id, uintptr_t param) {
  if(id == 0) {
    printf("integer %d\n", param);
  } else if(id == 1) {
    printf("pointer %d\n", ((Control*)param)->data);
  } else if(id == 2) {
    ((void (*)())param)();
  }
}

int main() {
Control c;
  c.data = 5;
  message(0, 4);
  message(1, (uintptr_t)&c);
  message(2, (uintptr_t)exproc);

  printf("done\n");
  getch();
  return 0;
}
Post Reply