AGS Ubuntu Linux 2.72 Binaries Released!

Started by EvilTypeGuy, Wed 24/01/2007 05:06:03

Previous topic - Next topic

EvilTypeGuy

Moderators, please sticky this topic, unsticky all existing 'AGS Linux' topics if possible.

The AGS 2.72 Final runtime has been posted the Linux AGS website here:

http://drevil.warpcore.org/ags/

A reminder that the Linux version does NOT support plugins or movie playback (except FLC).

BIG CHANGES, PLEASE NOTE...to help ensure faster updates to the Linux engine in the future, and to allow further opportunities to enhance the user experience, all future versions of AGS for Linux now only officially support Ubuntu Linux. At this time "Edgy Eft" is the current build environment. In addition, all but a very small set of libraries are now statically linked. This means that the runtime engine now relies on the versions of Allegro, DUMB, and many other libraries on your system to run. This should make for a far better (and more optimised) experience for many users.

Why Ubuntu? Simple, it's the only one of two distributions that has a production release that will actually run on my new workstation. That and after years of using so many of them, it is the first one in a long time I've actually liked.

However, don't worry about the new library dependencies. You should be able to install whatever dependencies you need using this:

Quotesudo apt-get install libaldmb1 liballegro4.2 libgtk1.2 libxml1

Obviously, the binaries should work on any distributions that meet these requirements or any Debian / Ubuntu derivatives:

gcc >= 4.1
glibc >= 2.4
aldmb >= 0.9.3-5
Allegro >= 4.2
GTK = 1.2
LibXML 1

Quite frankly, trying to build the AGS binaries in the past in a way that would run on many different Linux distributions was a nightmare, and was part of why it has always taken me so long to make a release. I no longer have the time (or ability due to hardware) to run and test on a handful of Linux distributions. Using Ubuntu will also provide me extra options in helping bring the AGS Linux port to be closer in features to the Windows version.

Thanks to all for your patience and understanding.

strazer

#1
First of all, thanks for your continued efforts to support us Linux users!

Quote from: EvilTypeGuy on Wed 24/01/2007 05:06:03In addition, all but a very small set of libraries are now statically linked.

You mean dynamically linked? I think I liked it better before, because of things like this:

Debian/testing: "ags: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ags)" :(

Edit:

Even unstable still has libc6 2.3.6. Looks like I will have to wait again.

SSH

Would it be very hard to provide both a statically and dynamically linked version?
12

jkohen

#3
Same here. Glad to see this finally released, and I know you'll hate me/us for asking, but is it possible to link statically against glibc for now? As strazer said, Debian only includes the new libc on experimental and it's not going to enter unstable at least for a while. Definitely not until after the release of etch and the chaos ensuing right afterwards.

Edit: oh, well, I think it's not that bad to setup a chroot environment with Debian experimental to run AGS, is it? :)

EvilTypeGuy

#4
Quote from: strazer on Wed 24/01/2007 13:03:24
First of all, thanks for your continued efforts to support us Linux users!

Quote from: EvilTypeGuy on Wed 24/01/2007 05:06:03In addition, all but a very small set of libraries are now statically linked.

You mean dynamically linked? I think I liked it better before, because of things like this:

No, I mean statically linked. Really. I don't statically link anything but a few sound libraries.

Unfortunately libc is backwards compatible (you can use a new version with a binary built on an old version) but not forwards compatible (you can't use a binary built with a new version on an old version). This means that if I build it on a system with glibc 2.4, you *should* be able to use it on any system with glibc 2.4 or newer, but not older.

QuoteDebian/testing: "ags: /lib/tls/libc.so.6: version `GLIBC_2.4' not found (required by ags)" :(

Edit:

Even unstable still has libc6 2.3.6. Looks like I will have to wait again.

Sorry :( You may wish to consider using Ubuntu instead of Debian.

EvilTypeGuy

Quote from: SSH on Wed 24/01/2007 13:32:15
Would it be very hard to provide both a statically and dynamically linked version?

I have tried the statically linked and the dynamically linked. I really don't want to maintain two different binaries. I've had emails from both sets of people that have problems with both. I'm honestly not sure what to do.

What I do know is that I should not be statically linking things. In fact, I was told in so many words terms by a RedHat engineer a few years ago that I was crazy for expecting a statically linked binary to work properly when it was a graphical one and used X.

The problem is that even if I statically link the binary, the versions of libraries that I would be statically linking are likely to cause problems with systems that older versions. When I had my old system, I use to be able to build the binary on RedHat 9 and RHEL3 (which were really old) so it wasn't a problem.

My new workstation however (an Intel Dual Core) can only run glibc 2.4 or newer based distributions. So, unfortunately, I don't think I really can.

I will look into a few options, but for now this is what I can offer. It's great if you're an Ubuntu user.

EvilTypeGuy

#6
Quote from: blashyrkh on Wed 24/01/2007 15:05:11
Same here. Glad to see this finally released, and I know you'll hate me/us for asking, but is it possible to link statically against glibc for now? As strazer said, Debian only includes the new libc on experimental and it's not going to enter unstable at least for a while. Definitely not until after the release of etch and the chaos ensuing right afterwards.

I encourage you to use Ubuntu. At this time, I don't have another option. I will however look into see what I can do, though it is difficult with my system. I do *not* want to maintain multiple binaries. This whole mess is one of the reasons why I think Solaris, Mac OS X, and Windows are better platforms for users. You don't have to deal with these problems :(

jkohen

#7
None of the platforms you mentioned are that great with forwards compatibility, for what it's worth. I've heard you can't expect much backwards compatibility from Windows Vista nor Mac OS's in general.

Although Ubuntu is probably what I'd use if I didn't use Debian, I'm quite happy with the latter for now. But thanks anyway!

marceledward

I am using fedora core 6 and I can't get it to run either

first it could not find some library's so I symlinked them:
# ln -T /usr/lib/libdumb-0.9.3.so /usr/lib/libdumb.so.1
# ln -T /usr/lib/libaldmb-0.9.3.so /usr/lib/libaldmb.so

But the fun didn't stop here, then ags returned:

./ags: symbol lookup error: /usr/lib/liballeg.so.4.2: undefined symbol: _blender_trans24

It seems to have to do with the allegro lib, but I am not sure..
Wich version of alllegro did you use to build the binary ?


strazer

His build environment "Edgy Eft" seems to use version 4.2.0 currently. Strange.

farvardin

thank you for your effort, but I can't even manage to pass the allegro test :

./ags: error while loading shared libraries: libaldmb.so.1: cannot open shared object file: No such file or directory

I don't understand what you said about statically linked libraries : for me, dynamically linked, means lots of dependancies, and we can see there are many here :

ldd ./ags Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã,  Ã, linux-gate.so.1 => Ã, (0xffffe000)
Ã,  Ã,  Ã,  Ã, liballeg.so.4.2 => /usr/lib/liballeg.so.4.2 (0xf7e46000)
Ã,  Ã,  Ã,  Ã, libm.so.6 => /lib/libm.so.6 (0xf7e20000)
Ã,  Ã,  Ã,  Ã, libpthread.so.0 => /lib/libpthread.so.0 (0xf7e08000)
Ã,  Ã,  Ã,  Ã, libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0xf7e02000)
Ã,  Ã,  Ã,  Ã, libXcursor.so.1 => /usr/lib/libXcursor.so.1 (0xf7df7000)
Ã,  Ã,  Ã,  Ã, libXpm.so.4 => /usr/lib/libXpm.so.4 (0xf7de6000)
Ã,  Ã,  Ã,  Ã, libXext.so.6 => /usr/lib/libXext.so.6 (0xf7dd7000)
Ã,  Ã,  Ã,  Ã, libX11.so.6 => /usr/lib/libX11.so.6 (0xf7cba000)
Ã,  Ã,  Ã,  Ã, libdl.so.2 => /lib/libdl.so.2 (0xf7cb6000)
Ã,  Ã,  Ã,  Ã, libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0xf7bd2000)
Ã,  Ã,  Ã,  Ã, libaldmb.so.1 => not found
Ã,  Ã,  Ã,  Ã, libgcc_s.so.1 => /lib/libgcc_s.so.1 (0xf7bc5000)
Ã,  Ã,  Ã,  Ã, libc.so.6 => /lib/libc.so.6 (0xf7a97000)
Ã,  Ã,  Ã,  Ã, /lib/ld-linux.so.2 (0xf7f69000)
Ã,  Ã,  Ã,  Ã, libdumb.so.1 => not found
Ã,  Ã,  Ã,  Ã, libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0xf7a91000)
Ã,  Ã,  Ã,  Ã, libXau.so.6 => /usr/lib/libXau.so.6 (0xf7a8c000)
Ã,  Ã,  Ã,  Ã, libXrender.so.1 => /usr/lib/libXrender.so.1 (0xf7a83000)
Ã,  Ã,  Ã,  Ã, libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0xf7a7d000)

I can't find this "dumb" library for my system (suse)

Maybe we're asking too much, but since it concerns only music, those libraries are not really compulsories for running a graphical games...
Anyway, with such libraries statically linked, I think it was easier to make it run on different systems...



EvilTypeGuy

#11
Sigh, and to think of the nasty emails I got about statically linking the libraries. Well, for now, this is the best that I can do. I will be leaving the country shortly and won't have access to my workstation for a few months. So, it is likely there will not be a new release until I return from Australia in late March unless I can figure something out in a short time. Really, statically linking libraries is a pain.

...and people wonder why Linux doesn't get more games. *grumbles*

EvilTypeGuy

Quote from: marceledward on Wed 24/01/2007 19:29:47
I am using fedora core 6 and I can't get it to run either

first it could not find some library's so I symlinked them:
# ln -T /usr/lib/libdumb-0.9.3.so /usr/lib/libdumb.so.1
# ln -T /usr/lib/libaldmb-0.9.3.so /usr/lib/libaldmb.so

But the fun didn't stop here, then ags returned:

./ags: symbol lookup error: /usr/lib/liballeg.so.4.2: undefined symbol: _blender_trans24

It seems to have to do with the allegro lib, but I am not sure..
Wich version of alllegro did you use to build the binary ?



I used Allegro 4.2 as built and distributed from the Ubuntu repositories. Which means that the Debian for your distribution is probably built differently. Joyous!

EvilTypeGuy

Quote from: blashyrkh on Wed 24/01/2007 18:47:14
None of the platforms you mentioned are that great with forwards compatibility, for what it's worth. I've heard you can't expect much backwards compatibility from Windows Vista nor Mac OS's in general.

Although Ubuntu is probably what I'd use if I didn't use Debian, I'm quite happy with the latter for now. But thanks anyway!

Actually, they are great with forwards compatibility. Sorry, I swapped the forwards and backwards earlier :)


EvilTypeGuy

Quote from: farvardin on Wed 24/01/2007 21:55:07
Maybe we're asking too much, but since it concerns only music, those libraries are not really compulsories for running a graphical games...
Anyway, with such libraries statically linked, I think it was easier to make it run on different systems...

No, trying to make a version that built without it would be painful. I have no answer to your quandary right now except to use Ubuntu. No one seems to have packaged the dumb and aldmb libraries for SuSE.

jkohen

Quote from: EvilTypeGuy on Thu 25/01/2007 00:59:12
Quote from: blashyrkh on Wed 24/01/2007 18:47:14
None of the platforms you mentioned are that great with forwards compatibility, for what it's worth. I've heard you can't expect much backwards compatibility from Windows Vista nor Mac OS's in general.

Although Ubuntu is probably what I'd use if I didn't use Debian, I'm quite happy with the latter for now. But thanks anyway!

Actually, they are great with forwards compatibility. Sorry, I swapped the forwards and backwards earlier :)

Really? So you say that a program compiled for Windows XP will run on Windows 95? Or a Windows 95 application will run on Windows 3.1? Let's not even suggest the dready Windows 2.0 or 1.x. I'm not sure, but many applications targeted to Windows 3.1 probably didn't work on Windows 3.0, without its truetype and printer spooler support. Of course, I doubt you can get any of the latter to run in a modern computer without too much pain.

Apple never cared about backwards compatibility at all, and much less forward compatibility, so I don't see your point. I don't know much about Solaris, so I'll have to take your word for that one.

Anyways, this is all off topic. I hope glibc 2.5 gets into Debian/unstable soon, or Wine gets better supporting AGS, now that they finally seem to have fixed DirectInput.

EvilTypeGuy

#16
Sorry, there appears to be confusion about how we view forwards and backwards compatability.

If you're talking about an OS in general, then backwards compatibility is the ability to run older programs on newer operating systems.

So, for example, glibc 2.4 programs are generally compatible going *forward* with newer versions of glibc, and newer versions of glibc (such as an elusive 2.6) are *backwards* compatible with glibc 2.4 programs. Yes, it's confusing :P

My whole point was that, generally speaking, dealing with libraries is easier on other platforms. On windows you can just distribute your apps with DLLs in its own directory, and its dead easy and it works. On Linux, distributing your own shared libraries doesn't guarantee you squat, since your shared libraries depend on others, and you quickly go mad! Not only that, but typically speaking, a DLL is a DLL on Windows. There aren't umpteen different builds of the same thing, unlike the Linux world.

Anyway, I digress. This mess is one of the reasons why I decided to just pick a distribution and be done with it.

farvardin

#17
if I remember well, on Neverwinter night for Linux they put some libraries into the same folder, and a script to include them in the game, so most players can run the game :

#!/bin/sh

# This script runs Neverwinter Nights from the current directory

export SDL_MOUSE_RELATIVE=0
export SDL_VIDEO_X11_DGAMOUSE=0

# If you do not wish to use the SDL library included in the package, remov
e
# ./lib from LD_LIBRARY_PATH
#export LD_LIBRARY_PATH=./lib:./miles:$LD_LIBRARY_PATH
export LD_LIBRARY_PATH=./miles:$LD_LIBRARY_PATH

./nwmain $@

SSH

That seems like a good solution, favabean. It should even be possible for someone else than EvilTypeGuy to package it up...

Sorry to sound like we're getting at you, EvilType... you've done a great job updating this, and thanks!
12

jkohen

The problem, at least for some of us, is that he's compiling against a more recent glibc than is bundled with our systems. Including glibc this way might or might not work, but it will definitely be a very large download in comparison.

SMF spam blocked by CleanTalk