noob, linux, building from source doesn't work

edited February 2012 in Help request
Hi guys,

I'm working on building up a pipeline for a win/linux project. I was able to build orx from source for windows, but I get errors under Linux.

I know they are not directly related to orx, but I also don't have any experience with gcc nor codelite. I do have gcc and g++ installed

I'm running linux mint (as I post this) under vmware. installed Codelite rev 5378.
I select Linux Embedded Dynamic.

and this is the result I get.

Build Started
/bin/sh -c '"make" -j 1 -f "orx_wsp.mk"none'
make: Warning: File `orx_wsp.mk' has modification time 0.1 s in the future
Building project:[ orxLIB - Linux Embedded Dynamic Debug ]
make[1]: Entering directory `/mnt/hgfs/Data/Killerkorp/Programming/orx/code/build/codelite/orxLIB'
gcc -c "/mnt/hgfs/Data/Killerkorp/Programming/orx/code/src/anim/orxAnim.c" -Wmissing-braces -Wparentheses -Wsign-compare -Wswitch -Wunused-variable -g -Wno-write-strings -fPIC -m32 -D__orxDEBUG__ -D__orxEMBEDDED__ -DAL_LIBTYPE_STATIC -o Linux_Embedded_Dynamic_Debug/anim_orxAnim.o -I. -I../../../include -I../../../../extern/dlmalloc -I../../../../extern/glfw-2.7/include -I../../../../extern/SDL-1.2.14/include -I../../../../extern/Box2D_2.1.3/include -I../../../../extern/SOIL/include -I../../../../extern/OpenAL-soft/include -I../../../../extern/libsndfile-1.0.22/include -I../../../../extern/stb_vorbis
In file included from /usr/include/math.h:28:0,
from ../../../include/math/orxMath.h:51,
from ../../../include/math/orxVector.h:50,
from ../../../include/core/orxSystem.h:47,
from ../../../include/core/orxClock.h:47,
from ../../../include/object/orxStructure.h:49,
from ../../../include/anim/orxAnim.h:53,
from /mnt/hgfs/Data/Killerkorp/Programming/orx/code/src/anim/orxAnim.c:33:
/usr/include/features.h:323:26: fatal error: bits/predefs.h: No such file or directory
compilation terminated.
make[1]: *** [Linux_Embedded_Dynamic_Debug/anim_orxAnim.o] Error 1
make[1]: Leaving directory `/mnt/hgfs/Data/Killerkorp/Programming/orx/code/build/codelite/orxLIB'
make: *** [All] Error 2
Build Ended
1 errors, 0 warnings


how is, what I'm assuming is a standard file, bits/predefs.h missing?

On another note... how does orx behave with non standard keyboards? anybody know? I type in Dvorak, and often times keyboard inputs in videogames don't support different layouts very well.

any help would be super appreciated,
Thank you

Comments

  • edited February 2012
    What architecture is the linux distribution, 32 or 64 bit? By the looks of it, you are trying to build a 32-bit orx on a 64bit linux. If you use the latest version of orx from git, there should be a 'Linux64 Embedded Dynamic Debug' for codelite, if that is indeed the issue.
  • edited February 2012
    Hi and welcome here, Katarak.

    By from git, I think 4babce meant from svn. ;)
    I'm pretty he's right about the architecture problem.
    By the way, if you ever want to build the 32b version, you should be able to do so by installing the libc6-dev-i386 package.
  • edited February 2012
    OK nice so not that big of a problem ;)
    I am running a 64bit linux, so that sounds like a valid analysis.

    I'll take a look at it and get back to you

    Thank you for the help.
  • edited February 2012
    close, but no cigar.

    now I get an error when building GLFW.. saying it can't find <GL/gl.h>

    Build Started
    /bin/sh -c '"make" -j 1 -f "orx_wsp.mk"none'
    Building project:[ orxLIB - Linux64 Embedded Dynamic Debug ]
    make[1]: Entering directory `/mnt/hgfs/Data/Killerkorp/Programming/orx/code/build/codelite/orxLIB'
    g++ -c "/mnt/hgfs/Data/Killerkorp/Programming/orx/code/src/plugin/orxPlugin_EmbeddedList.cpp" -Wmissing-braces -Wparentheses -Wsign-compare -Wswitch -Wunused-variable -g -Wno-write-strings -fPIC -m64 -D__orxDEBUG__ -D__orxEMBEDDED__ -DAL_LIBTYPE_STATIC -o Linux64_Embedded_Dynamic_Debug/plugin_orxPlugin_EmbeddedList.o -I. -I../../../include -I../../../../extern/dlmalloc -I../../../../extern/glfw-2.7/include -I../../../../extern/SDL-1.2.14/include -I../../../../extern/Box2D_2.1.3/include -I../../../../extern/SOIL/include -I../../../../extern/OpenAL-soft/include -I../../../../extern/libsndfile-1.0.22/include -I../../../../extern/stb_vorbis
    In file included from ../../../include/../plugins/Display/GLFW/orxDisplay.c:43:0,
    from /mnt/hgfs/Data/Killerkorp/Programming/orx/code/src/plugin/orxPlugin_EmbeddedList.cpp:86:
    ../../../../extern/glfw-2.7/include/GL/glfw.h:173:23: fatal error: GL/glu.h: No such file or directory

    So I went to look up what that was all about... turns out my ./usr/include/GL folder was empty. Looking online I saw I need to install some dev tools to get that up an running.

    I installed mesa-common-dev, and now there is a gl.h in ./usr/include/GL
    but it still won't compile. I added ./usl/include in the include paths of the project (just in case) but that didn't work. Restarting the OS (in case it had to get new PATHs) also didn work.

    I feel like an idiot about this stuff.

    when this is done a tutorial is going up.. even if it's a simple thing.
  • edited February 2012
    You should be able to obtain a package called 'mesa' which should have everything you need (and it would include mesa-common-dev, along with several other packages that you are missing.)
    And make sure you have libopenal-dev as well, as you will need that for sound.
  • edited February 2012
    Also, just in case, don't sync to yesterday's revision as I added a display optimization (using a VBO for indices) but I could only compile/test on windows/mac/iOS last night.

    I'll test on linux64 tonight and fix any problems that could have been added yesterday. The latest version prior to yesterday should be just fine though.
  • edited February 2012
    My version is 2 weeks old about. I don't grab from svn all the time, figuring it's not particularly necessary. There's much more activity that I thought there would be though.

    I installed libgl-mesa-dev, and libglu-mesa-dev, libglapi-mesa. which in turn installed a whole bunch of other things..

    I also installed libopenal-dev
    and libsndfile

    now I build! Debug, Profile and Release.

    Thanks for your help...

    I'll take the time to write a tutorial in the next few days or so...
  • edited February 2012
    Regularly syncing the svn isn't really useful unless it's for a feature/bug fix you're expecting of course.
    Requested features/fixes accounts for ~90% of the commits over the last year, I'd say. =)

    I'm glad you got it to work. That's weird that none of this dev environment was installed on your mint. I'm also running a mint (v11) in a box (via VirtualBox) for Linux64 work and I didn't have to manually install any of those packets. Ah, well!

    Looking forward to seeing your tutorial! Hope your next steps are going to be smoother now. :)
  • edited February 2012
    So I managed to build orx, and then worked it into my project.

    I'm working through Grey's tutorials, I'm at number 2.

    it compiles, and "debugs" through code lite, but nothing happens.
    The same files built in windows provide a purple screen.

    running it directly in linux, nothing happens either... No log is created either.

    Is there somewhere else I should look for a log of what's going on? I made sure I copied my ini files, and the .so file into my output folder.

    Thank you.
  • edited February 2012
    I've never used Grey's tutorials myself so, give me a second!
    *Quickly read Grey's tutorial #2*

    Ok, so the purple screen is what you want. It's just a viewport with a background color, ok.

    On linux, is there a black window that pops up? If you don't get any log, that's pretty weird. There should be a log in your exe folder with the name of your exe and the .log extension + one with a -debug.log extension if you run in debug.

    The debug log will appear almost instantly when you run in debug as orx is pretty verbose about what it's doing, whereas the release log is likely not to appear unless you logs things yourself with orxLOG().

    Do you mind sending me your linux project so that I can check it on my linux box?

    My email address is iarwain -at- <this-site>.
  • edited February 2012
    I get nothing. no pop up window, no log, no nothing.

    I'm thinking it might be because I didn't install de redistribuable libs? like I only installed mesa-dev, not just mesa?

    that's my idea so far, but my fiancée took the laptop for a business trip. so I'll only be able to verify that on thursday or so.

    if that doesn't work, I'll send over my code for you to have a look at.

    I'm getting all this pipeline stuff out of the way so when I start doing real development, I won't have to go back to it...

    when you mentioned the 64bit thing last time made me think I should also do those builds... so I'd have win32/64 and linux 32/64
  • edited February 2012
    So I checked my libs... and I think everything is there. Nothing still.

    So I thought maybe it was my graphic drivers or whatever. I installed Desura and TripleA which works. I also tried another game, which uses the ioquake2 engine. And like orx, It didn't run.

    So I'm not sure if it has anything to do with my drivers or something like that. I tried to install nvidia drivers, but I don't know.. is it possible that you can't do that through virtualization?

    I PM you with a link where you could dl my code and project.

    Thanks,
  • edited February 2012
    Hi Katarak!

    I replied to your PM a couple of days ago and I'm about to try your archive here on my linux box.

    As for virtualization, it shouldn't really matter, worst case scenario it'll just be very laggy and not 3D accelerated if your hardware/OS combination doesn't support it. That's what happened to me with my previous winXP/ubuntu 32 combination but everything is fast and accelerated with my new win7/mint64 one.

    I'll let you know if I find anything obvious.
  • edited February 2012
    Hi again!

    It turns out it's a very simple issue and easy to fix. :)

    Linux doesn't behave like windows and will not look in the exe folder to find dynamic libraries by default.
    So you could install liborx*.so somewhere in your standard library path (something like /usr/local/lib).
    This is, I believe, the preferred way of linux people but will require you to write an installer for redistributing your game as it's unlikely that orx will not come bundled with linux distributions. ;)

    The other options is to tell where to find the library.
    To do that you can either modify the LD_LIBRARY_PATH environment variable (not very handy) or simply provide the path at link time.

    The parameter to use is:
    -Wl,-rpath ./
    

    If you set that up in the Linker->Options of your codelite project and rebuild, everything should be fine after that. :)
  • edited March 2012
    ok, me again,

    I've gotten much further. I have been able to build orx and my project, but now I was trying to build it in linux 32bit. I followed iarwain's indication to install libc6-dev-i386. Which I did and that worked, however it still doesn't build. I get that it's not able to link the several libraries.
    libSOIL, libglfw, libBox2D. I attempted to install another libglfw but that also didn't work.

    I'm getting: Unable to link incompatible extern/glfw-2.7/lib/linux/libglfw.a

    same error for all the other libs.
    I understand the issue is that I'm attempting to build linux Embebbed Dynamic Debug (which is 32bit) on my 64bit linux VM, but I'm not sure if I need to add a switch to the build or whatever to get it to work.

    Thanks
  • edited March 2012
    Mmh, 32b/64b should be an issue with the svn version as the -m32 flag has been used to compile the 32b binaries.

    However it might be a compatibility issue between the compiler that was used by us to create the binaries and the one you're currently using as it happens often between versions of gcc.

    You'll have to rebuilt the dependencies yourself before building orx. You have codelite projects for all of them. Here's the list of the dependencies you need for the linux version:

    - Box2D_2.1.3
    - glfw-2.7
    - SOIL

    You can (and should) use the libsndfile and OpenAL that comes with your distribution as we haven't modified those for orx.

    When those are rebuilt, you should be able to rebuilt orx without any trouble.

    Let me know if that worked!
  • edited March 2012
    That didn't work unfortunately.

    I was able to build Box2D and Soil without problems, however they are still incompatible. GLFW doesn't have a codelite project.

    I looked online and they pretty much state that it has to do with using a 32bit lib on a 64bit build or vice versa.

    Like I said I did rebuild them, and confirmed they all had -m32 tagged (for box and soil) but I'm still getting the error.

    it exists in Debug, Profile, and Release.

    any other ideas? or should I install a 32bit linux to do that.

    am I the only one who is trying to do a multiple platform build of his orx project? how have other people fared?

    Btw, I also attempted to get windows 64bit build going for my project, and despite them saying you can une vsc++ Express if you install the latest platform sdk, I was unable to get that going.
  • edited March 2012
    Mmh, I'm not sure what's going on. And yes, there's a cmake project for GLFW, not a codelite one.

    I haven't compiled the 32b on my linux 64b for quite a while but last time I tried it was working fine. I'll try it again this week. I know some other people reported that they could build/run the 32b on 64b linux as well so I'm not sure what's going on.

    Which compiler/version are you using? Do you have the full logs of what you get when cleaning/building orx?

    As for win64, I haven't tried myself to be honest.
  • edited March 2012
    I had the opportunity to check this issue tonight on my linux64 box.

    Somehow there were missing -m32 flags for the linker. This is now fixed on the svn, sorry about that.

    However you will only be able to build a linux32 version if you have the 32b (i386) dev library for X11, GL, OpenAL, libsndfile, stdlib, etc...

    The version of glfw, SOIL and Box2D that are currently in orx's svn were fine here with my gcc 4.5.2 so I didn't update them.
  • edited April 2012
    i'm too used to this windows thing... where working with the compiler and linker is more of a joint affair. Thanks for the fix.

    As you say, I do need to get the 32bit versions of a bunch of libraries, and that's the problem. This isn't a orx problem though... really just how linux works.

    With Fedora it seems easy to have both 32bit and 64bit versions of the same library. The same seems to be difficult on Debian based systems. I attempted to install both libopenal and libsndfile in 32bit versions, but it had the result of removing the 64bit version.

    After more scouring the net, I found this info for ubuntu (which my mint install is based on)
    https://wiki.ubuntu.com/MultiarchSpec
    as is noted having both dev packages for development is not supported as of now (unless wiki is out of date).

    So I've decided to install a 32 bit version of linux along side the 64bit... I'm assuming people normally virtualise a 32bit version of linux within their main 64bit install. I'm mostly running windows.. so I have 2 virtual apps.

    I see the light at the end of the tunnel... let's hope it's not a train.
  • edited April 2012
    Sorry you had to go through all those issues, but yes, I'd recommend having two linux boxes too, a 32b one and a 64b one.
    That's actually what I use myself, a Mint64 and a Ubuntu32 both run under VirtualBox.

    Good luck with that light, but I hope it's a sunny day and nothing else. ;)
Sign In or Register to comment.