I tried to run PA on my Archlinux isntallation and it failed with (already known here) "version `CURL_OPENSSL_3' not found (required by ./PA)" issue. The previously suggested fix (installing more-then-a-year-old curl package from ARM) is not available now (as ARM is closed). Likely I'll manage to hunt down the libcurl binary with CURL_OPENSSL_3 elsewhere (or I'll build one), but this situation leads me to a simple question: why Linux PA binary is not staticly linked? Developers, did you actually try linking it statically? Most likely the binary won't become dramatically larger (at least "nm -g PA" lookup suggest so), and it will be able to run on any Linux distro (or may be even on FreeBSD with linux-compat).
well libs themselves have dependencies, and those dependencies have dependencies and.. well you see what is. I'm not sure the extent on libcurl, but for small libs that can standalone, I see no reason why not to statically link it. It's like the Matlab runtime compiler, you can install the matlab runtime so sombody can run your crazy analysis software with a small download, or have them download 200 or so MB of executable.
Why do you use post formatting without reason?No, seriously. It's designed for large articles formatting and it's not make it easier to read your message. First reason. This game use middleware called Coherent UI and this is actually modified Chromium. It's have tons of dependencies and Uber can't do anything about that. So basically there is no reason to make distro-neutral game executable because CoherentUI_Host.bin need half of Ubuntu as dependencies.
Linking it statically will likely reduce the amount quite a bit - staticly linked executables don't need to include all the dependendencies of the libs - only those of used symbols are needed. And they may also have less dependencies then their dynamic counterparts. P.S.: Removed formatting.
Right now I have two missing dependencies on Arch: "PA/host/CoherentUI_Host.bin" is linked against now obsolete standalone libudev; "PA/PA" and "PA/crashupload" are linked against ancient curl version; I'm not entirely sure, but most likely every non-Ubuntu Linux user has these problems. And nearly every user will have these problems before summer'2014. Either Uber is ready to undertake the pain of keeping eye on every Ubuntu update (and there are other distros beyond Ubuntu, you know...) or it may invest some effort into making static executable and only rebuild it when PA's code changes.
I do understand what static linking mean, but most of PA deps is Coherent deps and Uber don't have it's source code and possible don't even have debug builds. So they just can't make own static build.
Again. Coherent UI is build with Steam Runtime (Ubuntu 12.04 libraries) and devs can't do anything about that. If you don't have required libs in your distro then you have to find them manually or use Steam. Static builds it's not something they can just do with few flags. It's will require testing and technically might cause more problems on some specific configurations. I guess there still much more important things they might spend time on, e.g: PA#2803 I do agree they need to find out with most annoying problems like libudev and curl, but anything else just not worth time.
As I guess problem with cURL related to OpenSSL dependency, but I'm not too good about building stuff, so I can't say what solution here. Main problem with libudev that players need to make one which will work on every distro and then ask devs to include it with game. I'm posted my fixed version of startup script here: PA#2024 If you can review how it's works and give some feedback this will be helpful. Unfortunately I'm fix script, but I'm Debian/Ubuntu user and I'm too lazy to test it across different distributions. But if other players can test it and fix bugs then I'll submit it to devs and probably it's will be included in next update.
You seem to misjudge on this issue. It is not just a simple question of curl problems - the binaries in PA distributions are linked against a lot of software, and more issues will inevitably pop up soon. Just wait for another library's version bump. Uber indeed should seek staticly-linked Coherent, so that the problem of dependencies is resolved in a long term. Specificly so if Uber doesn't have access to Coherent sources.
Coherent based on Chromium codebase and it's updates stick to mainline Chromium and I guess Coherent devs can't just go and do something that Google don't support. Something you asking for isn't easy and there is no guarantee that game will work better. I guess it's just not important for game in development where binaries updated few times a month. When game will be released and updated less often then there will be reason to think about static builds.
It's fairly trivial to make static Chromium build. If you don't take my word for it, I can build static Chromium and post it. (Though it will take some time since I'm limited both in buildpower and free time.) It is. It would be much easier to update the game using binary deltas, and it would give Uber tight control over players' environments, making easier to reproduce crashes and avoid weird distro-specific issues. In the end it would save much time for Uber.
To be fair I know that Chromium/Chrome link most of deps statically, but I never think there is real static builds. E.g they still depends on some libs anyway. I'll be happy to find myself wrong if you can give me some proof link. I doubt they really care about bandwidth usage for Linux users because game servers eat way more bandwidth than game client downloads. E.g game using about 2mbps for each player so it's lot of bandwidth. Since alpha there most likely wasn't any distro-specific or library-specific crashes except this one: https://forums.uberent.com/threads/linux-working-distributions.48673/page-4#post-819281 But static builds won't help in this case because it's GTK problem. Anyway I don't think developers will spend time on troubleshooting problems of minority distributions. Valve made Steam runtime and PA/Coherent compatible with it. People who want to use their humble Linux distribution can use it or get Ubuntu LTS libraries on their own.
For the most part linux is actually VERY ABI stable, I have some proprietary software from the 90's that still quite happily runs on either my home Gentoo box or my work Ubuntu box... That said there are some libraries that are reasonably "ABI unstable" or ones that reach a point that they have to break their ABI stability for one reason or another (to fix some old code for instance...) lib{curl,jpg,png,stdc++} are the usual ones that are bundled due to their expected instability. Why this game directly links against libudev is quite bizarre. There are some issues with the CoherentUI_Host sh script which I don't think have been fixed (I posted a fix for it in another thread) that will allow the correct symlink to be made on some distro's that dot different libudev around the place (ie ones that adhere to the build of libudev....)
Can you review my version of script here? PA#2024 Main problem of this script fix that somebody have to test a lot it before it's can be submitted to devs.
For the most part it is fine. You are iterating over a sh array for all libudev found. Immediately this is a vast improvement over the present sh file which blindly assumes a single entry return (and thus bombs out when multiple returns are provided). My local edited script has two things different 1) I used head -1 instead of iterating over all libudev that are found. This was more just to get it working. Iterating over all found is the better solution 2) I have /sbin/ldconfig -p. The present script and your submission still uses ldconfig -p. This is only valid on distro's that have /sbin in the $PATH of a normal user (ubuntu and co do... gentoo, arch do not and thus it fails)
Good notice. there was one player who don't have it. Any idea how to improve it? To be fair I'm not sure if ldconfig found in every distro or not (i mean found at all).
ldconfig is part of glibc and thus should be std on all linux distro's (along with ld.so) so it should be pretty safe to rely on that "improvements" ? to: I wouldn't even bother doing the test on non-zero LD_LIBRARY_PATH, its being set anyway & BASH has uninitialised variables as zero to
