[chief1983]

No in Windows openal-soft is set up differently, we only use the reference implementation until recently and the openal-soft library is installed to the game folder on an as-needed basis currently.

I'd love if we could have a binary that works on most distros without hassles, but so far it hasn't always worked that way.  Help in that area would be appreciated.

[RedDwarf]

No in Windows openal-soft is set up differently, we only use the reference implementation until recently and the openal-soft library is installed to the game folder on an as-needed basis currently.

I'd love if we could have a binary that works on most distros without hassles, but so far it hasn't always worked that way.  Help in that area would be appreciated.

Sorry, I never used the Windows version. "installed on an as-needed basis"? How, from the launcher? It was my understanding that the Windows version also needs of an OpenAL library. And since Windows will not provide it by default you would include it with the binary (either the reference version or openal-soft).

In Linux the libraries are searched (from man ld.so):

       The shared libraries needed by the program are searched for in the following order:

       o  (ELF only) Using the directories specified in the DT_RPATH dynamic section attribute of the binary if present and DT_RUNPATH attribute does not exist.  Use of DT_RPATH is dep-
          recated.

       o  Using the environment variable LD_LIBRARY_PATH.  Except if the executable is a set-user-ID/set-group-ID binary, in which case it is ignored.

       o  (ELF only) Using the directories specified in the DT_RUNPATH dynamic section attribute of the binary if present.

       o  From the cache file /etc/ld.so.cache which contains a compiled list of candidate libraries previously found in the augmented library path.  If, however, the binary was  linked
          with the -z nodeflib linker option, libraries in the default library paths are skipped.

       o  In the default path /lib, and then /usr/lib.  If the binary was linked with the -z nodeflib linker option, this step is skipped.

So you can build fs2_open against openal-soft using rpath to say the binary to search the library in the same directory the binary is installed (using "$ORIGIN" as rpath). The binary will search for libopenal.so.1 in the same dir the binary is installed (you distribute both). And if the user wants to use the system openAL library he can just delete the version distributed with fs2_open and the linker will correctly find the system's version.

[chief1983]

We have never used OpenAL-Soft until recently, it's apparently helping with some issues in the new audio code.  Currently that library is only being installed by hand for testing by copying it to the game directory.  If it helps enough we may find a way to have the new launcher/installer pull it down.

We're not distributing a version of libopenal.so.1 with fs2_open on Linux, but you're saying there's a way to have it find libopenal.so without needing a symlink?  That's essentially what we need in this particular case.

[Iss Mneur]

I have a package for openSUSE... but users need to build it. That's becasue the non-commercial part of the license. Such a thing is against OSI's Open Source definition and FSF's Free Software definition, so most distros will not package it. And it could be also a problem for openSUSE because of Novell (and RedHat/Fedora? Others?). Things would be easier without that part of the license, but I suppose it would be difficult to change.

OpenSUSE doesn't allow third party binary packages and/or third party package repositories?

At least in the case of Ubuntu, IIRC FSO does qualify under the universe class though.  wxLauncher itself is GPL (because it is original code), but because wxL is useless without FSO it would probably also end up in universe (again IIRC).  Geting wxLauncher into the distro repos is something that one TC has expressed interest in to me about, so that they can simplify the release of there TC.

Removing the non-commercial clause of the source code would be great, but the license of FSO can only be changed by :V: and/or Interplay.  Aslo we would need to go through the code repo and get the permission of everyone that has contributed code to the project, some (most?) of whom are no longer active.

In any case, because the current linux build system that FSO uses handles the iterations and variations on the different distros rather well, wxL may just end up making sure that all of the required dependencies get installed and then run the build manually using Linux platform build system.

Which APIs aren't compatible across distros?

Its not that the APIs necessarily change but the location of the .so (dynamic link library) is not consistent.  Some platforms have support for the LSB to help minimize this, but I don't know if the APIs that we require are actually specified in the LSB.

Also some of the APIs that we link to are only source compatible based on the version that is actually installed. Lua and the SDL would be good examples of APIs that we use that we are source compatible with, that is, we can use a range of versions of the APIs but only when compiled against those APIs.

The dynamic libraries can be anywhere specified at /etc/ld.so.conf (and you can add more paths with a file in /etc/ld.so.conf.d/ with a sane /etc/ld.so.conf). But in every normal distro they will be at /usr/lib or /usr/lib64. What's the standard place in Windows? If you prefer you can use rpath and put the libraries in the same dir than the binary or any other path (absolute or relative, with $ORIGIN). Or naturally static link them. But I don't know why this was raised, the binary has no the library paths hardcoded and you don't need to provide any library, only a binary.

Interesting.  I did not know that.  That being said, the concern was not the directories that .so's are in, but the actual names of the libraries in those folders (yes, I know I said location in the quote above, but I meant names). That is, libraries that are called .so on one platform, .so.5 on anther, and .so.5.1 on yet another.  Yes symbolic links would solve this, but the distro does not provide them, asking the user to do this is not something that is "user friendly".

In windows case, the names of the .dlls are actually set down by the library maintainer so we avoid the entire name problem.  But currently FSO statically links every library it uses even the CRT except for the OpenAL redirector library (which is downloaded by users as a separate download).  This is actually something we want to move away from as wxL2 is implemented because wxL2 will then be able to install the the dependencies properly.  The currently the only reason that FSO doesn't dynamically link against the libs is because of the distribution method that we use.

To reiterate, we understand that libraries change, and we can mostly deal with that.  The issue is that the same binary library can have different names on different distros (even different versions of the same distro), this is our problem when distributing binaries for linux.

[RedDwarf]

We have never used OpenAL-Soft until recently, it's apparently helping with some issues in the new audio code.  Currently that library is only being installed by hand for testing by copying it to the game directory.  If it helps enough we may find a way to have the new launcher/installer pull it down.

Ok, now I understood it.

We're not distributing a version of libopenal.so.1 with fs2_open on Linux, but you're saying there's a way to have it find libopenal.so without needing a symlink?  That's essentially what we need in this particular case.

Well, it will always find "libopenal.so", whatever it's the reference version of openal-soft. But if the user didn't installed the development package probably it will not exists. The binary will search for either "libopenal.so.0" or "libopenal.so.1". And no, you can't use "libopenal.so.1" if the binary searchs for "libopenal.so.0" if you don't use a symlink*. But what you can do is distribute the library that you used in the compilation (either "libopenal.so.0" or "libopenal.so.1", I would recommend openal-soft) and make the binary search for it in the same path the binary is installed (normally it doesn't). It would be equivalent to Windows:
- openAL is distributed with the binaries
- The binary uses that version, so we are sure it's 100% binary compatible
- If the user deletes the included openAL, and he has a compatible version installed in its system, the system version is used.

The thing is:
- Use system versions when you are sure they will be compatoble for all users
- If for whatever reason you are not sure that all users will have a compatible version, distribute an specific version with the binary. If the user knows his system has a compatible version he can delete it at his own risk.


* You can if you use dlopen(). But that means modifying the code.

[chief1983]

Well modifying the code is, obviously, within our abilities

We should probably look into something like that.

[RedDwarf]

I have a package for openSUSE... but users need to build it. That's becasue the non-commercial part of the license. Such a thing is against OSI's Open Source definition and FSF's Free Software definition, so most distros will not package it. And it could be also a problem for openSUSE because of Novell (and RedHat/Fedora? Others?). Things would be easier without that part of the license, but I suppose it would be difficult to change.

OpenSUSE doesn't allow third party binary packages and/or third party package repositories?

It does. It could be added to Packman (the most important one)... but it's already a third party repository. And in this specific case I tried and got no answer (could try harder ;-) )

Interesting.  I did not know that.  That being said, the concern was not the directories that .so's are in, but the actual names of the libraries in those folders (yes, I know I said location in the quote above, but I meant names). That is, libraries that are called .so on one platform, .so.5 on anther, and .so.5.1 on yet another.  Yes symbolic links would solve this, but the distro does not provide them, asking the user to do this is not something that is "user friendly".

But every distro that uses LUA 5.0 will use .so.5; and every distro that uses LUA 5.1 will use .so.5.1. The names are different to explicitly say LUA 5.1 (.so.5.1) is not binary compatible with LUA 5.0 (.so.5). That's not something that you can fix with a symlink. If you create a symlink from .so.5 to .so.5.1 (binary compiled with LUA 5.0, user has LUA 5.1) the binary will find the library... but that doesn't means it will work. The libraries are binary incompatible, and the binary can break at any moment.

In windows case, the names of the .dlls are actually set down by the library maintainer so we avoid the entire name problem.

In Linux it is also the library maintainer who sets the names. Were LUA maintainer who decided to change the name to explicit say "these two libraries aren't binary compatible".


Normally library maintainer will maintain the binary compatibility longer. But LUA decides to break it more frequently. It's a problem with LUA, and it effects both Windows and Linux.
What you do is such cases is static compile... in Windows, in Linux and in any other OS.
At least in openSUSE case. What we also do is provide both versions. The default package, liblua5_1, will provide LUA 5.1. But if needed the user can install lua50-libs. They can be used in parallel.


Edit: I missread a patch. It seems at least version 5.1 of LUA can't be compiled as a shared library by default. So distributiosn had to patch it and each one could have added a different name. In the case of LUA 5.1 seems everybody used .so.5.1 but with LUA 5.0 some used ".so.5" and others ".so.5.0". This makes binary compatibility slightly worse in Linux than in Windows where everybody will use http://luabinaries.sourceforge.net/. But the binary incompatibility between LUA 5.0 and 5.1 argument still applies.

Edit2: Well, looking at the quantity of versions available at http://sourceforge.net/projects/luabinaries/files/5.1.4/Windows%20Libraries/ I'm not so sure about the "binary compatibility slightly worse in Linux than in Windows" thing. But I don't really know about the incompatibilities between dlls generated by different compilers in Windows. You really need different version for MSVCRT.DLL, MSVCR71.DLL, MSVCR80.DLL, MSVCR90.DLL, MSVCR100.DLL plus Cygwin and MingW??

[RedDwarf]

Well modifying the code is, obviously, within our abilities

We should probably look into something like that.

I don't think the work needed to use dlopen is worth. Right now isn't everybody already using openal-soft?
In openSUSE at least, 11.0 came only with reference version, 11.1 came with both, and 11.2 came only with openal-soft. And 11.0 is already unsupported.
Lenny (stable Debian) already came with openal-soft. "oldstable" is the only supported version that still used the reference version.
In Ubuntu it's included since Intrepid. The only supported versions that still uses the reference version are Dapper and Hardy. They are supported just because they are LTS. And if someone that wants to play games wants a LTS he probably is using Lucid.

Perhaps when openal-soft was released would have made sense. But now?
Anyway. You just need to use http://www.opengroup.org/onlinepubs/009695399/functions/dlopen.html and http://www.opengroup.org/onlinepubs/009695399/functions/dlsym.html. Try using dlopening with different names until it returns != NULL.

[Iss Mneur]

Edit: I missread a patch. It seems at least version 5.1 of LUA can't be compiled as a shared library by default. So distributiosn had to patch it and each one could have added a different name. In the case of LUA 5.1 seems everybody used .so.5.1 but with LUA 5.0 some used ".so.5" and others ".so.5.0". This makes binary compatibility slightly worse in Linux than in Windows where everybody will use http://luabinaries.sourceforge.net/. But the binary incompatibility between LUA 5.0 and 5.1 argument still applies.

To be clear, I pulled the numbers out of the air, I wasn't specifically thinking of lua when I wrote it.  As such, I understand about the binary incompatibilities, and like I said before there is nothing that we can do about it.  Our problem is with binary compatible libraries like what you said about lua version 5.0.

Also, keep in mind that a large part of the general "no binaries for linux" stance is that the SCP started with the linux porting sometime in 2004, when the distros did not play along as well with each other as they do now.  Also my opinon of this is also coloured by my experience installing linux game servers for other games in the time period (I had not heard of FSO at that time) and running into this same problem.  One distro would provide all symlinks for everything (for example .so, .so.1, .so.1.0, and .so.1.0.0 all pointing to the same binary) and other would only provide one or two of them.

I image reality has changed some since then, but for better or worse, fs2open is trapped in its own reality (which is a very windows biased reality).  We would do well with more people that are experienced with packaging and distribution of applications across multiple distros and operating systems other than windows.

[chief1983]

I plan on getting linux nightlies up again soon too, and we can see what the current state of running a Lucid built binary on other distros is.  Maybe it'll play nice now after all.

[RedDwarf]

To be clear, I pulled the numbers out of the air, I wasn't specifically thinking of lua when I wrote it.  As such, I understand about the binary incompatibilities, and like I said before there is nothing that we can do about it.  Our problem is with binary compatible libraries like what you said about lua version 5.0.

LUA is just a library. Static compile it and problem solved. Since upstream didn't provided a name each distro had to guess one. But normal libraries already come to be compiled as shared libraries, and distributions don't change its names.

Also, keep in mind that a large part of the general "no binaries for linux" stance is that the SCP started with the linux porting sometime in 2004, when the distros did not play along as well with each other as they do now.  Also my opinon of this is also coloured by my experience installing linux game servers for other games in the time period (I had not heard of FSO at that time) and running into this same problem.  One distro would provide all symlinks for everything (for example .so, .so.1, .so.1.0, and .so.1.0.0 all pointing to the same binary) and other would only provide one or two of them.

I image reality has changed some since then, but for better or worse, fs2open is trapped in its own reality (which is a very windows biased reality).  We would do well with more people that are experienced with packaging and distribution of applications across multiple distros and operating systems other than windows.

Well. I just downloaded http://swc.fs2downloads.com/builds/LINUX/fs2_open_3_6_10.tar.bz2... and it's plain perfect binary compatibility-wise.

Statically linked LUA, PNG and JPEG: the libraries that recently broke binary compatibility. And doesn't uses any feature from glibc newer than 2.3 (from 2002). The most common problem with that binary should be:
- "I use X86-64/PPC and the binary is only for x86-32. My distro doesn't has libvorbis for 32 bits in a x86-64 system". But neither I see x86-64 Windows binaries.
- The OpenAL-Soft thing. But as already said very few distros still have a supported version without OpenAL-Soft. And I'm pretty sure the guy that created that binary knows how to statically link OpenAL.

Is people really complaining??
As said trying to automatically compile from the installer seems to me a lot more difficult. The binary that you already have must work plain fine. At most I would add a x86-64 version.



Not important, but about the ".so, .so.1, .so.1.0, and .so.1.0.0" thing. Only a file is needed at run-time, the one that matches the DT_SONAME entry in the library (probably .so.1). And the ".so" is needed only to compile (and not really needed if you know what you are doing). ".so.1.0, and .so.1.0.0" are there just as information, but are not really needed... a distribution can or can't include them, isn't really important.


Edit: I also took a look at http://swc.fs2downloads.com/builds/LINUX/fs2_open_3_6_12_RC3_INF.tar.bz2 and isn't so good. It will only work in a system with glibc >= 2.11 (from November last year). And since January this year libpng 1.4 was released this wasn't the best moment to start dynamically linking to libpng 1.2.

[chief1983]

I made that binary.  I might be able to statically link OpenAL but we've erred in favor of not statically linking unless we need to.  In fact coming up Lua won't be statically linked anymore.  I think most of the linux libs are dynamically linked now (or at least compiled against system libs vs those in SVN, it may still link some of those in statically).

[RedDwarf]

I made that binary.  I might be able to statically link OpenAL but we've erred in favor of not statically linking unless we need to.  In fact coming up Lua won't be statically linked anymore.  I think most of the linux libs are dynamically linked now (or at least compiled against system libs vs those in SVN, it may still link some of those in statically).

Sure, if you have the option dynamic linking is always better.

From the number I though LUA 5.1 was a version released 6 months after LUA 5.0. But from its web it seems the first 5.0 version is from 2003-04-11 and the latest from 2004-03-17 (plus what seems an important bug fix release at 2006-06-19). The first LUA 5.1 is from 2006-02-20 and the latest from 2008-08-18. It all depends on how many distributions you want to support, but it seems any distro less than four years old will have LUA 5.1. So doesn't seems a big problem to dynamic link it.
It feels as is 5.2 will be released soon ("Lua 5.2 (work3)" released in May). When that happens new distros probably will install 5.2 by default but will maintain 5.1 packages for compatibility. But users will need to explicitly install those 5.1 versions. Again, it depends on which kind of support you want to provide.

About PNG: openSUSE 11.3 will be released next week. It will install libpng 1.4 by default. So if someone tries to run the 3.6.12 RC3 version he will need to explicitly install libpng12, the compatibility package. I suppose others will do the same.

About JPEG: If you start to dynamically link against it. You will find that an openSUSE 11.2 (and any other distro from the latest 10 years) user only has libjpeg.so.62. But an openSUSE 11.3 has libjpeg.so.8, he will need to explicitly install libjpeg6. It also existed a short lived libjpeg7, I expect nobody to use it.


So. It's a problem if users need to install compatibility packages? Every important distro provides these compatibility packages or only the latest versions? From the answer to these questions the decision has to be taken.


And then is the glibc thing. The 3.6.12 RC3 binary requires a very recent glibc. I think you need to compile with "-fno-stack-protector" to lower the requirement, but this way the binary will be less secure... what to do?

[RedDwarf]

Looking for input
The following are items that we are looking for more information on.

• Should wxLauncher be able to build FSO from source on Linux at least, maybe windows and osx?
• Because we are keeping the old files so that we can provide specific diffs, do we allow the user to request older versions of resources? How long do we keep them the old files?
• Who/Where are the mod files going to be stored?  In particular wxL2 would require MOD/TC data hosting with resume support that allows hot linking.

a) As already said. I think it's easier to provide binaries compatible with any distro than automatically compile (dependencies, code stops building with newer gcc versions, etc.)
b) I would provide a diff from X-1, X-2, X-N (decide N on a per-MOD basis) and the full version of the latest version. No need to provide full versions of old versions.
c) Each file could be in a different host, as now. In the central server you just need signed metadata that points to the data.

[chief1983]

Currently, the codebase seems to be compatible with libpng-1.2 and -1.4.

We could lower the glibc it's compiled against I suppose, until more distros catch up and lock stuff down.