NewsForumsCodeLogsGallerySpecsSearch

Debian GLIBC 2.15 wont even start MaxIDE

Archives Forums/Linux Discussion/Debian GLIBC 2.15 wont even start MaxIDE

Chapman7(Posted 2014) [#1]
Running Debian, went through and added I believe, all the dependencies I need. Go to run MaxIDE and it never comes up.

In terminal I get this:

./MaxIDE: /lib/i386-linux-gnu/i686/cmov/libc.so.6: version `GLIBC_2.15' not found (required by ./MaxIDE)


Any ideas? Debian has a package called libc6 that has the file i386-linux-gnu/i686/cmov/libc.so.6 but the version (on the latest debian - fresh install - latest updates) is 2.13-38 =/


dawlane(Posted 2014) [#2]
I take it this is Debian 7.4 stable 32bit?

Edit: Here's your answer
http://stackoverflow.com/questions/10863613/how-to-upgrade-glibc-from-version-2-13-to-2-15-on-debian

Edit: BlitzMax 1.48 will still work as it looks like BlitzMax binaries for 1.50 were built with a later version of Ubuntu.


Yasha(Posted 2014) [#3]
There is an alternative as well (which is attractive when the main option is to risk destabilising Debian) - you can actually create a local installation of libc and use it to run a specific program instead of the system libc.

Method:
-- download a more up-to-date libc from Jessie (i.e. here) - make sure to get the right architecture
-- copy its lib folder to a convenient local position, e.g. ~/libc-2.18
-- run `~/libc-2.18/ld-2.18.20 --library-path ~/libc-2.18 ./MyProgram`

In other words, use the downloaded `ld` to start the program, and direct it to look at the rest of the downloaded libc folder for its supporting libraries in preference to the main system.

Of course this will presumably not in any way fix the programs produced by the BlitzMax compiler and they'll all demand to use version 2.18 as well... but it might work for short-term hacking. It worked for me in getting Leadwerks running, anyway.


dawlane(Posted 2014) [#4]
Of course this will presumably not in any way fix the programs produced by the BlitzMax compiler and they'll all demand to use version 2.18 as well... but it might work for short-term hacking. It worked for me in getting Leadwerks running, anyway.
You can go the chroot way to build against an older version, but you have to be careful for what you are doing when binding the file system. If you decide to remove a chroot without unmouting the directories that have be bound, you can kiss goodbye to whatever they connected to. What ever you do. Do not try to install any drivers into a chroot. You will be asking for trouble. There is an old script I did when Linux started to go 64bit, and with no way to run 32bit applications. You can find it here. The new way now is to use schroot.
You see loads of tutorials on how to set a chroot up and 99% of them don't tell you the full story or are out dated. The default action for schroot is to try and recover a chroot session in the event of a crash (it doe this after a major update of the chroot files). This should be disabled in /etc/defaults/schroot.


Chapman7(Posted 2014) [#5]
I used to like repositories but boy does this shed a different light on it. I had to switch from Mint to Debian because certain packages weren't on Mint's repository (and I don't know how to install packages without it yet). 1.48 worked, thanks a lot man! :)


dawlane(Posted 2014) [#6]
I had to switch from Mint to Debian because certain packages weren't on Mint's repository
Did you try adding the repositories?


Chapman7(Posted 2014) [#7]
Na, I didn't know how to do all that. Question - would GTKMaxGUI work on Windows and Mac OS X also?


dawlane(Posted 2014) [#8]
Na, I didn't know how to do all that.
A Linux virgin eh ;-)
On Debian family systems, server repositories are usually stored in /etc/apt/sources.list, make a back up of this file before you mess around.
On Mint you can add repositories via synaptic. All you do in the dialogue box is enter the url, the code name of the distribution you are using and which components main restricted univers multiverse.

If you edit sources.list directly the format is.
deb <url> <codename> <components>
A hash(#) is a comment marker. If you have a problem with using the package manager in debian, then edit sources.list directly.

Question - would GTKMaxGUI work on Windows and Mac OS X also?
Yes as long as you have GTK+ for Windows or OS X installed. You will have to distribute the dynamic link libraries along with your application. Do not statically link to these libraries, unless you are releasing under the LGPG license, as I don't think you would like it having to distribute the application object file when someone asks for it.


Chapman7(Posted 2014) [#9]

Do not statically link to these libraries, unless you are releasing under the LGPG license, as I don't think you would like it having to distribute the application object file when someone asks for it.



What do you mean when you say application object file?

Edit: And why wasn't GTK used for MaxGUI instead of FLTK, Cocoa, and whatever the windows one is called?


dawlane(Posted 2014) [#10]
What do you mean when you say application object file?
An application object file is the intermediate stage before linking any libraries. External functions have not been resolved by the linker ld and you see these files with the file extension .o. When you see libraries with the .a extension, you are linking to a compressed archive that contains an object file, except these will export function declarations. Plus if these use other external libraries, then these also need to be resolved.

And why wasn't GTK used for MaxGUI instead of FLTK, Cocoa, and whatever the windows one is called?
The Windows GUI tool kit is part of the Windows API (WinAPI), so it is part of the operating system. GTK/wxWidget etc, uses parts of the WinAPI, and is meant to be cross platform, which adds additional over-head, unless they communicate directly to the Graphic Device Interface. Originally GTK, aka GIMP Tool Kit, was a GUI widget set for GNU Image Manipulation Program, aka GIMP, and was Linux only. I guess at the time BlitzMax was released, it made more sense to gear it towards what ever the native GUI implementation was, plus it cuts out any possible license issues, and the need to distribute any additional libraries.

As previously mentioned, GTK,Qt fltk and others are GUI tool kits built on top of the the native operating systems own implementation. On Linux, this is the X server. The X server would be the equivalent of the Graphics Device Interface in Windows; it can also communicate over a network. BRL could have written the Linux GUI part to access the raw drawing power of the X server, but it would have been a big burden and in this day and age, every one just uses a GUI tool kit as is simplifies development.

As to why GTK wasn't used for Linux, I would say that this is more than likely is down to licensing issues, and the fact that GTK isn't guaranteed to be installed on the end users system. Though fltk is released under the LGPL v2 license, it does have a exceptions that allow you to statically link the library to your application without having to release any object files or source code. This makes it ideal for deploying GUI application across Linux platforms without having to worry about whether the end user has the necessary libraries installed.


Brucey(Posted 2014) [#11]
And why wasn't GTK used for MaxGUI instead of FLTK, Cocoa, and whatever the windows one is called?

wxWidgets, for example, uses the GTK on Linux, Cocoa on OS X, and the Windows API on Windows. So, it's fairly normal for a GUI toolkit to use whatever is available on the local platform.