Arch Linux

I also have a problem with recently upgraded glibc 2.26, can't run Django server with PostgreSQL engine:

ImportError: /path/to/virtualenv/.venv/lib/python3.6/site-packages/psycopg2/.libs/libresolv-2-c4c53def.5.so: symbol __res_maybe_init, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference

and

django.core.exceptions.ImproperlyConfigured: Error loading psycopg2 module: /path/to/virtualenv/.venv/lib/python3.6/site-packages/psycopg2/.libs/libresolv-2-c4c53def.5.so: symbol __res_maybe_init, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference

UPDATE:

Works with downgraded glibc-2.25-7
https://archive.archlinux.org/packages/l/lib32-glibc/lib32-glibc-2.25-7-x86_64.pkg.tar.xz
https://archive.archlinux.org/packages/g/glibc/glibc-2.25-7-x86_64.pkg.tar.xz

I don't own any of these games – and I don't suspect any bug on our end. Does Feral have a bug tracker for their games?

@Denis, you need to recreate these virtualenvs. It's not a bug, and unrelated to this one.

>you need to recreate these virtualenvs
@Barthalion I've tried, but it didn't help. I know that problem appeared just after upgrading glibc and gone away when I installed the old version of it. So, I suppose, it's either related to glibc or to psycopg PostgreSQL adapter. Also I didn't update psycopg package that day.

>Denis, try to invoke pip with '--no-binary :all:'. That should fix it.
That helped, thanks a lot.

Denis, try to invoke pip with '--no-binary :all:'. That should fix it.

I also have this issue with these other Feral games I own/installed; CoH2 and DoW 2/3, but my other steam games do run just fine so this seems to be a Feral only issue...

@gulafaran: all feral game issues should be reported directly to support@feralinteractive.com
also feral has made a "sysreport.sh" script for their games: https://github.com/FeralInteractive/ferallinuxscripts

Upstream issue: https://github.com/FeralInteractive/ferallinuxscripts/issues/3
And OpenSuse issue where someone from toolchain team explains that their solution was based on undocumented behavior: https://bugzilla.opensuse.org/show_bug.cgi?id=1056606

Nothing to do here from my perspective. Yes, I could revert the commit that changed the behavior, but it's Feral Interactive that should fix their scripts.

yeah nothing to do from my perspective either, their broken code is broken. atleast the cause and reason is found. and the workaround for their brokeness seems to add the /game/lib/x86_64/ path to LD_LIBRARY_PATH= before running it.

Can you test glibc 2.26-4 from here[1]? I'm about to put it in [testing], but I wait for confirmation from anyone owning affected games.

[1] https://paste.xinu.at/m-vqG/

Works for friend of mine (and also with my poor reproducer in C). Pushed to [testing].

FYI: It seems Feral submited a bug report to opensuse about this, and there is some comments from Feral about being a Glibc regression.

Link with comments from Feral and more information at reddit:
https://www.reddit.com/r/linux_gaming/comments/6zpnci/gol_a_bunch_of_feral_interactive_linux_ports_may/

the glibc 2.26-4 update did work for me, at least with CoH2 and DoW2 & 3