Blitzmax Ubuntu 12.04 problems
Archives Forums/Linux Discussion/Blitzmax Ubuntu 12.04 problems
| ||
| Hi, I try to install Blitzmax on Ubuntu 12.04 and when i run MaxIde and try to compile for exemple "firepaint" I have this report : Compiling:firepaint.bmx flat assembler version 1.68 (32768 kilobytes memory) 3 passes, 33922 bytes. Linking:firepaint.debug /usr/bin/ld: cannot find -lfreetype /usr/bin/ld: cannot find -lGL /usr/bin/ld: cannot find -lGLU /usr/bin/ld: cannot find -lX11 /usr/bin/ld: cannot find -lXxf86vm /usr/bin/ld: cannot find -lX11 /usr/bin/ld: cannot find -lXxf86vm /usr/bin/ld: cannot find -lGL /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.so when searching for -lstdc++ /usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.6/libstdc++.a when searching for -lstdc++ /usr/bin/ld: cannot find -lstdc++ collect2: ld returned 1 exit status Build Error: Failed to link /home/desktop/tel/b148/BlitzMax/samples/firepaint/firepaint.debug Process complete |
| ||
| 64-bit Linux problems :-) You will need the "dev" packages for those libraries installed. Then, it is also likely, because the 64-bit dev packages do not actually include the 32-bit library stubs for the shared objects, that you will need to create some sym-links yourself. But, start with the dev packages, and see how far you get with those. |
| ||
| This post might help you somewhat. Although I don't like the way the sym-links have been done there. (each to their own, of course) |
| ||
| Feel free to add "alternative" styles of symlinking - I appreciate learning new (and maybe better) ways. What (dis-)advantages has your method? Hmm I thought there was a sticky for blitzmax@64... if it is missing, one may consider making the post you linked a sticky one. bye Ron |
| ||
| @Brucey Thank you, i followed the post, i rebuild all modules and it reduce error report to this : Building firepaint Compiling:color.bmx flat assembler version 1.68 (32768 kilobytes memory) 4 passes, 26502 bytes. Compiling:firepaint.bmx flat assembler version 1.68 (32768 kilobytes memory) 3 passes, 33922 bytes. Linking:firepaint.debug /usr/bin/ld: cannot find -lfreetype /usr/bin/ld: cannot find -lGL /usr/bin/ld: cannot find -lGLU /usr/bin/ld: cannot find -lGL collect2: ld returned 1 exit status Build Error: Failed to link /home/desktop/tel/b148/BlitzMax/samples/firepaint/firepaint.debug Process complete |
| ||
| More missing libs :-). You can usually get far by searching for them with apt-cache. $ apt-cache search libfreetype $ apt-cache search libgl etc. Find the name of the library you need and install it. You also probably want the 32bit libraries installed, most of them can be acquired by installing ia32-libs. See http://blitzmax.com/Community/posts.php?topic=96246 and https://help.ubuntu.com/community/32bit_and_64bit as well. |
| ||
| You also probably want the 32bit libraries installed Except the main problem is the 32-bit developer stub libraries are usually not installed with the dev packages (which are processor independent) on a 64-bit system. Which is why you need to manually sym-link the 32-bit stuff. |
| ||
| And another thing is libfreetype, libGL and libGLU AFAIK have been updated since I posted that thread. So you would have to remove those create symbolic links then find the new versions of those libs and redo links pointing to the new library versions. Feel free to add "alternative" styles of symlinking - I appreciate learning new (and maybe better) ways. Well I only know of two ways, a soft link and a hard link. Each have there advantages/disadvantages. Unless Brucey's on about about the fact I just placed the links in /usr/lib32/ which for the time seemed like a logical place as it's in the Max's search path or that I directly linked to the library and not to is pseudo link. But in future versions of debian flavours, I suspect that directory will be phased out so bmk would have to be hacked to take the new setup into account. Just like the ia32-libs are being phased out in favour of the multi-arch build system.Last edited 2013 |
| ||
| @Htbaa I tryed to apply your method on libfreetype: apt-cache search libfreetype return this message : libfreetype6 - FreeType 2 font engine, shared library files libfreetype6-dev - FreeType 2 font engine, development files libgd-gd2-perl - Perl module wrapper for libgd - gd2 variant libcoin60 - high-level 3D graphics kit implementing the Open Inventor API libgd-gd2-noxpm-perl - Perl module wrapper for libgd - gd2 variant without XPM support i install all the library (for exemple with libfreetype6 i type sudo apt-get install libfreetype6 at the end i made a sudo apt-get update After i launched MaxIde, i recompiled all module, i try to compile firepaint but i have style the same error report. Can you tell me if i followed the right procedure ? I am a newbie in Linux and i could miss something. @Brucey How can i manually sym-link the 32-bit stuff ? Isn't it what i have already done ? |
| ||
| Just reinstalled 12.04 the only update is to libGLU. @golomp: First make sure that you have Hardware Accelerated drivers installed for a new user use the non free drivers that are in the Ubuntu repositories (search the ubuntu forum on how to check and do this). Don't try and install any driver from a hardware vender as you can really cause problems if you don't know what you are doing and don't know how to recover when things go wrong. Next make sure that the following three sudo commands have installed the necessary build environment (copy and paste each line): sudo apt-get install ia32-libs-multiarch g++-multilib build-essential sudo apt-get install libglu1-mesa-dev x11proto-core-dev x11proto-gl-dev x11proto-kb-dev libxxf86vm-dev sudo apt-get install libasound2-dev libfreetype6-dev libxpm-dev libxft-dev The first line installs all of the 32bit libraries (there is away to install only those libraries that BlitzMax needs, but can get messy for any one new to Linux), the compiler with 32/64bit support and additional tools that come in handy. The second and third lines installs the development files and their associated 64bit compiled library counter parts. If you have done the sym-links (symbolic-links) as in the other post, remove them by copying and pasting each line sudo rm /usr/lib32/libGL.so sudo rm /usr/lib32/libGLU.so sudo rm /usr/lib32/libX11.so sudo rm /usr/lib32/libfreetype.so sudo rm /usr/lib32/libXxf86vm.so sudo rm /usr/lib32/libXft.so sudo rm /usr/lib32/libXpm.so then redo them again (copy and paste as a mistake typing will leave a broken link which has to be removed) sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib32/libGL.so sudo ln -s /usr/lib/i386-linux-gnu/libGLU.so.1 /usr/lib32/libGLU.so sudo ln -s /usr/lib/i386-linux-gnu/libX11.so.6 /usr/lib32/libX11.so sudo ln -s /usr/lib/i386-linux-gnu/libfreetype.so.6 /usr/lib32/libfreetype.so sudo ln -s /usr/lib/i386-linux-gnu/libXxf86vm.so.1 /usr/lib32/libXxf86vm.so sudo ln -s /usr/lib/i386-linux-gnu/libXft.so.2 /usr/lib32/libXft.so sudo ln -s /usr/lib/i386-linux-gnu/libXpm.so.4 /usr/lib32/libXpm.so When it comes to getting sound installed. If you use the MaxIDE to create the cpp file; save the file first before pasting any code into it. Then close the file and reopen it.You will then be able to paste the cpp code into the new cpp file without the MaxIDE trying to format the code as Max Basic. It has to be done this way with any non BMX file as any new file created gets treated as a BMX file until it's been saved. Last edited 2013 |
| ||
| >Feel free to add "alternative" styles of symlinking - I appreciate learning new (and maybe better) ways. Well I only know of two ways, a soft link and a hard link. Hmm I think I already knew both methods. That is why I asked for the differing approach brucey might have in mind ... maybe you were right assuming a "what was linked"-thing. bye Ron |
| ||
| @dawlane Thank you, i think we are very close from final solution. First sudo serie did'nt install anything. But, sym-links rebuild made *a lot* of good things... I have quite no compilation error and... tiledrop run! Some sample programs dont run... I made some try : tiledrop : No error at compile. Program run !!! I can watch main display and quit by ESC. But compilation window in MaxIDE show this error: Building tiledrop Compiling:tiledrop.bmx flat assembler version 1.68 (32768 kilobytes memory) 4 passes, 52241 bytes. Linking:tiledrop.debug Executing:tiledrop.debug Xlib: extension "XFree86-VidModeExtension" missing on display ":2000.0". spintext : Compile ok. Error at run : Unhandled Exception:Unable to calculate tex size(error is at line 22 : DrawText t,0,0) tempest : Compile ok. Error at run : Unhandled Exception:Attempt to access field or method of Null object(error is at line 432:Cls) astar_demo : Compile ok but when i try to run it, i have an error at recompilation window : Building astar_demo Compiling:priority_queue.bmx flat assembler version 1.68 (32768 kilobytes memory) 4 passes, 15857 bytes. Compiling:astar_node.bmx flat assembler version 1.68 (32768 kilobytes memory) 3 passes, 9445 bytes. Compiling:Callback.bmx flat assembler version 1.68 (32768 kilobytes memory) 3 passes, 3778 bytes. Compiling:astar_graph_walker.bmx flat assembler version 1.68 (32768 kilobytes memory) 4 passes, 17363 bytes. Compiling:astar_demo.bmx flat assembler version 1.68 (32768 kilobytes memory) 4 passes, 66782 bytes. Linking:astar_demo.debug Executing:astar_demo.debug Xlib: extension "XFree86-VidModeExtension" missing on display ":2000.0". Xlib: extension "XFree86-VidModeExtension" missing on display ":2000.0". Xlib: extension "XFree86-VidModeExtension" missing on display ":2000.0". Process complete I have a question : Do i have to rebuild All modules for each program i try or Rebuild procedure is general for BlitzMax only needed when i update system ? (library) |
| ||
| no rebuild is not neccessary. the warning is coming from xlib ... so your video settings (system wide) are not that correct. I don't know how the open source drivers are working at the moment but I only had 2 times having troubles installing binary blobs from ati (beta drivers without removing the old ones...). Before installing the manufacturers drivers (they correct some things in your xorg.conf).... Try setting different graphics drivers (Max2D, OpenGL ...) - but I don't think that helps much. Ok... have a look if you are using an Xorg.conf (terminal: locate Xorg.conf) and edit it: Section "Screen" SubSection "Display" Modes "1280x1024" "1280x960" "1280x800" "1280x720" "1152x864" "1152x768" "1024x768" "800x600" "640x480" EndSubSection EndSection Maybe add other resolutions too. What also may help: gpu driver settings, have look if you disabled "scaling" (lower resolution than your screen - what to do with them?). bye Ron edit: Rebuild of modules is only necessary if the module was changed (or in more advanced cases - as soon as you trust the magical hands of brucey and his modules) Last edited 2013 |
| ||
@Derronlocate Xorg.conf Sorry Derron but this command line return nothing... I am going to take a look at "Tiledrop" sample because it run. So, even if i dont know why other program didn't run, i maybe have the possibility to understand why "Tiledrop" run... I really feel to be close from solution. |
| ||
| Your display number is :2000 ? How are you using your Linux? (vm, actual, headless (across a network)) ? |
| ||
| @Brucey I use NX Free on Windows XP to have a distant connection on my Ubuntu server accross my internet network. Last edited 2013 |
| ||
| Ah, NX Free doesn't support GL context rendering :-) (been there, tried that, etc.) Sure, it did at one point - I can't remember which version of the server side did - but then a later update broke it. In theory, you can force it to software render instead, but I've never managed to get that to work. I pushed the use of NX Client at my work, because on Windows it's the easiest way to work on our Linux servers (with GUI stuff, obviously - otherwise you just use Putty, etc). But since I removed Windows from my work PCs and installed Linux, I can ssh -Y onto the boxes and run kde/gnome headless over the network. This *does* support GL rendering. It even works through VPN across the WAN. And because OS X has X11, I can run my Linux boxes headless via that too. Not that it helps with your problems, of course… Last edited 2013 |
| ||
| What's particularity in Tiledrop's structure to be able to run ? |
| ||
| Well, everything after line 8 won't work :-) |
| ||
| But seriously, it will look exactly the same on Windows, so you aren't missing out too much with that particular example. You can't open a GL context on NX. (if you still don't believe me, try starting one of the GL-based 3D screen savers) |
| ||
| i did'nt have the same thing on Window it doesnt works the same. Last edited 2013 Last edited 2013 |
| ||
| Oh, it works? That's interesting. I wouldn't have thought so! Maybe they fixed something… As for the errors you see in the other applications, that's typical of having not graphics context. |
| ||
| On Windows it does not work exactly the same. I thought but not. Maybe... It's not easy to make things runing on so much linux version, include all graphic cards I am going to try some program with only text function usage. TCP transaction doesnt need graphics. :) Last edited 2013 |
| ||
| error Last edited 2013 |
| ||
| I'm confused, is it just full screen graphics modes that fail? What kind of graphics card and drivers are you using? Ubunutu typically adds an icon in the dekstop toolbar allowing you to easily install the correct proprietary driver, even if you don't have nvidia the following page has some pics regarding use of "Restricted Drivers". https://help.ubuntu.com/community/BinaryDriverHowto/Nvidia |
| ||
| @skidracer Hi, Don't be confused, my situation is quite fully solved. I still have an error but it's due to the way i access to my server. It's a distant server and i use NX Free. Due to this i still have an error but it's a non-blocking error and i think i cant solve it completely. So i think my situation is completely solved as much as it can be. Thanks for all people who help me and contribute to this solved situation: (by alphabetic order) - Brucey - Dawlane - Derron - Htbaa - Skidracer Thank you all to have taken on your time and give your knowledge for somebody you don't know in real life. (i am a good guy, i make software and 99% of them for free. Now i hope to make their Linux equivalent) Best regards Golomp |
| ||
| Ok, the amount of effort that has to be undertaken to simply get Bmax to compile (on Linux) is just silly. I have Inkscape (an excellent, highly recommended vector [svg] drawing program) installed on my Ubuntu 12.04 system and when I do a system update, Inkscape (as well as Firefox and many other installed programs) automatically get updated, too, with all of the required libraries, etc.. - Why can't BlitzMax do this, too? Seems to me this would solve a huge number of, ahem, embarrassing problems for Linux BlitzMax. How much work would be involved to make this a reality? The pipedream would be to have BlitzMax -AND- third party modules do this as well. Russell |
| ||
| you mean: sudo apt-get update -> and blitzmax updates to the latest version? Not possible as it is restricted software and even at the moment the only license check is done during access to "product updates" on the website. do you mean: first start of a new blitzmax (hmm the compiler or the ide?) version on a linux environment -> blitzmax updates/installs needed requirements Not possible as this could destroy working environments (eg. pulseaudio or not to pulseaudio, what about people using custom versions of some libs (compiled by themself) ...) ... so what did you mean? bye Ron |
| ||
| Why can't BlitzMax do this, too? As Derron say it's restricted software and like all restricted software it's down to the authors to maintain the binaries and install methods. Just be thankful that we can modify the modules to make things work when they break something in the OS, as that's exactly what happened to sound when Ubuntu 12.04 came around.Many people are still waiting for the 64bit version of Max which I can not see happening as it looks like Mark is spending his time with Monkey which can be made to work on Linux and compile OpenGL binaries for both 32bit and 64bit Linux/Windows OS with a bit of know how. |
| ||
| So let's just throw our hands up and shrug, "Oh, well, I guess we'll just have to live with it..." Oh, come now, smart people! I refuse to believe that there is not a better way to install/distribute/update BlitzMax for Linux than what we have currently (which leaves a lot to be desired). Can not the repository reside on Blitz's own server, ask for a password to verify ownership rights and continue unimpeded? Surely, BlitzMax is not the only commercial program available for Linux with this same issue... Think, McFly! Think! Russell |
| ||
| Setting it up on a 32-bit linux is very simple. You can just run the setup script (as per another thread) which gets all the required bits together. 64-bit linuxes is a bit harder - some have the required parts setup for 32-bit dev, but recent versions do not, and it requires some set up of symbolic links and whatnot. (well, I suppose it's on the premise that everyone with a 64-bit system will be developing 64-bit applications) |
| ||
| Yeah, I try to stay away from 64 bit distros. I've successfully compiled programs on Ubuntu before using the mentioned script, but on my latest install (Wubi - Ubuntu 12.04), when I run BMax nothing happens at all. The BlitzMax IDE doesn't even load (and no error message is given). Strange. Anyway, to my previous point, couldn't Mark just have the .deb or .rpm package on the Blitz website (which would require authentication of course) and make sure everything necessary is included? Third party modules could have their own packages as well. There has got to be a way to make this as smooth and (relatively) painless as Windows and Mac (I'm assuming). Russell |
| ||
| I try to stay away from 64 bit distros What you talkin bout, Willis? X64 operating systems are much faster than 32 bit Linux, as it uses all of your installed ram and takes full advantage of 64bit capable cpus. All you need to do to avoid problems with libraries on Ubuntu is add ":i386" to the end of the package you want to install. ie "apt-get install package" would be "apt-get install package:i386". |
| ||
| Ohh Captain the master of wisdom. I would like to see what happens if you install all dependencies with your ubercool ":i386" - and yes, answer all questions of apt with "yes" - happy faces all around when rebooting ;D. Why? If you intend to eg. compile wxwindows for use with wxmax ... you may need some libs. If you now just install them with :i386 it will automatically remove some other libs and even your desktop (so gnome, xfce4, ...). This happens on debian based distributions (ubuntu, mint,...) which you, captain, are using (think you mentioned that before). Instead of using :i386 you will have to use symlinks to 64bit dev-libs (like brucey stated). -- Why no ".deb" - deb files are kind of "setup.exe" - they install blitzmax "somewhere" on your system. BlitzMax is intended to be portable and does not require hidden .blitzmax-profile directories nor does it care about multiple user setups. So this behaviour (extract zip and run) may not be intendet, but it was used as feature. And yes, for some linux distributions this worked out of the box. Nower days need more actions to be done which cannot be achieved using an "extract zip"-approach. Ok, you could modify the setup-shell-script provided in the linux section of this board. You would have to adjust it for the top 10 of the most common linux distributions - each for 32 and 64bit. Now you have to explain users how to make that script executable (sudo chmod +x name.sh) as zip files wont be able to "chown" and "chmod" while extracting. Ahh and before I forget to mention it: the shell script should also take care whether other symlinks are set (eg you have special versions symlinked to get other applications working) in this case it should print out "alert alert system is going down for explosion now". I know the current problems with BM are producing enough worries but I do not see easy ways to make all users happy. The only way would be to support a special distribution and state "may run" for all others (that is how other companies do it - so they only have to test one or two current desktop distributions). bye Ron |
| ||
| Life in the modern world would be so much easier if someone at BRL took the time to finally create a 64-Bit build of BlitzMax... I'm pretty sure most people would even pay for that. |
| ||
| @Deron: You forgot to mention on top of all that; is that things get change in the Linux world every time there is a new release. So what may work in the last distribution may not work in the next without a rebuild or a lot of messing about. X64 operating systems are much faster than 32 bit Linux, as it uses all of your installed ram and takes full advantage of 64bit capable cpus. No they are not. A 32bit system running at 3.73GHz will just be as fast as a 64bit system running at 3.73GHz. And a 32bit CPU in PAE mode can access 64GB.The only advantage a 64bit system has is access to more memory. Meaning more applications can be open at the same time. Unless the OS and "!RUNNING APPLICATION!" is written to use that extra memory correctly; then you will see no difference in speed what so ever as they would still have to access the hard drive at some point for swap space. Computers are only as fast as the slowest piece of installed hardware and usually that is always hard drive. BRL took the time to finally create a 64-Bit build of BlitzMax... I'm pretty sure most people would even pay for that. I know I would. |
| ||
| Actually x86-64 has twice as many hardware registers and 64 bit integers are handled natively. Also, 32 bit code is crippled by thunking whenever it needs to communicate with the native 64 bit Windows APIs, I'm not so sure of the penalties on Linux. |
| ||
| Also, 32 bit code is crippled by thunking whenever it needs to communicate with the native 64 bit Windows APIs And I thought WOW64 was to meant be a thin translation layer that translated 32bit API calls to their 64bit equivalents.As for Linux for what I can gather as from Linux 3.4 there is the x32-ABI which allows 32bit applications to run in 64bit long mode while using 32-bit pointers and data fields. I think there was a performance hit before this was introduced, but if there was I never noticed it. |
   |