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

Compile errors and more on raygui #17

Open
greenfork opened this issue Jan 3, 2021 · 12 comments
Open

Compile errors and more on raygui #17

greenfork opened this issue Jan 3, 2021 · 12 comments

Comments

@greenfork
Copy link

greenfork commented Jan 3, 2021

Hi, there are a couple of errors trying to compile just generated files on linux:

raylib.nim(788, 15) Error: expected closing ')'
caused by
proc MemFree*(ptr: pointer)
fixed by renaming ptr
proc MemFree*(ptr1: pointer)
raygui.nim(288, 21) Error: invalid pragma: RAYGUIDEF
caused by missing pragma definition
fixed by adding to raygui.nim
{.pragma: RAYGUIDEF, cdecl, discardable, dynlib: "libraygui" & LEXT.}

Also, not a problem but {.pragma: RLAPI, cdecl, discardable, dynlib: "libraylib" & LEXT.} is generated twice on lines 75-76 in raylib.nim.

UPDATE: when compiling example from examples/texture/image_processing.nim, this chunk of code in raylib.nim does not work

# Temporal hack to avoid breaking old codebases using
# deprecated raylib implementation of these functions
template FormatText*(): auto = TextFormat
template LoadText*(): auto = LoadFileText
template GetExtension*(): auto = GetFileExtension
template GetImageData*(): auto = LoadImageColors

it needs to be located below type definitions and be rewritten to forward all arguments, like this:

template GetImageData*(image: Image): auto = LoadImageColors(image)

It was a bit hard for me to compile raygui library as a dynamic library with no previous experience of doing so, maybe it is helpful to at least leave some notes on how to do this. Here is what I did on linux, probably not ideal:

$ cd /home/grfork/reps
$ git clone https://github.com/raysan5/raygui.git
$ cd raygui/src
$ mkdir build
$ cd build
$ cp ../raygui.h raygui.c
$ gcc -fPIC -c raygui.c -DRAYGUI_IMPLEMENTATION
$ gcc -shared -o libraygui.so raygui.o

After that example from examples/original/basic.nim compiles with:

nim c -o:thegame --passL:"-L/home/grfork/reps/raygui/src/build -lraylib" src/thegame.nim
LD_LIBRARY_PATH=/home/grfork/reps/raygui/src/build/ ./thegame
@Guevara-chan
Copy link
Owner

Phew... It was close !
Fixed ptr issue on main.

@Guevara-chan
Copy link
Owner

RAYGUIDEF issue was gone as well.

@Guevara-chan
Copy link
Owner

Double pragma generation was fixed.

@greenfork
Copy link
Author

Great, thanks!

Also an update on raygui. I found a way to link it statically on "as needed" basis which means that we don't need to compile it as a shared library, just need the copy of source file when compiling the executable. Here is implementation: https://github.com/greenfork/nimraylib_now/blob/master/src/nimraylib_now/raygui.nim#L5. One downside though is that we can't use dynlib with it anymore because of name mangling

@Guevara-chan
Copy link
Owner

Fixed those pesky function name aliasing. Oh well.

@Guevara-chan
Copy link
Owner

Great, thanks!

Also an update on raygui. I found a way to link it statically on "as needed" basis which means that we don't need to compile it as a shared library, just need the copy of source file when compiling the executable. Here is implementation: https://github.com/greenfork/nimraylib_now/blob/master/src/nimraylib_now/raygui.nim#L5. One downside though is that we can't use dynlib with it anymore because of name mangling

Oh, btw: can you do me a favor and compile raygui.h to .DLL that refers to libraylib.dll instead of just raylib.dll ?
It's just as far from convinient as it is right now, since all OS except Windows uses lib* notation and I wish no additional compile-time checks.

@greenfork
Copy link
Author

greenfork commented Jan 17, 2021

compile raygui.h to .DLL that refers to libraylib.dll

Do you mean you want a Linux version of it? On Linux shared libraries have .so extension and on Windows there's no libraylib.dll file, I'm a little confused. If you want a Linux version of shared library for raygui, you can download it here: https://github.com/greenfork/nimraylib_now/releases/tag/v0.4.0

@Guevara-chan
Copy link
Owner

Guevara-chan commented Jan 17, 2021

I'm a little confused.

So are me. Back in 3.0 times and before, there was pretty consistent libraylib.dll available in Windows distribution: https://github.com/raysan5/raylib/releases/download/3.0.0/raylib-3.0.0-Win64-mingw.zip
Now it's called raylib.dll, yet Linux version is still libraylib.so and so is MacOS one. So, I decided to keep my wrapper with old library naming convention.

On other hand: nevermind. Your version works.

@greenfork
Copy link
Author

greenfork commented Jan 17, 2021

Now it's called raylib.dll

As I understand, this is the "conventional" naming for Windows libraries. Considering that you build the latest version from master, changing the name might be the "right" thing to do.

Regarding linking to libraylib.dll - I didn't really get it to work on Windows at all with building raygui as dll so I don't even know which -l flag to pass. I don't have a Windows machine so I had to do remote debugging in this issue (branch which was at the start of the issue) and I didn't get all the details straight.

On other hand: nevermind. Your version works.

Currently our wrappers differ in these points:

  • raylib-forever keeps all the naming as in original, nimraylib_now does camelCase transform and removes prefixes
  • raylib-forever uses dynlib to dynamically load a library, nimraylib_now uses headers to insert direct #include pragmas (which results in longer compilation times and requires header files present to compile the game; but speeds up startup time)
  • raylib-forever takes latest master, nimraylib_now though takes latest master but the exact version is still pinned and it needs some manual work to update it further
  • raylib-forever uses CoffeeScript to parse headers, nimraylib_now uses Nim to parse headers

I understand that my version might seem better in some aspects and it is in fact what I wanted to do, create a "better raylib-forever", I don't want to be a dick about it. I use c2nim app to do code translation, your version does everything in CoffeeScript which is straight mind-blowing to me, I really admire your work there.

@Guevara-chan
Copy link
Owner

Guevara-chan commented Jan 17, 2021

No, I was talking about your version of raygui.dll <3.
Still, your wrapper is rather nice, I will look at example translation progress.

@greenfork
Copy link
Author

Okay, I might have misunderstood you there :)
My version is nothing special though, I just use standard raylib.dll provided on raylib release page for 3.5

@weskerfoot
Copy link

weskerfoot commented Jul 2, 2021

FYI, on Linux, I had to pass -DRAYGUIDEF when I compiled the .so file in order to not make all the declarations static (so that they're actually possible to use with a shared lib)

Full command I used: gcc -shared -fPIC -DRAYGUIDEF -DRAYGUI_IMPLEMENTATION -lraylib -lGL -lm -lpthread -ldl -lrt -lX11 raygui.h -o raygui.so

I hope this helps someone else. Maybe it should be in the docs?

Edit: I also had to rename it from raygui.h to raygui.c or else GCC would refuse to compile it correctly.

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

3 participants