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.