Unable to launch Bmax IDE 1.50
Archives Forums/Linux Discussion/Unable to launch Bmax IDE 1.50
| ||
| Hi, I can't get the IDE for 1.50 to run. Double-clicking on it does nothing as well as opening it. It is set as an executable application. I am using debian 7 64bit and Bmax 1.48 compiles and runs fine. Help a Linux newbie. :) Thanks, |
| ||
| You won't be able to use BlitzMax 1.50 on Debian as for some unfathomable reason 1.50 was built against a later version of Ubuntu (not 12.04) and as a result the versions of GLIBC are different. People tend to forget that for a program to be compatable. It has to be built against the long term support version. Currently for Ubuntu there are two LST versions. Ubuntu 12.04 and 14.04. Ubuntu 12.04 support ends in October 2017. |
| ||
| Nice hint @dawlane. Maybe there should be some stickies around so people do not use "other linuxes" than XYZ ... :-( PS: You know that 1.50 includes a bugfix concerning REM/ENDREM-blocks. So if you might not be able to compile your code - check REM/ENDREM blocks. If you really dare: mail Mark Sibly directly (see his blog-emailaddress) to build it again. I had to be that stubborn too to get 1.50 - so this might be a chance to involve him again. bye Ron |
| ||
| So, we need a version of the IDE built against what? Ubuntu 12.04? I'll try to get something done about it over the weekend... |
| ||
| You should really try my build of the default Maxide. It's MaxIDE143 (+ the ini) here: maxide_gtk2_bin. It uses Brucey's Gtk2, Webkit1 (and Scintilla) so you need to make sure you have installed libgtk2.0-dev and libwebkitgtk-dev. It was built on ubuntu but it may work on debian. |
| ||
| Think 64Bit system will have some trouble installing "libwebkitgtk-dev" the easy way. So you might try some statical linking ... UNZ had some trouble with indevIDE too (more specifically: I had trouble on linux because of the dependencies). bye Ron |
| ||
| Think 64Bit system will have some trouble installing "libwebkitgtk-dev" the easy way. Indeed, I couldn't get it to install on mine. Maybe what we need is a 64-bit build of the IDE... :-p |
| ||
| Hmm indeed... that is another option but this a) involves fltk 64bit or b) gtk 64 bit c) debugger differences? in both cases (a+b): some adjustments more than needed - adding misdirection to your brain :p. bye Ron |
| ||
| So, we need a version of the IDE built against what? Ubuntu 12.04? I wouldn't waste your time Brucey with the default Max download. I tried it when 1.50 first came out by using 1.48 to build the tools and modules. Unless you have access to the bcc source you will just be p*ssing against the wind.Some else asked why they couldn't get 1.50 to work on Debian. |
| ||
| I think Brucey had the other bcc in mind :p bye Ron |
| ||
| Hi, I am not going to be too much help here but I can contact Mark about it. If I were to install a version of Ubuntu (say on external HD) which version should I install? Thanks, |
| ||
| I don't think that it matters if you stick to using 1.48 as far as I can tell there wasn't any changes in 1.50 on the module side of things for Linux, or skids audio fixes for ALSA would have been in there. So just stick with 1.48 if you wish to distribute your applications. Companies such as Steam will reject Linux applications that aren't built against Debian 6/7 or a Ubuntu distribution that is based directly from the stable branch of Debian. Or to be more precise they have to be able to run on Debian. If you do want to use 1.50, then Ubuntu 13.04/13.10. If I were to install a version of Ubuntu (say on external HD) which version should I install? You don't need to install a complete distribution. You can do what's commonly known as a chroot (an abbreviation of change root). When the first 64bit distributions came along, there was no 32bit support within them at all. The only way you could get round it without completely messing up the installation was to use a chroot and a clever bit of scripting to run 32bit applications. Somewhere there is an out dated post by me that showed how to do this. Don't try it out as things have changed, and there is a real danger that you mess up the system beyond repair. There are tutorials by me over on the MonkeyX site. One of them shows how to set up a chroot that is currently valid. If you do use a chroot, then remember to rebuild all modules before compiling. |
| ||
| The only important non-mac-osx-change in 1.50 is the thing I blamed some weeks before release of 1.50: buggy rem/endrem-blocks. So 1.48 will do, as dawlane mentioned. PS: This bug only occoured to me when I used WinXP for compiling. So this should be not an issue for Linux users. bye Ron |
| ||
| Hi, V1.50 was built on Ubuntu 12.04 LTS (according to the help panel), although it may have been built on a different installation from 1.48 (not 100% sure, I've been using 12.04 in vmware for a while now). My 12.04 may be in need of some updates too (installing now). But regardless of how BlitzMax was built, it wont affect how it *builds*, will it? That will come down to what compilers, libs etc you've got installed. Anyway, V1.50 works here on both Ubuntu 12.04 and a shiny new install of Ubuntu 14.04 (very nice!), so I'm not sure what the problem is. I build/test on Ubuntu *only*, so that's definitely the recommended dev platform for using BlitzMax. Which isn't exactly the Linux way, but while I would love to be able to provide mega support for a bunch of distros, that's just not gonna happen. On the other hand, if it's simply a case of installing/fixing something and rebuilding the lot, let me know what to do. Re: audio, I strongly recommend using openal on Linux, ie: SetAudioDriver "OpenAL". I might make this the default for linux in the next release. This (apparently) means 'openal-soft' these days for most distros, which is much better than the old, laggy openal lib. I've been on the openal mailing list for a while now, and the openal-soft author clearly knows far more about linux audio than I ever will, and openal-soft *should* handle a wide range of different setups and distros. It's also possible to ship binaries with a prebuilt openal-soft binary, although I have no idea how necessary this really is. This involves using a 'launcher' script file that mungs LD_LIBRARY_PATH to include 'current dir' or similar, so you can just stick a prebuilt openal.so in the app's main dir. There's also the RPATH=$ORIGIN linker option (which would need to be hacked into bmk) although this effectively hardcodes the lib path into your app, meaning your app will *never* use 'system' openal. Which is possibly not the linux way(?) [edit] Ok, reading around a bit it appears the main problem people have with openal is it isn't included with all distros (but then, what is?), in which case your app can either somehow install (or prompt the user to install) openal, or use LD_LIBRARY_PATH or RPATH to force your app to use a prebuilt, internal version of openal.so. [/edit] |
| ||
| I build/test on Ubuntu *only*, so that's definitely the recommended dev platform for using BlitzMax. Thanks for that. Really, Ubuntu is going to be used by most gamers and is the most popular (average user) distribution of Linux. It also makes it easier to support my users knowing that I can recommend it as the supported Linux distro. @dawlane or Derron What do you think, go with Ubuntu 12.04 64bit or 14.04? Really I want to be able to set it up for 64bit and there are few threads on setting up Ubuntu this way but not for 14.04. @all Anyone here have Bmax 1.50 running on Ubuntu 12.04 (aside form Mark)? Thanks Mark. |
| ||
| The lowest common denominator seems to be ALSA. Knoppix (was famous years ago - but is still well known in Germany): only ALSA. Slackware (14.1): no PulseAudio but ALSA on board. (that user run into the negative Millisecs() problem too - people will get this more and more as soon as people do no longer shutdown their pcs -- happening on mobiles even more often). Ubuntu/Mint: both come with ALSA + PulseAudio. Ubuntu/Mint are #3 and #4 most used OS worldwide (when cumulating all Windows incarnations as one) - so I assume you reach most of the linux users with PulseAudio. But some of your customers/clients/users/friends then might run into trouble installing another lib. Same for me when it comes to openAL - which has to get manually installed on nearly all distros. This is a no-go for apps you do not compile on your own (open source). So this means: for now you need to use Alsa. And if done properly, you can also use PulseAudio (dynamical linking of libs) like done in FreeAudio. It just needs some fixes (app-end-channelPlaying-Boolean is wrong on Linux) and enhancements (streaming :D). OSS is nice to have, but hmm really outdated, JACK is not used by many users except audio enthusiasts (low latency engine). Benefit of PulseAudio: you can route audio streams over the network - so eg. route your apps sound to another unit in another room to playback that sound. Also you could more easily adjust the volume of your apps without interfering other apps (each one gets its own "volume knob"). @1.50 Dawlane said (post #2 in this thread) the problem is based on the changed glibc-version. The only error in my VM (Knoppix 7.2) was Linking digesteroids.debug sh: g++: Command not found Build Error: Failed to Link [...]/digesteroids.debug Had to install g++ by hand (and of course installing/linking the libs X11, Xxf86vm, GL, GLU and whatever is needed too). @marksibly_v2 Doesn't "password reset" work for you :D ? Or is this some kind of "restart" symbol (you could rename your nick in your account settings then) ? @Richard I replaced my last Ubuntu 12.04 with a mint last week (repaired the whole laptop after a Beer somehow flooded it :p). All linuxes I have now access too seem to use various "glibc 2.17"-releases (just run the .so file to see the version). I am downloading an ubuntu-12.04-iso now, will check it in a VM later that day. bye Ron |
| ||
| @Derron Right on I await your results. :) I noticed you VM'ing it. How well does a VM work as far as video performance. That is really why I have a dual boot setup as I like to be able to fully test my application, running with speedy video performance. @marksibly_v2 Doesn't "password reset" work for you :D ? Or is this some kind of "restart" symbol (you could rename your nick in your account settings then) ? I noticed that too :D Me thinks it is the latter. :) |
| ||
| > The lowest common denominator seems to be ALSA. OpenAL-soft is a wrapper around whatever it's built to support (oss, alsa, etc) much like freeaudio in fact. In theory, if it's part of your distro, then it should be prebuilt/configured to 'just work'. > Dawlane said (post #2 in this thread) the problem is based on the changed glibc-version. He also said v1.50 was not built with 12.04 LTS, but this is not true so I'm not sure what's going on. Perhaps I inadvertently upgraded my glibc? Is this possible? Undoable? What if other users have done it too? > sh: g++: Command not found Actually, the mxdevinstall util that someone developed for monkey does a good job of installing all bmx dependancies too. |
| ||
| @glibc If you have a "higher version" you wont be in trouble (like stated: mine ara 2.17) but of course this could change somewhen in the future (backwards compatibility breaking changes). In your installation (you use for compilation) just call the lib directly. Eg.: ronny@RonnyPC ~ $ /lib/i386-linux-gnu/libc.so.6 GNU C Library (Ubuntu EGLIBC 2.17-93ubuntu4) stable release version 2.17, by Roland McGrath et al. Copyright (C) 2012 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Compiled by GNU CC version 4.7.3. Compiled on a Linux 3.11.3 system on 2013-10-12. Available extensions: crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B libc ABIs: UNIQUE IFUNC For bug reporting instructions, please see: <https://bugs.launchpad.net/ubuntu/+source/eglibc/+bugs>. @g++ command For me dawlanes script does what it should (and I can adjust the sources to my needs ... an advantage in my opinion). I just wondered why "g++" is needed for linking together prebuild data (I thought that is what the .i .a files in the .bmx-directories are for). Thought g++/gcc are just needed for compiling custom c-code. bye Ron |
| ||
| I just wondered why "g++" is needed for linking together prebuild data Rather than ld ? Because linking with g++ ensures the (possibly) required c++ static libs are compiled into your application too. With ld, you need to do all the "donkey" work yourself. It's pretty much standard to use g++ when linking something that may have elements of C++ in it somewhere. |
| ||
| On Ubuntu 12.04 32Bit (vanilla install from the iso, no updates done) the glibc version is "2.15", MaxIDE starts fine there. 12.04 was released in April, 2012, means 2 years ago. Edit: too see what version your binary is linked too: ldd -r -v binaryname So eg. MaxIDE for 1.42 was linked against max version "glibc 2.4" while the current one references "glibc 2.15" in some lines. Also of interest: the older MaxIDE references "libGLU" which is not needed for the newer ones. @LD / g++ Hmm, so "g++" is another requirement for BlitzMax on Linux (it is _not_ installed on all distros by default). bye Ron |
| ||
| He also said v1.50 was not built with 12.04 LTS, but this is not true so I'm not sure what's going on. Perhaps I inadvertently upgraded my glibc? Is this possible? Undoable? What if other users have done it too? I apologise for that statement. As it turns out the problem is that the tools and the IDE are built with 12.04 LTS. bcc is unaffected and will work quite happily on Debian 7 32bit as I have tested this on real hardware. Using a VM can throw of the results a bit with having to install Guest Additions to get things working.The GLIBC versions are different in the Debian stable branch, which is still using EGLIBC 2.13-38+deb7u1, while Ubuntu 12.04 is using EGLIBC 2.15-0ubuntu10.5 (current as the initial 12.04.2 iso image release uses EGLIBC 2.15-0ubuntu10.3 as there was a minor update). There is an up to date version of EGLIBC in the Debian testing branch (I think that's currently 2.17). There are quite a few topics about applications breaking as a result of this EGLIBC issue with Debian. Which is a bit ironic as the minimum requirement for the Steam client is Ubuntu 12.04 and yet they rejected an application because of this GLIBC issue and recommended that the author rebuilt it with Debian Wheezy or Ubuntu lucid 10.04 or another old enough distro. As bcc from 1.50 will function on Debian 7 32bit with out a hitch, it is possible to use BlitzMax 1.48 to rebuild the tools for 1.50 and then copy over the new tools to the 1.50 bin directory. You can then rebuild the 1.50 modules and if you wish, rebuild the tools again with the 1.50 modules. The last time I attempted to do this was with Debian 64bit in VM and something wouldn't work correctly. I will see if I can get 1.50 will work correctly on a 64bit version of Debian later. Re: audio, I strongly recommend using openal on Linux, ie: SetAudioDriver "OpenAL". I might make this the default for linux in the next release. OpenAL has been know to have issues with Pulse Audio on some distributions with certain sound devices. The end user has to then force OpenAl to use ALSA (echo "drivers = alsa" > ~/.alsoftrc). And as stated earlier, OpenAl is not installed on many systems by default. Likewise, pulseaudio is not installed as default on many distributions and many users will refuse to install either just to get one piece of software to work. There is a topic about audio problems and possible solution here.I think myself that the Max Audio module should check to see if a preferred sound server is available and running and then dynamically load it's libraries for use and always fall back to using the ALSA drivers if all else fails as the kernel (from 2.5 I think) has support for ALSA drivers as standard. OSS has been depreciated on Linux for some time now. Hmm, so "g++" is another requirement for BlitzMax on Linux (it is _not_ installed on all distros by default). The c compiler is not always guaranteed to be installed as default either. If I remember 14 years ago I had to manually install it on Redhat. |
| ||
| Regarding issues with glibc - would it be a good thing to have that files located within the BlitzMax-directory ("on demand", so if they do not exist, the system ones get used?). Think other apps (our custom ones) will have the same problems on a debian system then. @audio As soon as the "Max Audio module" only tries to load files (so no "inbuilt dependency") this is the best way to go imho. What engines are supported is then just a matter of the "Max audio module" - and having a look at FreeAudio it shows that plugging in "newer engines" is possible and so the module does not have a "dead end". @PulseAudio I do not want to start a flame so excuse me in advance :D. I think PulseAudio is the "current state of the art" engine for Linux distros. Most of the Linux users will have it installed. But: yes, as Alsa is the LCD of all engines (highest coverage) this is the one we should have working 100%. Other things are "sugar". bye Ron |
| ||
| Hmm, so "g++" is another requirement for BlitzMax on Linux (it is _not_ installed on all distros by default). If you are going to be developing on Linux, I'd expect you to have all the tools installed, whether they are there already or you add them yourself. |
| ||
| If I want to develop in language "X" I would not expect to have tools for language "Y" installed too. I hoped the "package" is selfcontained as much as possible. Also it was more a note to the "dependency installer" (script or binary) which helps to get a "useable state" to develope with BlitzMax on Linux. bye Ron |
| ||
| Regarding issues with glibc - would it be a good thing to have that files located within the BlitzMax-directory ("on demand", so if they do not exist, the system ones get used?). Think other apps (our custom ones) will have the same problems on a debian system then. If only it was that simple. But unfortunately it's not that easy, as GLIBC is a core library that requires other core libraries. It becomes a vicious circle as you then find out that in the end you start to have to include other libraries that you wouldn't even have guested would need to be linked against. I know I had a go at doing this. Even using the version from the test branch can cause problems. If you want to try then there are a couple of commands below. Note: I haven't test these yet. And the documentation about this is obsolete or outdated. sudo apt-get install libc6-dev=2.17-7or sudo apt-get -t testing install libc6-dev EDIT: 2.17 is no longer test according to Debian Package tracker |
| ||
| Hi, I was wondering if this approach might work out for debian. http://stackoverflow.com/questions/10863613/how-to-upgrade-glibc-from-version-2-13-to-2-15-on-debian I tried installing Ubuntu 14.04 64bit but it crashes after it gets to the desktop (looks like a video error). I will give 12.04 a try. I would love to keep debian (7.5 AMD 64bit) as I have it supporting my video card (not an easy thing to do). EDIT - Tried above no go. |
| ||
| Looks like the Debian team have been doing a bit of messing around or, it could have been that I tested the install script using VM that things are a little different. Just installed Debian 7.4 64bit (updated) on real hardware and libGL.so.1:i386 is no longer in it's default location and there is no soft-link in the path either. So BlitzMax 1.48 didn't work out of the box after I installed the dependencies. The libraries needed for linking are located at /usr/lib/mesa-diverted/i386-linux-gnu. To make the link use su -c 'ln -s /usr/lib/mesa-diverted/i386-linux-gnu/libGL.so.1 /usr/lib/i386-linux-gnu/' I will have to update the install script for this. But the good news is that bcc will run successfully on Debian 7 64bit and the binaries can be rebuilt using 1.48. How to do it. Shoudn't take more that 20 minutes maximum after the dependencies are installed 1) Make sure that the dependencies are installed and that the system links for a 64bit install are correct and not broken. 2) Make sure you have a patched BlitzMax 1.48 and rebuilt the modules and a patched BlitzMax 1.50 ready 3) Download the MaxIDE v1.40 source and unpack it into a directory. . 4) Use the 1.48 version to build bmk, makedocs and docmods in the 1.50 version sources directory. Remember to change the build settings from debug and GUI application. 5) Make a directory in the 1.50 versions bin directory and move the programs bmk, makedocs and docmods in the bin directory to the new one you just created. 6) Now move the newly built versions of these files from the 1.50 versions source directories into the bin directory of BlitzMax 1.50. 7) Open a terminal and change directory (cd) into the 1.50 bin directory and use the command line to rebuild the modules. bmk makemods -a 8) Now you can build a new IDE with bmk makeapp /location-to-the-ide-source/maxide.bmx 9) Rename the 1.50 IDE, then copy/move the newly created IDE into the BlitzMax 1.50 directory. 10) You can rebuild bmk, makedocs and docmods if you wish. OR Copy over bmk, makedocs and docmods and the IDE from 1.48 to 1.50 and save some messing around. @Derron: You could have used objdump -p to get a less cluttered output from a binary. |
| ||
| Think there is no "normal user" knowing all console commands Linux/Unix provide. BTW: objdump -p binaryname | grep "GLIBC_" bye Ron |
| ||
| I will give your method a try. I am downloading the latest debian ISO for a fresh test bed install. BTW, I was able to add the 'testing' branch of the debian repository and and update the package list. Using " sudo apt-get -t testing install libc6-dev " looks like it will work, but the synaptic package manager shows the 'testing' repository as only listing lib6c 2.19.3 being available. Is that what would get installed? |
| ||
| 2.19-3 is now the version in the testing branch and would be the one installed. If you ever need to get the steam client working then you have no other choice but to use it. |
   |