Compiler Error: Can't find interface for module 'openb3d.b3dglgraphics'

Started by Foolish, March 28, 2018, 23:41:50

Previous topic - Next topic

Foolish

Hi all.
Yesterday I installed the Windows release version of BlitzMax NG (v0.93.3.21 ).  Installation went fine and I was able to compile some simple programs no sweat.  Today I downloaded OpenB3D from the GitHub repository.  I was able to run BMK Make mods.  However, when I try to run the examples I get the error: Can't find interface for module 'openb3d.b3dglgraphics'.

Any suggestions for me?
Thanks

markcwm

Hello,

I just tested the latest commit (a few minutes ago) to openb3d.mod in NG on Windows and it works fine. It might be that the version you downloaded was borked but your message means you do not have the module files built for it, you haven't got the right architecture x64/x86 or standard build options one of debug/release, console/gui, singlethread/multithread.

Foolish

Thanks for the response.

I noticed that it was skipping the folders during compilation. 

I noticed that I copied the subfolders of openb3d.mod-master into the Mods directory and not the openb3d.mod-master folder itself.  However, even then it skipped the folder.  I renamed openb3d.mod-master to just openb3d.mod and it found the folder and tried to compile it with:
bmk makemods -a -w -g x64 openb3d

It started to compile and got to 42% and then I encountered this error:

In file included from In file included from
ax/BlitzMax/mod/openb3d.mod/openb3dlib.mod/data.h:4:0:
,
                 from D:/Blitzmax/BlitzMax/mod/openb3d.mod/openb3dlib.mod/openb3d/src/pick.h:33:21:D:/Blitzmax/BlitzMax/mod/openb3d.mod/openb3dlib.mod/data.cpp:3 :
error: D:/Blitzmax/BlitzMax/mod/openb3d.mod/openb3dlib.mod/openb3d/src/pick.h:33:21:' constexprerror: ' needed for in-class initialization of static data member ''const float Pick::EPSILONconstexpr' of non-integral type [' needed for in-class initialization of static data member '-fpermissiveconst float Pick::EPSILON]
  static const float ' of non-integral type [EPSILON-fpermissive=0.0001;
                     ]
  static const float
=0.0001;
                     ^~~~~~~
Build Error: failed to compile (1) D:/Blitzmax/BlitzMax/mod/openb3d.mod/openb3dlib.mod/methods.cpp
D:\Blitzmax\BlitzMax\bin>In file included from D:/Blitzmax/BlitzMax/mod/openb3d.mod/openb3dlib.mod/openb3d/src/camera.cpp:17:0:
D:/Blitzmax/BlitzMax/mod/openb3d.mod/openb3dlib.mod/openb3d/src/pick.h:33:21: error: 'constexpr' needed for in-class initialization of static data member 'const float Pick::EPSILON' of non-integral type [-fpermissive]
  static const float EPSILON=0.0001;

 
Any other advise?

Thanks!

markcwm

It's because you have MinGW GCC 7.2 which conforms to C++11, the fix seems to be to replace all "static const" with "static constexpr". I'll have to update my NG before I can test.

Foolish

I made the change to the data type as suggested and the build completed successfully.

However, when I run the examples, I get an ACCESS VIOLATION.  I did notice the following compiler warning when building OpenB3D.

[ 18%] Processing:openb3d.bmx
Compile Warning: In call to Function MemAlloc:Byte Ptr(size:size_t). Argument #1 is "Int" but declaration is "size_t".
[D:/Blitzmax/BlitzMax/mod/openb3d.mod/openb3d.mod/inc/TGLShader.bmx;327;0]

Compile Warning: In call to Function MemAlloc:Byte Ptr(size:size_t). Argument #1 is "Int" but declaration is "size_t".
[D:/Blitzmax/BlitzMax/mod/openb3d.mod/openb3d.mod/inc/TGLShader.bmx;365;0]

I don't know if that is helpful or not.  I do really appreciate you looking into this.

Thanks!

markcwm

Okay, unfortunately openb3d does not compile with GCC 7.2, I don't know why as there is no error message, I tried in x86 (32-bit) and it was the same, just an EAV. There are no valid pointers coming from the library everything is just null, so I'm at a loss for why that might be.

I'm going to suggest to use MinGW 5.1.0 until this is fixed. Just go to the NG releases and get NG Win32 0.87 it has 5.1.0 in a MinGW32 folder, just copy that over to NG 0.93 and rename MinGW32x64 and x86 folders so they won't be recognized by BMK, then rebuild all modules.

Derron

Maybe you could raise an issue on
https://github.com/bmx-ng/b3d.mod

as this way Brucey might check out what is happening and maybe is able to fix it.


@ EAV
What did GDB (MinGWPath\bin\gdb.exe -r your-gdb-enabled-debug-binary) say ?

bye
Ron

Derron

I tried to compile the 64bit variant (in debug) - so I tried the "examples/cubemap.bmx"

It fails:
Code (BlitzMax) Select

Function CreateCamera:TCamera( parent:TEntity=Null )
Local instance:Byte Ptr=CreateCamera_( TEntity.EntityExists( parent ) )


gdb was a bit useless - should normally display some useful stuff

0x00000000005070c6 in ?? ()
(gdb) bt
#0  0x00000000005070c6 in ?? ()
#1  0x00000000004f6de9 in ?? ()
#2  0x0000000000440fb5 in ?? ()
#3  0x00000000004024a8 in ?? ()
#4  0x00000000005b18e7 in ?? ()
#5  0x00000000006a01b2 in ?? ()
#6  0x00000000004013f7 in ?? ()
#7  0x00000000004014fb in ?? ()
#8  0x0000000077d5970c in KERNEL32!BaseProcessStart () from C:\WINDOWS\system32\kernel32.dll
#9  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)


bye
Ron

Kippykip

Yeah I was having issues converting types on the new version, in my case Float(Sin()) has problems

BMX-NG 0.87 worked fine beforehand, I'd recommend sticking with that version for the meantime.

Derron

Code (BlitzMax) Select

SuperStrict
Framework Brl.StandardIO
Import Brl.GLGraphics
Import Brl.glmax2D

Graphics 800, 600

Local img:TImage = CreateImage(100,100, PF_RGBA8888)
Local YBounce:Int = 0
Repeat
Cls
YBounce = YBounce + 6
DrawImage(img:TImage, GraphicsWidth()/2 - (ImageWidth(img:TImage)/2), Float(Sin(YBounce)) * 5 + 70)

Flip
Until AppTerminate() Or KeyHit(KEY_ESCAPE) Or KeyDown(KEY_ESCAPE)


Compiles fine ...with v0.93. Do you use SuperStrict? Where is "YBounce" declared?
If you think its the float(Sin(YBounce)) - it should fail if you add above that line:

local myValue:Float = Float(Sin(YBounce)) * 5 + 70
DrawImage ...

If that does not fail there, then another expression is failing.

Also you do not have to add the ":TImage" everytime.
This will be shorter and doing the same:
DrawImage(img, (GraphicsWidth() - img.width)/2, Float(Sin(YBounce) * 5 + 70))

The "Float(" is only needed as Sin() returns a double, this warning could be disabled in the compilation flags.


Edit: the culprit is the "GraphicsWidth" which you use there .... without "()" it should fail (if it did not in 0.87 you now know why you need to upgrade). Add the two brackets and it should compile ("GraphicsWidth()"). AND NO ... it would also not compile with vanilla (regardless if you used SuperStrict to catch such errors or not) - it blames "int" <> "int()" with or without (super)strict.

bye
Ron

Kippykip

Quote from: Derron on March 30, 2018, 12:48:27
Code (BlitzMax) Select

SuperStrict
Framework Brl.StandardIO
Import Brl.GLGraphics
Import Brl.glmax2D

Graphics 800, 600

Local img:TImage = CreateImage(100,100, PF_RGBA8888)
Local YBounce:Int = 0
Repeat
Cls
YBounce = YBounce + 6
DrawImage(img:TImage, GraphicsWidth()/2 - (ImageWidth(img:TImage)/2), Float(Sin(YBounce)) * 5 + 70)

Flip
Until AppTerminate() Or KeyHit(KEY_ESCAPE) Or KeyDown(KEY_ESCAPE)


Compiles fine ...with v0.93. Do you use SuperStrict? Where is "YBounce" declared?
If you think its the float(Sin(YBounce)) - it should fail if you add above that line:

local myValue:Float = Float(Sin(YBounce)) * 5 + 70
DrawImage ...

If that does not fail there, then another expression is failing.

Also you do not have to add the ":TImage" everytime.
This will be shorter and doing the same:
DrawImage(img, (GraphicsWidth() - img.width)/2, Float(Sin(YBounce) * 5 + 70))

The "Float(" is only needed as Sin() returns a double, this warning could be disabled in the compilation flags.


Edit: the culprit is the "GraphicsWidth" which you use there .... without "()" it should fail (if it did not in 0.87 you now know why you need to upgrade). Add the two brackets and it should compile ("GraphicsWidth()"). AND NO ... it would also not compile with vanilla (regardless if you used SuperStrict to catch such errors or not) - it blames "int" <> "int()" with or without (super)strict.

bye
Ron

Oooh, must've missed that when I wrote this code ages ago. Weird that it worked in all NG versions previously haha.

Yellownakji

Oh, interesting because () was not needed in previous versions for graphicswidth, like kippy said.   It always accepted it;  ???  but i think i am going to still stick with version 0.87, anyways for now.

But at least the source compiles again, and if we do update, we know what to adapt. :-*

and NO, we weren't gonna ask about vanilla but thanks for the info...

(..I've been secretly removing the types from kip's variables but he still does it lol)

Foolish

In reference to this from Mark

Quote from: markcwm on March 30, 2018, 04:51:42
Okay, unfortunately openb3d does not compile with GCC 7.2, I don't know why as there is no error message, I tried in x86 (32-bit) and it was the same, just an EAV. There are no valid pointers coming from the library everything is just null, so I'm at a loss for why that might be.

I'm going to suggest to use MinGW 5.1.0 until this is fixed. Just go to the NG releases and get NG Win32 0.87 it has 5.1.0 in a MinGW32 folder, just copy that over to NG 0.93 and rename MinGW32x64 and x86 folders so they won't be recognized by BMK, then rebuild all modules.

I followed your advise and am able to run the examples.  Many thanks.  Its great to be playing with Blitzmax again with OpenB3D.  Your assistance is very much appreciated.

markcwm

QuoteMaybe you could raise an issue on
https://github.com/bmx-ng/b3d.mod

as this way Brucey might check out what is happening and maybe is able to fix it.

Thanks Derron, I think I'll do that as this one seems a bit out of my league. I tried a few things out but none of them fixed it.

I tried extern "C" from functions.h (usually not included) but including it caused undefined references when building so I had to go back to extern "C" in functions.cpp - it seems you don't need prototypes for external functions. I also tried adding "cc_opts: -std=c++11" which works on older GCC but it doesn't seem to be the problem. I'm wondering if it isn't an issue with BCC as I can't find anything about this on searches.

Glad you got it working with 5.1.0 Foolish. I'll going to move on from this now, I've to finish the native LoadTexture functions.