nimforum mirror - Wrapping GameMusicEmu library but errors

System64 (orginal) [2021-06-08T15:07:07+02:00] view original

Hello, I'm trying to wrap the GameMusicEmu lib, a lib that allows you to play various musics from old chiptune systems such as NES or MegaDrive but when I compile my project, it compiles without any errors but when I run the output exe, it instantly crash with this error :

could not import: gme_ay_type

which is declared there :

var: gmeAyType* {.importc: "gme_ay_type", dynlib: libgmedll.}: GmeTypeT gmeGbsType* {.importc: "gme_gbs_type", dynlib: libgmedll.}: GmeTypeT gmeGymType* {.importc: "gme_gym_type", dynlib: libgmedll.}: GmeTypeT gmeHesType* {.importc: "gme_hes_type", dynlib: libgmedll.}: GmeTypeT gmeKssType* {.importc: "gme_kss_type", dynlib: libgmedll.}: GmeTypeT gmeNsfType* {.importc: "gme_nsf_type", dynlib: libgmedll.}: GmeTypeT gmeNsfeType* {.importc: "gme_nsfe_type", dynlib: libgmedll.}: GmeTypeT gmeSapType* {.importc: "gme_sap_type", dynlib: libgmedll.}: GmeTypeT gmeSpcType* {.importc: "gme_spc_type", dynlib: libgmedll.}: GmeTypeT gmeVgmType* {.importc: "gme_vgm_type", dynlib: libgmedll.}: GmeTypeT gmeVgzType* {.importc: "gme_vgz_type", dynlib: libgmedll.}: GmeTypeT

we checked the dll and seems theses symbols (gme_xxx_type, where xxx is the system) doesn't exists in the dll. libgme is a C++ lib, so, how can I wrap this without problems? Is it possible? Thanks for the answer.

here this is my repo that contains the GME wrapping (it will be moved to another repo when finished) : https://github.com/system64MC/NimTilengine

here the repo of the GME library : https://github.com/ShiftMediaProject/game-music-emu

I'm on Windows and someone tried it on Linux on libgme 0.6.x, seems working fine but without music (it's an SPC file)

kaushalmodi (orginal) [2021-06-08T15:33:18+02:00] view original

Looking closer, I have never mapped global variables between Nim and C/C++; I have only mapped types and procs.

Does it work if you remove the {.importc: .. dynlib: libgmedll.} parts from those declarations?

System64 (orginal) [2021-06-08T16:08:24+02:00] view original

I have the errors " ':' or '=' expected but got 'gmeXXXType' (for each type)

kaushalmodi (orginal) [2021-06-08T16:11:45+02:00] view original

Did you try this?

var
  gmeAyType*: GmeTypeT
  gmeGbsType*: GmeTypeT
  gmeGymType*: GmeTypeT
  gmeHesType*: GmeTypeT
  gmeKssType*: GmeTypeT
  gmeNsfType*: GmeTypeT
  gmeNsfeType*: GmeTypeT
  gmeSapType*: GmeTypeT
  gmeSpcType*: GmeTypeT
  gmeVgmType*: GmeTypeT
  gmeVgzType*: GmeTypeT

[ Again, this is someone coming from someone not familiar with mapping global variables between Nim and C++ dll. ]

System64 (orginal) [2021-06-08T16:15:07+02:00] view original

It compiles well but my exe instant crash with this following error : could not import: gme_wrong_file_type

kaushalmodi (orginal) [2021-06-08T16:17:17+02:00] view original

Yeah, that's what I feared.. someone will need to chime in on how to connect the global vars on the C++ side (in the .dll) with Nim.

System64 (orginal) [2021-06-08T16:18:55+02:00] view original

So it's impossible to wrap for now?

kaushalmodi (orginal) [2021-06-08T16:20:26+02:00] view original

Wait, it's not a crash.. it's a similar mapping to a global var that's failing..

https://github.com/system64MC/NimTilengine/blob/ba1dbb3ddeaf855e1e3dfb1ee52ff1a0d780371b/libgme.nim#L241

Here too, try changing to var gmeWrongFileType*: cstring.

kaushalmodi (orginal) [2021-06-08T16:21:31+02:00] view original

Hopefully @Araq or someone can comment on how to map Nim identifiers to global variables in C/C++ headers, or if that's even possible.

System64 (orginal) [2021-06-08T16:22:58+02:00] view original

Now it says that :

SIGSEGV: Illegal storage access. (Attempt to read from nil?)

System64 (orginal) [2021-06-08T17:31:04+02:00] view original

Edit : Alright I fixed the object thing but still have the file error

kaushalmodi (orginal) [2021-06-08T17:40:57+02:00] view original

Try translating the repo's demo/basic.c example to Nim.

The example uses gme_open_file and not gme_load_file, and the former constructs the Music_Emu object on the C side for you. So you don't actually need (and shouldn't do) object construction on the Nim side.

System64 (orginal) [2021-06-08T17:46:34+02:00] view original

for the string it's a ptr char, I don't know how to pass that kind of thing to the function

kaushalmodi (orginal) [2021-06-08T17:49:00+02:00] view original

You already did that in that example.. "some_string".cstring.

System64 (orginal) [2021-06-08T17:52:18+02:00] view original

That's weird, and I dunno why the procs needs a MusicEmu object to work I know the guy does Music_Emu* (pointer there) = emu

PMunch (orginal) [2021-06-08T23:39:51+02:00] view original

I've imported globals for my Arduino/AVR stuff with {.importc, nodecl.} that basically tells Nim to not do anything with it, assume it exists, and just output the symbol it C code whenever it is used.

System64 (orginal) [2021-06-09T09:31:52+02:00] view original

Shouldn't I use the dynlib: libgmedll pragma?

PMunch (orginal) [2021-06-09T11:50:08+02:00] view original

Yes, of course. But if you add those two pragmas so you get {dynlib: libgmedll, importc, nodecl.} it should work I think.

System64 (orginal) [2021-06-09T13:58:39+02:00] view original

It runs, it compiles, but no sound :/

Mirror of forum.nim-lang.org

8099 :: Wrapping GameMusicEmu library but errors