Re: Having a hard time getting raylib bindings to work
So this is a fun issue now...
I've gotten the bindings to work, but when you want to do something with
Textures, they won't display on the screen. The raylib tracelog says everything
is okay when it came to loading the assets. I'm tracking the issue here:
[https://gitlab.com/define-private-public/raylib-Nim/issues/1](https://gitlab.com/define-private-public/raylib-Nim/issues/1)
I've tried:
* dynamically loading raylib.so at runtime, (via the dynlib pragma)
* statically linking raylib
* statically compiling the raylib source into raylib.nim (via the compile
pragma)
The only thing I can think of is that there is some issue with how c2Nim
translated the Image data structure. I think it has to do with that void *
pointer.
typedef struct Image {
void *data; // Image raw data
int width; // Image base width
int height; // Image base height
int mipmaps;// Mipmap levels, 1 by default
int format; // Data format (TextureFormat type)
} Image;
type
Image* = object
data*: pointer ## Image raw data
width*: cint ## Image base width
height*: cint ## Image base height
mipmaps*: cint ## Mipmap levels, 1 by default
format*: cint ## Data format (TextureFormat type)
Anyone got any ideas?
Re: Having a hard time getting raylib bindings to work
Taking a look [at the man page for
dlopen(3)](http://man7.org/linux/man-pages/man3/dlopen.3.html), I think the
easiest thing to do would to be to wrap the dlopen() call in the Nim code in
something that sets and then resets the LD_LIBRARY_PATH environment variable.
Taking a look at the dlopen() imports in
[dylib.nim](https://github.com/nim-lang/Nim/blob/75345ad1aacf8e2a4d43e4e89f16f6a641d6a9c3/lib/pure/dynlib.nim#L85)
and
[dyncalls.nim](https://github.com/nim-lang/Nim/blob/7e351fc7fa96b4d560c5a51118bab22abb590585/lib/system/dyncalls.nim#L67),
we could use the os modules' getEnv() and putEnv() functions.
E.g.:
from os import getEnv, putEnv
proc real_dlopen(path: cstring, mode: cint): LibHandle
{.importc: "dlopen", header: "".}
proc dlopen(path: cstring, mode: cint): LibHandle=
# Modify the library search path
var
origLibPath = getEnv("LD_LIBRARY_PATH")
newLibPath = originalLibPath & ":/usr/local/lib"
setEnv("LD_LIBRARY_PATH", newLibPath)
result = real_dlopen(path, mode)
setEnv("LD_LIBRARY_PATH", origLibPath)
I think that would do it. Looking also [at OS X's
dlopen()](https://developer.apple.com/legacy/library/documentation/Darwin/Reference/ManPages/man3/dlopen.3.html),
it might be best to add in a block that will get the correct environment
variable to get, set, and reset. Interestingly enough, OS X already searches
/usr/local/lib by defualt. But I'm not sure about /usr/local/Cellar, where is
where homebrew likes to put stuff.
I'll leave the details up to you, but I think this needs to be the case for
Linux at least.
Re: Having a hard time getting raylib bindings to work
> I consider it something that Nim should be concerned about. I am concerned. Now what? How can we improve the situation?
Re: Having a hard time getting raylib bindings to work
It might be aadded to a FAQ but this is clearly a distribution issue. Searching "ubuntu /usr/local/lib" yields 700k+ results according to Google. The first page all have at least one correct answer (export ...). Also no regular package installs in `/usr/local/lib`, only things that you compile from source. It's a well known location for user compiled libraries but I think it's fair to expect people compiling from source to manage their custom `$PATH`
Re: Having a hard time getting raylib bindings to work
I consider it something that Nim should be concerned about. It's already caused me a fair bit of grief trying to get the bindings working on Linux and I'm sure anyone else will run into the same issue down the road. Keep in mind it's not my .so that it was failing to find, but an .so that mine depended on, which was in a well known install location.
Re: Having a hard time getting raylib bindings to work
It is not Nim's problem. >From the `dlopen` doco, you definitely need to either use `ldconfig` or set >`LD_LIBRARY_PATH`, because `dlopen` does not check `/usr/local/lib` by default: o (ELF only) If the executable file for the calling program contains a DT_RPATH tag, and does not contain a DT_RUNPATH tag, then the directories listed in the DT_RPATH tag are searched. o If, at the time that the program was started, the environment variable LD_LIBRARY_PATH was defined to contain a colon-separated list of directories, then these are searched. (As a security measure, this variable is ignored for set-user-ID and set-group- ID programs.) o (ELF only) If the executable file for the calling program contains a DT_RUNPATH tag, then the directories listed in that tag are searched. o The cache file /etc/ld.so.cache (maintained by ldconfig(8)) is checked to see whether it contains an entry for filename. o The directories /lib and /usr/lib are searched (in that order).
Re: Having a hard time getting raylib bindings to work
I think I figured out why setting export LD_LIBRARY_PATH=/usr/local/lib was necessary to make it work. [The dlopen() function](http://man7.org/linux/man-pages/man3/dlopen.3.html) is used under the hood for the dynlib macro on Linux. dlopen() will not search /usr/local/lib by default. It needs to be manually specified... Is this something that maybe should be fixed in the Nim source to also search /usr/local/lib for .so files on unix systems?
Re: Having a hard time getting raylib bindings to work
I use ubuntu (well, xubuntu... technically). I doubt it's a bug on their side. Someone else would have tripped over this way before I would have and fixed it too.
Re: Having a hard time getting raylib bindings to work
Add it through /etc/ld.so.conf.d/ example [here](https://gist.github.com/daryltucker/1c17354fa39ce8cb2285). Relevant [thread in Archlinux forum](https://bbs.archlinux.org/viewtopic.php?id=99807). You might want to file a bug to your linux distro.
Re: Having a hard time getting raylib bindings to work
I've been able to get the Nim bindings to work on Linux using .so files!! There is still a bit of an odd quirk: 1. GLFW 3.2.1 needs to be installed (with cmake -DBUILD_SHARED_LIBS=ON) from source (sudo make install). So those get put in /usr/local/lib 2. raylib needs to be installed (with make SHARED_RAYLIB=YES) from source (sudo make install SHARED_RAYLIB=YES). Those get put in /usr/local/lib too. So at this point, you can compile the core_basic_window.nim example I have in examples. But the problem is that if I try to run it, I get this: ben@linux:examples$ ./core_basic_window /usr/local/lib/libraylib.so: undefined symbol: glfwSetWindowIcon could not load: libraylib.so But when I did export LD_LIBRARY_PATH=/usr/local/lib. then it would run fine. What the hell is going on here? Isn't /usr/local/lib one of the default library search paths? That's where the .so files are put.
Re: Having a hard time getting raylib bindings to work
I found out some more information about the issue on Linux. If you read the link to my edited post at the top it explains a little more. tl;dr the raylib.so Linux .so is broken.
Re: Having a hard time getting raylib bindings to work
you can also add all c files of raylib manually with the compile pragma, like I did it in AntTweakBar [https://github.com/krux02/nimAntTweakBar/blob/master/AntTweakBar.nim#L43](https://github.com/krux02/nimAntTweakBar/blob/master/AntTweakBar.nim#L43)
Re: Having a hard time getting raylib bindings to work
Well you use `dynlib: LIB_RAYLIB` (which is fine) and add linker commands
`{.passL: "-L. -lraylib".}` at the same time! That's wrong! Use one way or the
other, preferably the `dynlib` solution.
Having a hard time getting raylib bindings to work
I'm trying to get some Nim bindings for [this neat little game programming
library called raylib](https://github.com/raysan5/raylib/). But well, I'm
having some difficulties trying to do so.
After cleaning up raylib.h, I was able to use c2nim to auto-generate a .nim. I
commented out a few things and added in the {.importc.} pragmas manually. You
can [see it thus far
here](https://gitlab.com/define-private-public/raylib-Nim/blob/dac2fdab777604053c470b4a41a6f9844148575b/src/raylib.nim).
If you want to help me out, you'll need to build your own copy of raylib, off
of the develop branch, using the SHARED_RAYLIB=YES option at make. There are
some extra instructions on their Wiki.
On Linux: I can't seem to get the library to load at runtime. It compiles fine.
But when I try to run the core_basic_window in examples, I keep on getting
could not load: libraylib.so messages. I tried compiling with the extra
information and it only said that it couldn't find the .so file. I tried
placing the .so in /usr/local/lib, and the current working directory (with
setting LD_LIBRARY_PATH). Still nothing. Does anyone see what's wrong here?
On OS X: It's in a partial working state. For now, the .dylib needs to be in
the same folder as the .nim you want to compile, as well as for to run the
executable. There's a bit of a problem though. It's failing to load some of the
functions from the .dylib, thus making the application crash if I don't have
that {.deadCodeElim: on.} pragma at the top of src/raylib.nim. For example, if
I remove that pragma, it will compile, but at runtime it will say could not
import: LoadMeshEx. The proc id in Nim looks fine to me. Anyone know what's
going wrong?
For Windows: I haven't tried yet. If someone else to try this out and see how
they are going, I'd be very appreciative.
