Thanks, I'll take a look on it when sleep and wake up. It's was here in original script so I just don't touched it.
there is that. Two ways of looking at this 1) making what is present work. This will require the /sbin/ prefix and the loop over the bash array of libudev entries 2) make a good job of it. If I was to write this from scratch I would do something like this: Code: #!/bin/bash HOST_DIR="${0%/*}" if [[ "${LD_LIBRARY_PATH+set}" = "set" ]] ; then export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:HOST_DIR" else export LD_LIBRARY_PATH="$HOST_DIR" fi if ! [[ -L "$HOST_DIR/libudev.so.0" ]]; then UDEV_SO_LIST=( $(/sbin/ldconfig -p | grep libudev.so.[01] | cut -d' ' -f4 )) if [[ ${#UDEV_SO_LIST[@]} -eq 0 ]]; then echo "Could not find libudev.so.1" # exit 1 fi for UDEV_SO in "${UDEV_SO_LIST[@]}"; do if file -L $UDEV_SO | fgrep 'ELF 64-bit' &>/dev/null; then ln -s "$UDEV_SO" "$HOST_DIR/libudev.so.0" break fi done fi exec -a "$0" "$HOST_DIR/CoherentUI_Host.bin" "$@" General cleanup basically taking what I did and what you did, more bashish test on the existence of LD_LIBRARY_PATH, actually check that the symlink points somewhere valid, slight tweak to the bash array length test (better todo -eq rather than string compare to zero) I have tested this and it generates the symlink quite happily. Basically it will ALWAYS generate the symlink and thus the precence of a symlink (even if it isn't needed for so.0 systems) is an indication if the udev environment has been sanitised. Using [[ over [ utilises bash builtin test facility as oppose to the application "[" and thus it is quicker and cleaner and with the environment sanitised it can quickly go straight to launching the game
I'm have only one more idea about libudev check. Are we sure there is no distributions where libudev have totally different name? E.g not "libudev.so.1" and not "libudev.so.0"
at some point libudev.so.2 might come along. Thats the point of dynamically linked libraries but that will cause quite a few issues... Again does raise the question wtf is this depending on quite a low-level library, why does it have to hook directly into the device manager query library? PA should be abstracted enough away from that especially due to Xlibraries... this type of thing, especially with binary applications is what results in programs not functioning 5-10years down the line when some major low-level shift is required (udev is actually relatively new, replaced devfs in 2003 which replaced static /dev when kernel 2.4.0 was released in 2001 and static dev had been around since linux inception and unix inception in the 60's) --edit-- Well Coherent directly linking to libudev is because Coherent is built on Chromium which does link to libudev... but chrome hooks into things like webcams and such. I have a nasty feeling, especially with the device management being in the state of flux as they are in linux RE. Systemd ... that PA directly building against Coherent which directly builds against libudev.so.0 could come back to bite linux users in a few years... --edit-- Someone could come along and make libudev.so.22 but the benefit of linux is the majority stear things (and hickups occur when libudev.so.1 is the newer version of udev and came about when udev was absorbed into systemd. Distro's affected? Ubuntu 13.04 Fedora 18, 19 Arch Gentoo Derivatives of the above The others are still using udev as a standalone package BUT at some point will upgrade (what are Uber baselining against for building PA?). libudev.so.1 and libudev.so.0 should be API and ABI compatible so the link shouldn't break anything.
Thank for such large post, but actually I'm only worried about library naming. E.g currently script only check for libudev.so.1 and libudev.so.1
we shouldn't see any other named files then HOWEVER! EVEN BETTER SOLUTION!!! pertaining to what I wrote and why I don't think Coherent needs direct udev access (chrome does for webcam etc and for chromebook...) I started playing around with that library: Working on a hunch that ld only needs the shared libs satisfied for it to then be loaded by the kernel... I did a few tweaks 1) touch libudev.so.0 # did not work, PA/ld complained it was the wrong length 2) make a file the same size via dd if=/dev/urandom of=libudev.so.0 bs=1 count=131136 # did not work, PA/ld complained not a valid ELF file 3) cp /dev/bash ./libudev.s0.0 # did not work, needed a linked library 4) cp /lib/libwrap.so.0.7.6 ./libudev.so.0 # SUCCESS!!! PA launches!!! so... it needs a valid library to launch (ie to satify the ELF structure) but doesn't use it. so... 1) libdummyudev.c Code: #include <stdio.h> int main(void) { return 0; } 2) gcc -Wall -fPIC -c *.c 3) gcc -shared -Wl,-soname,libdummyudev.so.1 -o libdummyudev.so.1.0 *.o 4) ln -s libdummyudev.so.1.0 libudev.so.0 Guess what runs I suggest Uber ships a sharedlib stub and the symlink Well... linux users test this to death first
Well, actually it's interesting idea. Currently it's not possible to use microphone/webcam in UI, so probably we don't lose anything.
Mic is via fmodex (which then goes via alsa,Pulse,oss ... ) webcam... well only use would be for twitch overly if you would ever want todo it ... even then I don't think chrome does that and chrome uses udev for webcam, google video calls/hangouts
FMOD not accessible though mods, but currently Mic/Webcam in Coherent not accesible anyway because there is no confirmation which ask for cam/mic access. So for now your idea bout dummy library looks nice if it's will actually work as excepted.
Now "librtmp.so.0" is replaced with "librtmp.so.1" on Arch since rtmpdump update at 2013-12-29 17:18 UTC. Other distros to follow. Getting ".a" libs from Coherent devs would definitely solve this and all of the discussed above in a more consistent and reliable way. eeyrjmr Works for me. I actually used this:
That looks like an arch specific issue, but an issue that has to be delt with non the less. Code: ll /usr/lib/librt librt.a librtmp.a librtmp.so librtmp.so.1 librt.so genlop rtmpdump * media-video/rtmpdump Wed Mar 2 21:48:27 2011 >>> media-video/rtmpdump-2.3 Fri Aug 12 20:23:15 2011 >>> media-video/rtmpdump-2.4 Thu Oct 31 20:10:25 2013 >>> media-video/rtmpdump-2.4_p20131018 equery b /usr/lib/librtmp.a * Searching for /usr/lib/librtmp.a ... media-video/rtmpdump-2.4_p20131018 (/usr/lib64/librtmp.a) I have had .s0.1 since October without any issue (but I do have the .a file) Nice and clean so that should work, that could even be put into the _host script to auto gen it if it doesn't exist. The udev thing is unique since Chrome (directly from Google) still builds against udev.so.0 so Coherent bumping will not fix that issue. The rtmp however isn't
Apparently dummy trick does it. May be a wrapper script for PA should check for these libraries and generate appropriate dummy libraries in main directory? I didn't yet have time to try it, but I suppose that there may even be a special subdir with dummy libraries for unused dependencies (I suppose there may be more leftovers in Coherent then libudev and librtmp). I checked PKGBUILD (Arch's build script) for Chromium - we have several patches, but none has anything to do with udev - aparently Chromium builds OK with systemd's udev, which is also default udev everywhere now (AFAIK on Ubuntu too). So if Coherent devs are interested in better support for their product, they may want to build against current software. But if they cared, they would have produced only archives (".a" libraries) anyway...
Chromium is the community built from community repo and yes it will link against the sysd. Chrome as built and packaged by Google uses so.0 prob due to old ('stable') toolchain used to build chromebook against. They do the symlink trick BUT they need udev. PA does (so far... And no reason it should) so a symlink or a stub is valid. rtmp however... That could be important to pa so not sure how long a stub is viable
I guess all game middleware developers only care about Steam runtime which is currently based on Ubuntu 12.04. Coherent will work everywhere if Steam runtime installed.
Now, that was me who messed things up here. "librtmp.so.0" appears to be dependency of libcurl binary I used to run PA, so this problem is neither PA- nor Arch-specific - it is simply my own mistake. Sorry for noise. I fail to understand how exactly Chrome is relevant here. Coherent is a fork of Chromium, and thus it inherits the properties of Chromium; you are talking about properties of Chrome that have nothing to do with Chromium. Furthermore, even if Chromium was routinely linked against legacy udev, I just can't see how this affects Coherent. Sorry, what Steam runtime are you talking about exactly? The one I see in packages is 32-bit only, which is of no use to 64-bit only PA. Even if I miss something, I'm still unsure whether it is really an excuse, as I bought my PA beta access directly from Uber under impression that PA runs on Linux - which is not merely "PA runs on Ubuntu" or "PA runs on Steam". I believe I am entitled to ask for a build that matches reasonably complete understanding of "Linux", given that it was advertised this way. At the same time I believe that I can't be tasked with cherry-picking contents of Ubuntu packages I am not even supposed to be aware of. Sure, there are Microsoft, Adobe and Google products for Linux that already do this "dynamicly linked binaries" nonsense, but they don't actually advertise their products as Linux-compatible - instead they list supported distros, versioned. Provided, that most likely Uber is in contractual relationships with Coherent devs I assume that Uber can fulfil its promise by getting staticly linked Coherent from whoever makes it and deliver staticly linked binary I could use right until my last breath regardless of my choice of Linux distro.
Its relevant because when the udev thing was 1st detected (ie within 5min of it becoming available for linux) & symlink suggested it was based upon what chrome (thats google chrome) does. THAT is why it is relevant to mention. Now chromium will link against s0.1 or so.0 but it depends on the toolchain being used... YES Coherent should update (their toolchain) OR Uber should update (the version of coherent they are using...)... but right now the game is beta and we have workarounds and uber are aware (where it is uber or coherent is something between uber and coherent) OR... you could chill a bit and accept this is BETA & a steep learning curve for Uber. If they find something that works (NOTE I am not even saying they are dependent on STEAM... they are slightly because although steam is 32bit, it ships with a couple of 64bit libraries... namely the ui overlay one WHICH PA can use & will need if you launch through steam) its better they use what works to try to keep feature parity with windows before they chill features and then iron out release bugs.
I invest my time here to convince Uber to take a technical decision that would benefit their product and possible extend the period of their offer viability. At the same time I invest my time in making PKGBUILD (packaging script) for Arch User Repository, so that any Arch user who payed Uber for PA and downloaded the Linux distribution from their site may run the standard build command ("makepkg") and enjoy PA without fiddling with distribution-specific issues and hunting for workarounds for known problems. Right now I got PA to install and run (via menu icon in freedesktop-compliant start menu), but there are some issues I need to solve before submitting the PKBUILD to AUR, with libcurl problem being one of them. The fact that I have to fiddle with libcurl and numerous Coherent dependencies isn't particularly helpful. (Once I have a fully working script I'll commit it to AUR and start a dedicated thread on this forum.) I seriously doubt that you need anything from steam to launch your app via steam. Though I'm no steam user, so I may be utterly wrong here. And this is IMO fundamentally wrong. I'm convinced that only reliable way of propriatory Linux software development is to make a solid foundation and then work to reach feature parity. Otherwise developer risks to waste quite a lot of already invested effort with an unexpected update - if Ubuntu updates some of numerous Chromium dependencies to a version with incompatible ABI - Uber will loose the Linux platform for non-steam players.
