| 1 |
On 08/10/2016 06:10 PM, James Le Cuirot wrote: |
| 2 |
> Hello all, |
| 3 |
> |
| 4 |
> We, like almost everyone else and presumably upstream, install PCRE 8 |
| 5 |
> as libpcre.so.1. Debian, for reasons best known to themselves, install |
| 6 |
> it as libpcre.so.3. With Ubuntu still being the most widely accepted |
| 7 |
> "standard" Linux desktop, this presents a problem when dealing with |
| 8 |
> pre-compiled binaries. |
| 9 |
> |
| 10 |
> I have been working on a script to replace the rather lacking |
| 11 |
> steam-games-meta ebuild (see steam-overlay). I'm very excited about |
| 12 |
> releasing it soon as I think it is a major step forwards in our ability |
| 13 |
> to easily run Steam without the official Ubuntu-based runtime. |
| 14 |
> |
| 15 |
> Before I put it out there, I'd like to get Alien Isolation working |
| 16 |
> properly. It links to libpcre.so.3. Hacking the binary might work but |
| 17 |
> this isn't ideal and not always an option as some games use Valve's |
| 18 |
> anti-cheat system, which is ruthless. |
| 19 |
> |
| 20 |
> I have found that creating a symlink in /usr/lib that points |
| 21 |
> to /lib/libpcre.so.1 works, except that when you run ldconfig, it |
| 22 |
> automatically creates another symlink from /usr/lib/libpcre.so.1 to |
| 23 |
> libpcre.so.3. If you create the first symlink in /lib instead then the |
| 24 |
> existing /lib/libpcre.so.1 holds after running ldconfig. The latter |
| 25 |
> location is therefore probably preferable. |
| 26 |
> |
| 27 |
> Would anyone have any issue with adding this to our libpcre package? I |
| 28 |
> don't foresee any problems. libpcre.so would obviously still point to |
| 29 |
> libpcre.so.1. I'm pretty sure there will never be another libpcre.so.3 |
| 30 |
> as upstream have released PCRE2 as libpcre2, effectively an entirely |
| 31 |
> separate library. |
| 32 |
> |
| 33 |
> I could create a Steam-specific package for this but that would mean |
| 34 |
> adding some additional Steam-specific location to ld.so.conf, which I'm |
| 35 |
> trying to avoid. It would be nice to solve this generally anyway. |
| 36 |
> |
| 37 |
> Thoughts? |
| 38 |
|
| 39 |
|
| 40 |
Whilst devs are discussing the future of Valve's offerings on gentoo, |
| 41 |
it'd be wise to consider the effects of "Vulcan" as it is FOSS where all |
| 42 |
video card vendors can inter-operate with multiple game vendors. Vulcan |
| 43 |
will impact those gaming codes, as Vulcan seems to be the clear pathway |
| 44 |
forward for Valve related to Open Source communities [1 3]. |
| 45 |
|
| 46 |
|
| 47 |
[1] |
| 48 |
http://www.kitguru.net/components/graphic-cards/anton-shilov/valve-directx-12-does-not-make-a-lot-of-sense-vulkan-does/ |
| 49 |
|
| 50 |
[2] |
| 51 |
http://www.pcgamesn.com/khronos-and-valve-reveal-details-of-vulkan-api-show-dota-2-running-in-source-2-on-intel-integrated-graphics |
| 52 |
|
| 53 |
[3] |
| 54 |
https://community.amd.com/community/gaming/blog/2016/02/16/radeon-gpus-are-ready-for-the-vulkan-graphics-api |
| 55 |
|
| 56 |
|
| 57 |
hth, |
| 58 |
James |
Archives