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

2017-07-24 06:14:47

I consider it something that Nim should be concerned about.

I am concerned. Now what? How can we improve the situation?

2017-07-24 09:17:22

Taking a look at the man page for dlopen(3), 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. We wouldn't want it polluting anything else.

Taking a look at the dlopen() imports in dylib.nim and dyncalls.nim, 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: "<dlfcn.h>".}

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(), 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.

2017-07-25 00:58:00

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

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?

2017-08-10 01:17:41
<<<••12••>>>