bitmap loading problem

edited February 2011 in Help request
Hi, I am at linux x64 platform.

I'm trying to build grey's tutorial3 [http://orx-project.org/wiki/en/orx/tutorials/community/grey/tutorial3] )the forst part).

The image is shown bad, I can see only crapped pixels some lines and dots. In debug mode I see:


[2011-02-20 22:12:21] <SYSTEM> (orxConfig_Load() - home/basiek/Pulpit/orx/orx-1.2/code/src/core/orxConfig.c:2616) [GravityFighters.ini]: Begins the processing of included file @MainMenu.ini@.
[2011-02-20 22:12:21] <SYSTEM> (orxConfig_Load() - home/basiek/Pulpit/orx/orx-1.2/code/src/core/orxConfig.c:2622) [GravityFighters.ini]: Ends the processing of included file @MainMenu.ini@.
[2011-02-20 22:12:21] <DISPLAY> (orxDisplay_GLFW_SetBitmapData() - include/../plugins/Display/GLFW/orxDisplay.c:1103) Can't set bitmap data: format needs to be RGBA.
[2011-02-20 22:12:21] <DISPLAY> (orxFont_CreateDefaultFont() - home/basiek/Pulpit/orx/orx-1.2/code/src/display/orxFont.c:301) Can't set default font's bitmap's data.
[2011-02-20 22:12:21] <RENDER> (orxRender_RenderViewport() - include/../plugins/Render/Home/orxRender.c:904) [orxOBJECT 0x11ebff8 / SoldierNameTag -> orxBITMAP 0xdc7030] couldn't be rendered.

I used precompiled binary libs I found on this forum, and compiled orx myself. Result is the same.

What's wrong?

Comments

  • edited February 2011
    Hi Bwiklak, firstly, welcome! :)

    Secondly, this looks like an issue with the font processing. Does the same problem happen if you comment out (or delete) these lines:
    [SoldierNameTag] ;============================
    Graphic              = SoldierName
    Position             = (0.0, -32.0, 0.0)
     
    [SoldierName] ;===============================
    Text                 = SoldierNameString
    Color                = (255, 255, 255)
    Pivot                = center
     
    [SoldierNameString] ;=========================
    String               = Soldier
    
  • edited February 2011
    Hi Grey.
    Welcome!
    Thanks for the grate soft, and thank you for clear and useful tutorials.

    Unfortunately cutting off the ini part resulted in this output:


    [2011-02-21 07:42:01] <SYSTEM> (orxConfig_Load() - home/basiek/Pulpit/orx/orx-1.2/code/src/core/orxConfig.c:2616) [GravityFighters.ini]: Begins the processing of included file @MainMenu.ini@.
    [2011-02-21 07:42:01] <SYSTEM> (orxConfig_Load() - home/basiek/Pulpit/orx/orx-1.2/code/src/core/orxConfig.c:2622) [GravityFighters.ini]: Ends the processing of included file @MainMenu.ini@.
    [2011-02-21 07:42:01] <DISPLAY> (orxDisplay_GLFW_SetBitmapData() - include/../plugins/Display/GLFW/orxDisplay.c:1103) Can't set bitmap data: format needs to be RGBA.
    [2011-02-21 07:42:01] <DISPLAY> (orxFont_CreateDefaultFont() - home/basiek/Pulpit/orx/orx-1.2/code/src/display/orxFont.c:301) Can't set default font's bitmap's data.


    even more, even providing plain ini file results in this:


    [2011-02-21 07:43:06] <SYSTEM> (orxConfig_Load() - home/basiek/Pulpit/orx/orx-1.2/code/src/core/orxConfig.c:2616) [GravityFighters.ini]: Begins the processing of included file @MainMenu.ini@.
    [2011-02-21 07:43:06] <SYSTEM> (orxConfig_Load() - home/basiek/Pulpit/orx/orx-1.2/code/src/core/orxConfig.c:2622) [GravityFighters.ini]: Ends the processing of included file @MainMenu.ini@.
    [2011-02-21 07:43:06] <DISPLAY> (orxDisplay_GLFW_SetBitmapData() - include/../plugins/Display/GLFW/orxDisplay.c:1103) Can't set bitmap data: format needs to be RGBA.
    [2011-02-21 07:43:06] <DISPLAY> (orxFont_CreateDefaultFont() - home/basiek/Pulpit/orx/orx-1.2/code/src/display/orxFont.c:301) Can't set default font's bitmap's data.
    [2011-02-21 07:43:07] <OBJECT> (orxObject_CreateFromConfig() - home/basiek/Pulpit/orx/orx-1.2/code/src/object/orxObject.c:1098) Failed to find config section named Scene.

    My soldier looks like in the attachment. soldier.png
  • edited February 2011
    Hi bwiklak, and sorry for the late reply!

    Grey's idea sounded good but there's something going fundamentally wrong there. This assert can only happen when trying to fill a texture with a wrong sized-buffer.

    Can you give us details about the version of orx you're running and your video card? Orx should work correctly on linux64 (I know that Eyecreate was able to run it and I think Grey also gave it a shot).

    If you're not currently using the svn version, I'd recommend to get it as it might be a bug that has been fixed since 1.2 (one can always hope! ;)).

    If you want a native 64bit version, you'll need to recompile some external dependencies of orx first: in the /extern folder, you need to recompile GLFW, Box2D, libsndfile and SOIL. The most important ones in your case being GLFW and SOIL.
    There are codelite projects for all these libraries. Then you simply need to recompile orx (embedded dynamic debug&release).

    If you feel like syncing the svn and trying that, please let me know as it'd be of great help for fixing whatever is going wrong on linux64 and would be much appreciated! :)

    Sorry for the inconvenience!
  • edited February 2011
    Hi gays,
    I'll be very happy to help and widen my understanding of orx.

    I'm on HP ProBook 4520s ( i3-370M, integrated graphics )
    I'm running the latest Ubuntu 64 system, intel drivers seem to be ok ( for example WebGL sort of works ).

    I have compiled Box2D and GLFW from extern dir, the rest is form debian's repository. Maybe there's a problem. I had some warnings during compilation of embedded dynamic I don't remember now.

    In 9-10 ours I'll be at home and I'll try to build SOIL and libsndfile form extern. I hope codelite will pick these libs, not those from /usr/lib/ . We'll see what happens.

    I could try to debug this error but my codelite debugger fails to set brakepoints, no idea why. I'm to ... let's face it, lazy, to learn gdb :(

    The's no inconvenience, the olny problem is that there are so many manually changed libs, it would be very good it their maintainers could incorporate changes in official releases. Debian repositories are huge boost in case of libs and apps maintenance.

    Thanks a lot!
    See you in 10-11 hours ( I wonder what time is it at your place now ).
  • edited February 2011
    Ah, an intel card. Well I hope we'll manage to find a solution for that. :)
    Do you have any trouble with other OpenGL-based applications, beside WebGL?

    SOIL and libsndfile can come from your system. I didn't make any significant changes.
    I simply removed OpenGL code from SOIL as I'm not using it in orx and made sure libsndfile would compile on windows as its author doesn't want to do any work to maintain non-C99 standard compilers: http://www.mega-nerd.com/libsndfile/FAQ.html#Q019
    I can understand his position but I don't think it's that hard to maintain a couple of different compilers, especially when they're as popular as visual studio. And I begin to have some experience in this field too. ;)

    The biggest changes are in Box2D (per-object custom gravity and non-sliding characters on slopes) and in GLFW (a bunch of small corrections and made sure it'd behave the same way as SDL/SFML plugins). I'll probably have to integrate a newer version of GLFW one of these days, I'll ask Camilla if she plans on making a release at some point during 2011.

    Out of curiosity, are there any other video drivers for your card that would be more OpenGL friendly? I know that some people got the same kind of issue with the default OpenGL drivers on Win7 but got it fixed by updating their video card drivers.

    Have a good day!

    (I'm living in San Francisco's area and it now is 23:45. Time to update the shader lighting tutorial with pre-computed normal maps and then bed time! ;))
  • edited February 2011
    Ok, I'll try to mess around with intel HD driver, I hope I'll manage to do something, I've just bought this laptop!
  • edited February 2011
    Hopefully up-to-date driver and the svn version should resolve your issues. Let us know if it's not the case.
  • edited February 2011
    Hi all.

    I've upgraded my video drivers to the newest one, and compiled from svn.

    Good news are: my driver works good in case of OpenGL ES, even my favorite test, the Google body browser, works great.

    Bad news, I run into problems in compiling orx.

    First things first.

    1) Compilation errors:
    ../../../include/../plugins/Display/GLFW/orxDisplay.c: In function ‘orxSTATUS orxDisplay_GLFW_SetVideoMode(const orxDISPLAY_VIDEO_MODE*)’:
    ../../../include/../plugins/Display/GLFW/orxDisplay.c:2059: error: cast from ‘void*’ to ‘GLhandleARB’ loses precision
    In file included from /home/basiek/Pulpit/orx/orx/trunk/code/src/plugin/orxPlugin_EmbeddedList.cpp:75:
    ../../../include/../plugins/Display/GLFW/orxDisplay.c: In function ‘void* orxDisplay_GLFW_CreateShader(const orxCHAR*, const orxLINKLIST*)’:
    ../../../include/../plugins/Display/GLFW/orxDisplay.c:2653: error: cast from ‘void*’ to ‘GLhandleARB’ loses precision

    I changed the code to:
    pstShader->hProgram = (GLhandleARB)-1;
    (don't kill me)

    2) Thake a look:
    Building project:[ orxLIB - Linux Embedded Dynamic Release ]
    [...]
    g++ -shared -fPIC -o ../../../lib/dynamic/liborx.so Linux_Embedded_Dynamic_Release/anim_orxAnim.o Linux_Embedded_Dynamic_Release/anim_orxAnimPointer.o Linux_Embedded_Dynamic_Release/anim_orxAnimSet.o Linux_Embedded_Dynamic_Release/base_orxModule.o Linux_Embedded_Dynamic_Release/base_orxType.o Linux_Embedded_Dynamic_Release/core_orxClock.o Linux_Embedded_Dynamic_Release/core_orxConfig.o Linux_Embedded_Dynamic_Release/core_orxEvent.o Linux_Embedded_Dynamic_Release/core_orxLocale.o Linux_Embedded_Dynamic_Release/core_orxSystem.o Linux_Embedded_Dynamic_Release/debug_orxDebug.o Linux_Embedded_Dynamic_Release/debug_orxFPS.o Linux_Embedded_Dynamic_Release/display_orxDisplay.o Linux_Embedded_Dynamic_Release/display_orxFont.o Linux_Embedded_Dynamic_Release/display_orxGraphic.o Linux_Embedded_Dynamic_Release/display_orxScreenshot.o Linux_Embedded_Dynamic_Release/display_orxText.o Linux_Embedded_Dynamic_Release/display_orxTexture.o Linux_Embedded_Dynamic_Release/io_orxFile.o Linux_Embedded_Dynamic_Release/io_orxInput.o Linux_Embedded_Dynamic_Release/io_orxJoystick.o Linux_Embedded_Dynamic_Release/io_orxKeyboard.o Linux_Embedded_Dynamic_Release/io_orxMouse.o Linux_Embedded_Dynamic_Release/main_orxParam.o Linux_Embedded_Dynamic_Release/math_orxMath.o Linux_Embedded_Dynamic_Release/math_orxVector.o Linux_Embedded_Dynamic_Release/memory_orxBank.o Linux_Embedded_Dynamic_Release/memory_orxMemory.o Linux_Embedded_Dynamic_Release/object_orxFrame.o Linux_Embedded_Dynamic_Release/object_orxObject.o Linux_Embedded_Dynamic_Release/object_orxSpawner.o Linux_Embedded_Dynamic_Release/object_orxStructure.o Linux_Embedded_Dynamic_Release/physics_orxBody.o Linux_Embedded_Dynamic_Release/physics_orxPhysics.o Linux_Embedded_Dynamic_Release/plugin_orxPlugin.o Linux_Embedded_Dynamic_Release/plugin_orxPlugin_EmbeddedList.o Linux_Embedded_Dynamic_Release/render_orxCamera.o Linux_Embedded_Dynamic_Release/render_orxFX.o Linux_Embedded_Dynamic_Release/render_orxFXPointer.o Linux_Embedded_Dynamic_Release/render_orxRender.o Linux_Embedded_Dynamic_Release/render_orxShader.o Linux_Embedded_Dynamic_Release/render_orxShaderPointer.o Linux_Embedded_Dynamic_Release/render_orxViewport.o Linux_Embedded_Dynamic_Release/sound_orxSound.o Linux_Embedded_Dynamic_Release/sound_orxSoundSystem.o Linux_Embedded_Dynamic_Release/sound_orxSoundPointer.o Linux_Embedded_Dynamic_Release/utils_orxHashTable.o Linux_Embedded_Dynamic_Release/utils_orxLinkList.o Linux_Embedded_Dynamic_Release/utils_orxString.o Linux_Embedded_Dynamic_Release/utils_orxTree.o "-L." "-L../../../../extern/glfw-2.7/lib/linux" "-L../../../../extern/SOIL/lib/linux" "-L../../../../extern/libsndfile-1.0.22/lib/linux" "-L../../../../extern/SDL-1.2.14/lib/linux" "-L../../../../extern/Box2D_2.1.3/lib/linux" -lsndfile -lopenal -ldl -lm -lglfw -lSOIL -lBox2D -lGL -lX11 -lXrandr -s
    /usr/bin/ld: skipping incompatible ../../../../extern/glfw-2.7/lib/linux/libglfw.a when searching for -lglfw
    /usr/bin/ld: skipping incompatible ../../../../extern/SOIL/lib/linux/libSOIL.a when searching for -lSOIL
    /usr/bin/ld: skipping incompatible ../../../../extern/Box2D_2.1.3/lib/linux/libBox2D.a when searching for -lBox2D
    Executing Post Build commands ...

    I've build Box2D, siol etc. myself, no idea why it does not work.

    then, ldd from my app compiled in debug mode:

    basiek@basiek:~/.codelite/Game/Debug$ ldd GravityFighters
    linux-vdso.so.1 => (0x00007fff1b7ed000)
    liborxd.so => /usr/lib/liborxd.so (0x00007fc904b95000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fc90488f000)
    libm.so.6 => /lib/libm.so.6 (0x00007fc90460b000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fc9043f5000)
    libc.so.6 => /lib/libc.so.6 (0x00007fc904072000)
    libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x00007fc903e0c000)
    libopenal.so.1 => /usr/lib/libopenal.so.1 (0x00007fc903bb4000)
    libdl.so.2 => /lib/libdl.so.2 (0x00007fc9039b0000)
    libglfw.so.2 => /usr/lib/libglfw.so.2 (0x00007fc90379f000)
    libSOIL.so.1 => /usr/lib/libSOIL.so.1 (0x00007fc903588000)
    libBox2D.so.2.1.0 => /usr/local/lib/libBox2D.so.2.1.0 (0x00007fc90334f000)
    libGL.so.1 => /usr/lib/mesa/libGL.so.1 (0x00007fc9030dd000)
    libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fc902da7000)
    libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007fc902b9e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fc904f52000)
    libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x00007fc902953000)
    libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007fc902484000)
    libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007fc902258000)
    libogg.so.0 => /usr/lib/libogg.so.0 (0x00007fc902050000)
    librt.so.1 => /lib/librt.so.1 (0x00007fc901e48000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc901c2b000)
    libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fc901a18000)
    libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007fc901815000)
    libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007fc90160f000)
    libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007fc901408000)
    libdrm.so.2 => /lib/libdrm.so.2 (0x00007fc9011fd000)
    libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fc900fe1000)
    libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007fc900dd6000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fc900bd3000)
    libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fc9009cc000)


    I'm not surprised it uses my repo libs. I'm not sure why it does not use precompiles libs. The same result in embedded static.

    the final result:
    basiek@basiek:~/.codelite/Game/Debug$ ./GravityFighters
    [2011-02-21 23:49:28] <ASSERT> (orxEvent_AddHandler() - home/basiek/Pulpit/orx/orx/trunk/code/src/core/orxEvent.c:215) [Assertion failed] : <orxFLAG_TEST(sstEvent.u32Flags, orxEVENT_KU32_STATIC_FLAG_READY)>
    Pułapka debuggera/breakpoint

    Looking forward for any ideas,
    Bartek

    (Plese call me Bartek, bwiklak is the first letter of my first name and my surname - it sounds strange even in my native tongue :) - I know, I chosen it myself )
  • edited February 2011
    bwiklak wrote:
    Hi all.

    Hi Bartek!
    I've upgraded my video drivers to the newest one, and compiled from svn.

    Good news are: my driver works good in case of OpenGL ES, even my favorite test, the Google body browser, works great.

    That's indeed very good news!
    Bad news, I run into problems in compiling orx.

    First things first.

    1) Compilation errors:
    ../../../include/../plugins/Display/GLFW/orxDisplay.c: In function ‘orxSTATUS orxDisplay_GLFW_SetVideoMode(const orxDISPLAY_VIDEO_MODE*)’:
    ../../../include/../plugins/Display/GLFW/orxDisplay.c:2059: error: cast from ‘void*’ to ‘GLhandleARB’ loses precision
    In file included from /home/basiek/Pulpit/orx/orx/trunk/code/src/plugin/orxPlugin_EmbeddedList.cpp:75:
    ../../../include/../plugins/Display/GLFW/orxDisplay.c: In function ‘void* orxDisplay_GLFW_CreateShader(const orxCHAR*, const orxLINKLIST*)’:
    ../../../include/../plugins/Display/GLFW/orxDisplay.c:2653: error: cast from ‘void*’ to ‘GLhandleARB’ loses precision

    I changed the code to:
    pstShader->hProgram = (GLhandleARB)-1;
    (don't kill me)

    You did well, I'll update the code myself to prevent this issue (didn't think of 64bit pointers when I wrote it, my bad).
    2) Thake a look:
    Building project:[ orxLIB - Linux Embedded Dynamic Release ]
    [...]
    g++ -shared -fPIC -o ../../../lib/dynamic/liborx.so Linux_Embedded_Dynamic_Release/anim_orxAnim.o Linux_Embedded_Dynamic_Release/anim_orxAnimPointer.o Linux_Embedded_Dynamic_Release/anim_orxAnimSet.o Linux_Embedded_Dynamic_Release/base_orxModule.o Linux_Embedded_Dynamic_Release/base_orxType.o Linux_Embedded_Dynamic_Release/core_orxClock.o Linux_Embedded_Dynamic_Release/core_orxConfig.o Linux_Embedded_Dynamic_Release/core_orxEvent.o Linux_Embedded_Dynamic_Release/core_orxLocale.o Linux_Embedded_Dynamic_Release/core_orxSystem.o Linux_Embedded_Dynamic_Release/debug_orxDebug.o Linux_Embedded_Dynamic_Release/debug_orxFPS.o Linux_Embedded_Dynamic_Release/display_orxDisplay.o Linux_Embedded_Dynamic_Release/display_orxFont.o Linux_Embedded_Dynamic_Release/display_orxGraphic.o Linux_Embedded_Dynamic_Release/display_orxScreenshot.o Linux_Embedded_Dynamic_Release/display_orxText.o Linux_Embedded_Dynamic_Release/display_orxTexture.o Linux_Embedded_Dynamic_Release/io_orxFile.o Linux_Embedded_Dynamic_Release/io_orxInput.o Linux_Embedded_Dynamic_Release/io_orxJoystick.o Linux_Embedded_Dynamic_Release/io_orxKeyboard.o Linux_Embedded_Dynamic_Release/io_orxMouse.o Linux_Embedded_Dynamic_Release/main_orxParam.o Linux_Embedded_Dynamic_Release/math_orxMath.o Linux_Embedded_Dynamic_Release/math_orxVector.o Linux_Embedded_Dynamic_Release/memory_orxBank.o Linux_Embedded_Dynamic_Release/memory_orxMemory.o Linux_Embedded_Dynamic_Release/object_orxFrame.o Linux_Embedded_Dynamic_Release/object_orxObject.o Linux_Embedded_Dynamic_Release/object_orxSpawner.o Linux_Embedded_Dynamic_Release/object_orxStructure.o Linux_Embedded_Dynamic_Release/physics_orxBody.o Linux_Embedded_Dynamic_Release/physics_orxPhysics.o Linux_Embedded_Dynamic_Release/plugin_orxPlugin.o Linux_Embedded_Dynamic_Release/plugin_orxPlugin_EmbeddedList.o Linux_Embedded_Dynamic_Release/render_orxCamera.o Linux_Embedded_Dynamic_Release/render_orxFX.o Linux_Embedded_Dynamic_Release/render_orxFXPointer.o Linux_Embedded_Dynamic_Release/render_orxRender.o Linux_Embedded_Dynamic_Release/render_orxShader.o Linux_Embedded_Dynamic_Release/render_orxShaderPointer.o Linux_Embedded_Dynamic_Release/render_orxViewport.o Linux_Embedded_Dynamic_Release/sound_orxSound.o Linux_Embedded_Dynamic_Release/sound_orxSoundSystem.o Linux_Embedded_Dynamic_Release/sound_orxSoundPointer.o Linux_Embedded_Dynamic_Release/utils_orxHashTable.o Linux_Embedded_Dynamic_Release/utils_orxLinkList.o Linux_Embedded_Dynamic_Release/utils_orxString.o Linux_Embedded_Dynamic_Release/utils_orxTree.o "-L." "-L../../../../extern/glfw-2.7/lib/linux" "-L../../../../extern/SOIL/lib/linux" "-L../../../../extern/libsndfile-1.0.22/lib/linux" "-L../../../../extern/SDL-1.2.14/lib/linux" "-L../../../../extern/Box2D_2.1.3/lib/linux" -lsndfile -lopenal -ldl -lm -lglfw -lSOIL -lBox2D -lGL -lX11 -lXrandr -s
    /usr/bin/ld: skipping incompatible ../../../../extern/glfw-2.7/lib/linux/libglfw.a when searching for -lglfw
    /usr/bin/ld: skipping incompatible ../../../../extern/SOIL/lib/linux/libSOIL.a when searching for -lSOIL
    /usr/bin/ld: skipping incompatible ../../../../extern/Box2D_2.1.3/lib/linux/libBox2D.a when searching for -lBox2D
    Executing Post Build commands ...

    I've build Box2D, siol etc. myself, no idea why it does not work.

    That's the very weird part. It's looking for our customized version first but doesn't like them for a reason I don't understand. When you rebuilt them yourself, was it with the same compiler? Can you paste here the resulting command line and output? It looks like they are not compiled with the same version of gcc or with the same flags.
    then, ldd from my app compiled in debug mode:

    basiek@basiek:~/.codelite/Game/Debug$ ldd GravityFighters
    linux-vdso.so.1 => (0x00007fff1b7ed000)
    liborxd.so => /usr/lib/liborxd.so (0x00007fc904b95000)
    libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007fc90488f000)
    libm.so.6 => /lib/libm.so.6 (0x00007fc90460b000)
    libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007fc9043f5000)
    libc.so.6 => /lib/libc.so.6 (0x00007fc904072000)
    libsndfile.so.1 => /usr/lib/libsndfile.so.1 (0x00007fc903e0c000)
    libopenal.so.1 => /usr/lib/libopenal.so.1 (0x00007fc903bb4000)
    libdl.so.2 => /lib/libdl.so.2 (0x00007fc9039b0000)
    libglfw.so.2 => /usr/lib/libglfw.so.2 (0x00007fc90379f000)
    libSOIL.so.1 => /usr/lib/libSOIL.so.1 (0x00007fc903588000)
    libBox2D.so.2.1.0 => /usr/local/lib/libBox2D.so.2.1.0 (0x00007fc90334f000)
    libGL.so.1 => /usr/lib/mesa/libGL.so.1 (0x00007fc9030dd000)
    libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fc902da7000)
    libXrandr.so.2 => /usr/lib/libXrandr.so.2 (0x00007fc902b9e000)
    /lib64/ld-linux-x86-64.so.2 (0x00007fc904f52000)
    libFLAC.so.8 => /usr/lib/libFLAC.so.8 (0x00007fc902953000)
    libvorbisenc.so.2 => /usr/lib/libvorbisenc.so.2 (0x00007fc902484000)
    libvorbis.so.0 => /usr/lib/libvorbis.so.0 (0x00007fc902258000)
    libogg.so.0 => /usr/lib/libogg.so.0 (0x00007fc902050000)
    librt.so.1 => /lib/librt.so.1 (0x00007fc901e48000)
    libpthread.so.0 => /lib/libpthread.so.0 (0x00007fc901c2b000)
    libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fc901a18000)
    libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007fc901815000)
    libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007fc90160f000)
    libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007fc901408000)
    libdrm.so.2 => /lib/libdrm.so.2 (0x00007fc9011fd000)
    libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fc900fe1000)
    libXrender.so.1 => /usr/lib/libXrender.so.1 (0x00007fc900dd6000)
    libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fc900bd3000)
    libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fc9009cc000)


    I'm not surprised it uses my repo libs. I'm not sure why it does not use precompiles libs. The same result in embedded static.

    Well, as we saw earlier, ld didn't want to use our custom version so it defaulted to the distribution ones. As soon as we figure out why ld doesn't work, everything should be fine.
    I saw that it uses orx from /usr/lib, is that the one you just compiled earlier?
    Looking forward for any ideas,
    Bartek

    (Plese call me Bartek, bwiklak is the first letter of my first name and my surname - it sounds strange even in my native tongue :) - I know, I chosen it myself )

    Will do, Bartek! =) As for the ideas, right now I can only think of trying to figure out what's going wrong in the binaries produced for the extern dependencies.
    What is the output when you can the command file on the compiled .o files for Box2D or GLFW (folder build/CodeLite/Debug|Release), for example, and then on liborx.so?
  • edited February 2011
    Hi, I'll try to investigate it today.

    It seems we have terrible time shift, here in Poland it's 8:22 am and I'm in office now. As soon as I'm back home (and spend some time with my family) I'll post my findings.

    All libs were compiled using codelite from workspaces provided in a trunk. Maybe there's something wrong with compiler flags. I was to learn linking process anyway :)

    /ust/lib/liborxd.so was build by me and copied to /lib/.

    The good thing is, that at the end we will get proper linux64 support, hopefully.
  • edited February 2011
    It looks like glfw is compiled in 32bit:

    objdump -a libglfw.a
    In archive libglfw.a:

    enable.o: file format elf32-i386
    rw-r--r-- 1000/1000 13116 Jul 11 06:17 2010 enable.o
    [...]

    Aaaaghhrrrr!

    WHY?
  • edited February 2011
    I managed to build 64 glfw (with gcc -m64 -fPic)

    I'm getting segfault...

    I'm loosing my hope, maybe I should try to build with 32bit lib?
    Precompiled examples work well.
  • edited February 2011
    Ok, I made it work with -m32 ...
    I don't know if it is a failure or victory :|
  • edited February 2011
    Mmh, it's at least a partial victory!
    It means you can use orx right now, even in 32bit version, and we can try to figure out what's going wrong. Unfortunately I don't have access to a linux64 myself.
    I know that Eyecreate was able to have 64bit version of orx running on Linux and I thought Grey might have done the same. I'll ask them when I see them online.
    In the meantime, you can continue your exploration of orx without too much trouble. :)

    Btw, thanks for taking on your time and giving a shot for the 64bit compiling.
Sign In or Register to comment.