Closed Jipok closed 7 years ago
Looks like you fixed the first error. I'm going to remove window from line 41, at column 37. I think I copy-pasted the same line and replaced the function and didn't read the C function definition.
C's function:
Display * glfwGetX11Display (void)
Nim's function:
proc GetX11Display*(): pointer
Neither one expects window, and yet I left it. Sorry about that.
Can you tell me what you did for the first error? Cast right?
The latest commit should have fixed it. Any better?
Yes. Previous errors corrected. But now I have other problems
HelloWorld.nim(13, 9) Error: cannot open 'logo'
It corrected by replacing the first letter in the title.
But I don't know what to do with it:
./libbgfx-shared-libRelease.so: undefined symbol: glXGetFBConfigAttrib
I got passed the logo
issue by renaming the file from Logo.nim
to logo.nim
, which it sounds like @Jipok did as well.
However passed that, the error I get is in bgfx/c99/bgfx.h
. I don't understand why it's not using the shared library. I have libbgfx-shared-libRelease.so
in the example folder I am trying to run, and have even tried passing --define:BGFX_SHARED_LIB_API
manually in case it wasn't liking it in the config file. I never successfully get inside the when defined(BGFX_SHARED_LIB_API):
block.
Edit: I use Arch Linux by the way, not OSX.
So I did some research and found the problem... kinda. There seems to be common problem with loading libraries dynamically on Linux, with Nim. However I was able to link bgfx as a shared library and the examples did work after some minor tweaks to bgfx.nim
. Linking to it statically needs some work. Because of that, I think I will have to find a way to build and link bgfx and bx along with nim-bgfx(kinda like how bgfx-rs does it) and sidestep the dynamic loading all together. But I will need time to get that working. On another note... I have a SDL2 backend for the examples coded but it needs more debugging before I can commit it with confidence. Until then, please don't use my library on Linux until I can patch it or the Nim devs fix dynamic loading. :disappointed:
@rosshadden, if you get a runtime error
could not load: .libbgfx-shared-lib(Debug|Release).so
then try one of these:
1) put libbgfx-shared-libRelease.so in /usr/lib or /usr/lib64
2) insert {.passL:"-Wl,-rpath=.".}
to top of bgfx.nim
3) in bgfx.nim replace it
elif defined(linux):
{.pragma: BGFXImport, dynlib: "libbgfx-shared-lib(Debug|Release).so", cdecl.}
on the
elif defined(linux):
{.pragma: BGFXImport, dynlib: "./libbgfx-shared-lib(Debug|Release).so", cdecl.}
I looked into it really quick and found that adding a relative path did nothing but the linker flag did help. I was able to get slightly nicer error messages when I set nim-bgfx to link BGFX as shared in my embedded tests. But it did not fix the dynamic loading. I will dig more into it later today.
I dug into it... nim-bgfx now compiles bgfx with all the appropriate flags on Linux! :penguin: Untested for other platforms but I did try to guess the flags and paths necessary for other platforms. More adjustments are probably needed for those platforms but now you don't have to use flags with this package. Which is super cool! :sunglasses: SDL2 support added but doesn't really work on Linux. I'm hoping that it will work when I start testing it on other platforms. So far the examples default to using GLFW, which does work!
Why skipDirs = @["examples"]
?
First we need nimble install bgfx
. And then another, and download examples separately.
It is not comfortable.
Both examples are compiled and run successfully. But HelloWorld gives an error when closing:
~/.nimble/pkgs/bgfx-0.1.6/embed/bgfx/src/bgfx.cpp (2636): BGFX Shutdown...
~/.nimble/pkgs/bgfx-0.1.6/embed/bgfx/src/bgfx_p.h (2218): BGFX render thread exit
~/.nimble/pkgs/bgfx-0.1.6/embed/bgfx/src/bgfx.cpp (2645): BGFX Shutdown complete.
No stack traceback available
SIGSEGV: Illegal storage access. (Attempt to read from nil?)
Error: execution of an external program failed: '~/.nimble/pkgs/bgfx-0.1.6/examples/00-HelloWorld/HelloWorld '
Compile via C is no longer available? Now only the c ++?
It would appear that the popFrame
function in nim is causing a segmentation fault.
#line 51 "/home/corynull/NimProjects/Nim/lib/system/excpt.nim" framePtr_HRfVMH3jYeBJz6Q6X9b6Ptw = (*framePtr_HRfVMH3jYeBJz6Q6X9b6Ptw).prev;}
At least on the cubes example. Could you give me the gdb backtrace of the crash? I want to compare backtraces. I have a feeling we have different errors and that this might be related to nim.
`(gdb) backtrace
at /home/corynull/NimProjects/Nim/lib/system.nim:2726`
I'm also aware that C is also no longer available if you want to embed bgfx, but bgfx is a C++ library. I could look into finding a workaround for it, there is one other thing I want to try. If you need to use the C backend use the BGFX_SHARED_LIB
define and it will link against it as a shared library without the need to use the C++ backend. I'm going to add BGFX_STATIC_LIB
soon so it can be linked statically.
As for including the examples on install, other packages typically don't do that. You only need to install it once and clone it without the submodules to get the examples.
I'm going to close this issue, could you please start another issue for the segmentation fault with the backtrace?
I improved embedding, you can now build your project in C and bgfx will be built appropriately with a C++ compiler.
I tried to fix it. But getting new bugs: