libpcsxcore

Developers
2009-08-11
2013-04-22
  • I'm packaging pcsx-df for openSUSE and I have some questions:
    1- Why libpcsxcore exists? Is any app other than the main pcsx-df binary supposed to use it? After a quick look it seems to me it would be better to remove it and just link that code statically into the main binary.
    2- I found this patch, 64 bit related but without any other explanation, in an older package:
    --- libpcsxcore/psxbios.c
    +++ libpcsxcore/psxbios.c
    @@ -2363,7 +2363,7 @@
         base+=size;

    #define bfreezes(ptr) bfreeze(ptr, sizeof(ptr))
    -#define bfreezel(ptr) bfreeze(ptr, sizeof(uintptr_t))
    +#define bfreezel(ptr) bfreeze(ptr, sizeof(*ptr))

    #define bfreezepsxMptr(ptr) \      if (Mode == 1) { \

    it makes any sense?
    3- I don't know why anybody would use pcsx instead of pcsx-df. But shouldn't all the "pcsx"s be changed for pcsx-df? (binary, man, datadir..) There could be problems also with other forks.

     
    • OK, I don't know what the function is supposed to do or what the 's'/'l' suffix is supposed to mean, but the patch from "2" makes sense and I have submitted it. Without it the second memcpy from bfreeze overflows in 64 bits.

      My 1.10 based package still segfaults when loading a game in x86-64, but works in i586. But I would like to clear the libpcsxcore thing before releasing it.

       
  • Andrew Burton
    Andrew Burton
    2009-11-17

    1. When libpcsxcore was split to a library from the GUI, the intention that was there initially was to allow different front-ends (e.g. KDE etc) to use the core. In retrospect it's added more complexity for not a lot of value.

    2. Seems feasible to be. I don't run x64, so would need someone to validate it.

    3. Should probably be a bug.

    Sorry about the delayed response