darkradiant Darkradiant Git master compiles but won't start, missing libraries and modules

MirceaKitsune · October 19, 2020

I'm compiling Darkradiant from Git on my Linux machine (openSUSE Tumbleweed x64). I noticed that although latest master compiles successfully, there are some issues with libraries and modules that prevent it from working. I figured I'd make a thread here before opening an entry on the bug tracker. First issue I run into is an instant crash with:

Gtk-Message: 04:58:08.252: Failed to load module "appmenu-gtk-module"
Cannot find the main module in any of the paths: /archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/modules/; /archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/plugins/

It appears I can work around this one by creating a symlink to darkradiant/install/lib64 called darkradiant/install/lib (simply remove the "64" from the name). That seems to get it to start up further, but then I'm met with an error popup leading to another crash:

Quote

ModuleRegistry: Module doesn't exist: ScriptingSystem

Aborted (core dumped)

So something is causing the modules not to be seen. Any idea what the problem might be and how to solve it?

**greebo** · October 19, 2020

What did you pass to ./configure ?

I don't get why there would be two folders used for the module output (lib64 and lib). Is this something specific to openSUSE?

MirceaKitsune · October 19, 2020

13 hours ago, greebo said:

What did you pass to ./configure ?

I don't get why there would be two folders used for the module output (lib64 and lib). Is this something specific to openSUSE?

./autogen.sh
./configure --prefix=/home/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install --enable-darkmod-plugins
make install

It would be odd if something in openSUSE cause the output of the compiled project to be different. This seems like a path issue given I'm not noticing any compilation errors in the console and everything appears to build well. Also I didn't have this issue several months ago but it's been a while since last time I did a "git pull" and recompile.

MirceaKitsune · October 19, 2020

What's also odd is that darkradiant/install/lib64 appears to contain all of the necessary modules and plugins, so why does copying it to lib in order to fix the bad path still cause a crash too?

mircea@linux-qz0r:~> ls -1 -R
.:
darkradiant

./darkradiant:
libmath-2.8.1.so
libmath.la
libmath.so
libmodule-2.8.1.so
libmodule.la
libmodule.so
libscenegraph-2.8.1.so
libscenegraph.la
libscenegraph.so
libwxutil-2.8.1.so
libwxutil.la
libwxutil.so
libxmlutil-2.8.1.so
libxmlutil.la
libxmlutil.so
modules
plugins
scripts

./darkradiant/modules:
libradiantcore.la
libradiantcore.so
script.la
script.so
sound.la
sound.so

./darkradiant/plugins:
dm_conversation.la
dm_conversation.so
dm_difficulty.la
dm_difficulty.so
dm_editing.la
dm_editing.so
dm_gameconnection.la
dm_gameconnection.so
dm_gui.la
dm_gui.so
dm_objectives.la
dm_objectives.so
dm_stimresponse.la
dm_stimresponse.so

./darkradiant/scripts:
brushtest.py
commands
dialogtest.py
init.py
patchtest.py
test.py

./darkradiant/scripts/commands:
ase_export_blend.py
ase_export.py
check_for_invalid_visportals.py
example.py
export_obj.py
patchsplitter.py
select_all_models_of_type.py
shift_textures_randomly.py
shift_textures_upwards_randomly.py
test_targets.py

**greebo** · October 19, 2020

I really don't know why it would put anything into lib64. The Makefile explicitly use $(pkglibdir) which is $(libdir)/$(PACKAGE), i.e. prefix/lib/darkradiant. As far as I read the docs, $(libdir) will always point to lib. If one wants to install something somewhere else, they must explicity change it to lib64 in the configure step.

For the records, this is what I passed to configure:

./configure --enable-darkmod-plugins --enable-debug --prefix=/home/greebo/dr

And this is what my output folder looks after make install:

.:
total 20
drwxrwxr-x  5 greebo greebo 4096 Okt 12 07:20 .
drwxr-xr-x 22 greebo greebo 4096 Okt 18 19:11 ..
drwxrwxr-x  2 greebo greebo 4096 Okt 19 18:39 bin
drwxrwxr-x  3 greebo greebo 4096 Okt 12 07:18 lib
drwxrwxr-x  6 greebo greebo 4096 Okt 12 07:20 share

./bin:
total 199904
drwxrwxr-x 2 greebo greebo      4096 Okt 19 18:39 .
drwxrwxr-x 5 greebo greebo      4096 Okt 12 07:20 ..
-rwxr-xr-x 1 greebo greebo 189595464 Okt 19 18:38 darkradiant
-rwxr-xr-x 1 greebo greebo  15092664 Okt 19 18:39 test

./lib:
total 12
drwxrwxr-x 3 greebo greebo 4096 Okt 12 07:18 .
drwxrwxr-x 5 greebo greebo 4096 Okt 12 07:20 ..
drwxrwxr-x 5 greebo greebo 4096 Okt 19 18:36 darkradiant

./lib/darkradiant:
total 32340
drwxrwxr-x 5 greebo greebo     4096 Okt 19 18:36 .
drwxrwxr-x 3 greebo greebo     4096 Okt 12 07:18 ..
-rwxr-xr-x 1 greebo greebo   627320 Okt 19 18:35 libmath-2.8.1.so
-rwxr-xr-x 1 greebo greebo      959 Okt 19 18:35 libmath.la
lrwxrwxrwx 1 greebo greebo       16 Okt 19 18:35 libmath.so -> libmath-2.8.1.so
-rwxr-xr-x 1 greebo greebo  1586344 Okt 19 18:36 libmodule-2.8.1.so
-rwxr-xr-x 1 greebo greebo      971 Okt 19 18:36 libmodule.la
lrwxrwxrwx 1 greebo greebo       18 Okt 19 18:36 libmodule.so -> libmodule-2.8.1.so
-rwxr-xr-x 1 greebo greebo  5362408 Okt 19 18:35 libscenegraph-2.8.1.so
-rwxr-xr-x 1 greebo greebo     1038 Okt 19 18:35 libscenegraph.la
lrwxrwxrwx 1 greebo greebo       22 Okt 19 18:35 libscenegraph.so -> libscenegraph-2.8.1.so
-rwxr-xr-x 1 greebo greebo 24988960 Okt 19 18:36 libwxutil-2.8.1.so
-rwxr-xr-x 1 greebo greebo     1347 Okt 19 18:36 libwxutil.la
lrwxrwxrwx 1 greebo greebo       18 Okt 19 18:36 libwxutil.so -> libwxutil-2.8.1.so
-rwxr-xr-x 1 greebo greebo   496160 Okt 19 18:35 libxmlutil-2.8.1.so
-rwxr-xr-x 1 greebo greebo      984 Okt 19 18:35 libxmlutil.la
lrwxrwxrwx 1 greebo greebo       19 Okt 19 18:35 libxmlutil.so -> libxmlutil-2.8.1.so
drwxrwxr-x 2 greebo greebo     4096 Okt 19 18:38 modules
drwxrwxr-x 2 greebo greebo     4096 Okt 19 18:39 plugins
drwxrwxr-x 3 greebo greebo     4096 Okt 19 18:39 scripts

./lib/darkradiant/modules:
total 312848
drwxrwxr-x 2 greebo greebo      4096 Okt 19 18:38 .
drwxrwxr-x 5 greebo greebo      4096 Okt 19 18:36 ..
-rwxr-xr-x 1 greebo greebo      1227 Okt 19 18:37 libradiantcore.la
-rwxr-xr-x 1 greebo greebo 233335928 Okt 19 18:37 libradiantcore.so
-rwxr-xr-x 1 greebo greebo      1040 Okt 19 18:38 script.la
-rwxr-xr-x 1 greebo greebo  81371856 Okt 19 18:38 script.so
-rwxr-xr-x 1 greebo greebo      1428 Okt 19 18:38 sound.la
-rwxr-xr-x 1 greebo greebo   5614536 Okt 19 18:38 sound.so

./lib/darkradiant/plugins:
total 144060
drwxrwxr-x 2 greebo greebo     4096 Okt 19 18:39 .
drwxrwxr-x 5 greebo greebo     4096 Okt 19 18:36 ..
-rwxr-xr-x 1 greebo greebo     1419 Okt 19 18:39 dm_conversation.la
-rwxr-xr-x 1 greebo greebo 19617768 Okt 19 18:39 dm_conversation.so
-rwxr-xr-x 1 greebo greebo     1407 Okt 19 18:39 dm_difficulty.la
-rwxr-xr-x 1 greebo greebo  9012616 Okt 19 18:39 dm_difficulty.so
-rwxr-xr-x 1 greebo greebo     1389 Okt 19 18:39 dm_editing.la
-rwxr-xr-x 1 greebo greebo 26450048 Okt 19 18:39 dm_editing.so
-rwxr-xr-x 1 greebo greebo     1431 Okt 19 18:39 dm_gameconnection.la
-rwxr-xr-x 1 greebo greebo  5348320 Okt 19 18:39 dm_gameconnection.so
-rwxr-xr-x 1 greebo greebo     1375 Okt 19 18:39 dm_gui.la
-rwxr-xr-x 1 greebo greebo 26281224 Okt 19 18:39 dm_gui.so
-rwxr-xr-x 1 greebo greebo     1407 Okt 19 18:39 dm_objectives.la
-rwxr-xr-x 1 greebo greebo 36205552 Okt 19 18:39 dm_objectives.so
-rwxr-xr-x 1 greebo greebo     1419 Okt 19 18:38 dm_stimresponse.la
-rwxr-xr-x 1 greebo greebo 24545328 Okt 19 18:38 dm_stimresponse.so

./lib/darkradiant/scripts:
total 40
drwxrwxr-x 3 greebo greebo 4096 Okt 19 18:39 .
drwxrwxr-x 5 greebo greebo 4096 Okt 19 18:36 ..
-rw-r--r-- 1 greebo greebo  712 Okt 19 18:39 brushtest.py
drwxrwxr-x 2 greebo greebo 4096 Okt 19 18:39 commands
-rw-r--r-- 1 greebo greebo  760 Okt 19 18:39 dialogtest.py
-rw-r--r-- 1 greebo greebo  118 Okt 19 18:39 init.py
-rw-r--r-- 1 greebo greebo  620 Okt 19 18:39 patchtest.py
-rw-r--r-- 1 greebo greebo 8652 Okt 19 18:39 test.py

./lib/darkradiant/scripts/commands:
total 96
drwxrwxr-x 2 greebo greebo  4096 Okt 19 18:39 .
drwxrwxr-x 3 greebo greebo  4096 Okt 19 18:39 ..
-rw-r--r-- 1 greebo greebo 18148 Okt 19 18:39 ase_export_blend.py
-rw-r--r-- 1 greebo greebo 15674 Okt 19 18:39 ase_export.py
-rw-r--r-- 1 greebo greebo  3021 Okt 19 18:39 check_for_invalid_visportals.py
-rw-r--r-- 1 greebo greebo   800 Okt 19 18:39 example.py
-rw-r--r-- 1 greebo greebo 11559 Okt 19 18:39 export_obj.py
-rw-r--r-- 1 greebo greebo 12457 Okt 19 18:39 patchsplitter.py
-rw-r--r-- 1 greebo greebo  1498 Okt 19 18:39 select_all_models_of_type.py
-rw-r--r-- 1 greebo greebo   713 Okt 19 18:39 shift_textures_randomly.py
-rw-r--r-- 1 greebo greebo   586 Okt 19 18:39 shift_textures_upwards_randomly.py
-rw-r--r-- 1 greebo greebo  2500 Okt 19 18:39 test_targets.py

./share:
total 24
drwxrwxr-x 6 greebo greebo 4096 Okt 12 07:20 .
drwxrwxr-x 5 greebo greebo 4096 Okt 12 07:20 ..
drwxrwxr-x 2 greebo greebo 4096 Okt 19 18:39 applications
drwxrwxr-x 6 greebo greebo 4096 Okt 19 18:39 darkradiant
drwxrwxr-x 3 greebo greebo 4096 Okt 12 07:20 doc
drwxrwxr-x 3 greebo greebo 4096 Okt 12 07:20 locale

./share/applications:
total 12
drwxrwxr-x 2 greebo greebo 4096 Okt 19 18:39 .
drwxrwxr-x 6 greebo greebo 4096 Okt 12 07:20 ..
-rw-r--r-- 1 greebo greebo  566 Okt 19 18:39 darkradiant.desktop

./share/darkradiant:
total 108
drwxrwxr-x 6 greebo greebo  4096 Okt 19 18:39 .
drwxrwxr-x 6 greebo greebo  4096 Okt 12 07:20 ..
drwxrwxr-x 2 greebo greebo 12288 Okt 19 18:39 bitmaps
-rw-r--r-- 1 greebo greebo 10232 Okt 19 18:39 colours.xml
-rw-r--r-- 1 greebo greebo  6537 Okt 19 18:39 commandsystem.xml
-rw-r--r-- 1 greebo greebo  2732 Okt 19 18:39 debug.xml
drwxrwxr-x 2 greebo greebo  4096 Okt 19 18:39 games
drwxrwxr-x 2 greebo greebo  4096 Okt 19 18:39 gl
-rw-r--r-- 1 greebo greebo 12738 Okt 19 18:39 input.xml
-rw-r--r-- 1 greebo greebo 19778 Okt 19 18:39 menu.xml
drwxrwxr-x 3 greebo greebo  4096 Okt 19 18:39 ui
-rw-r--r-- 1 greebo greebo 15099 Okt 19 18:39 user.xml

./share/darkradiant/bitmaps:
total 1832
drwxrwxr-x 2 greebo greebo  12288 Okt 19 18:39 .
drwxrwxr-x 6 greebo greebo   4096 Okt 19 18:39 ..
-rw-r--r-- 1 greebo greebo    303 Okt 19 18:39 active_layer_invisible.png
...
-rw-r--r-- 1 greebo greebo    548 Okt 19 18:39 wireframe.png

./share/darkradiant/games:
total 108
drwxrwxr-x 2 greebo greebo  4096 Okt 19 18:39 .
drwxrwxr-x 6 greebo greebo  4096 Okt 19 18:39 ..
-rw-r--r-- 1 greebo greebo 14660 Okt 19 18:39 darkmod.game
-rw-r--r-- 1 greebo greebo 13562 Okt 19 18:39 doom3-demo.game
-rw-r--r-- 1 greebo greebo 13925 Okt 19 18:39 doom3.game
-rw-r--r-- 1 greebo greebo  9841 Okt 19 18:39 prey.game
-rw-r--r-- 1 greebo greebo  9772 Okt 19 18:39 quake3.game
-rw-r--r-- 1 greebo greebo  9863 Okt 19 18:39 quake4.game
-rw-r--r-- 1 greebo greebo 13846 Okt 19 18:39 xreal.game

./share/darkradiant/gl:
total 24
drwxrwxr-x 2 greebo greebo 4096 Okt 19 18:39 .
drwxrwxr-x 6 greebo greebo 4096 Okt 19 18:39 ..
-rw-r--r-- 1 greebo greebo 3258 Okt 19 18:39 interaction_fp.glsl
-rw-r--r-- 1 greebo greebo 2248 Okt 19 18:39 interaction_vp.glsl
-rw-r--r-- 1 greebo greebo 1080 Okt 19 18:39 zfill_fp.glsl
-rw-r--r-- 1 greebo greebo 1264 Okt 19 18:39 zfill_vp.glsl

./share/darkradiant/ui:
total 356
drwxrwxr-x 3 greebo greebo   4096 Okt 19 18:39 .
drwxrwxr-x 6 greebo greebo   4096 Okt 19 18:39 ..
-rw-r--r-- 1 greebo greebo   5072 Okt 19 18:39 aboutdialog.xrc
...
-rw-r--r-- 1 greebo greebo  31081 Okt 19 18:39 stimresponseeditor.xrc

./share/darkradiant/ui/fonts:
total 1044
drwxrwxr-x 2 greebo greebo   4096 Okt 19 18:39 .
drwxrwxr-x 3 greebo greebo   4096 Okt 19 18:39 ..
-rw-r--r-- 1 greebo greebo 343980 Okt 19 18:39 FreeMono.ttf
-rw-r--r-- 1 greebo greebo 714456 Okt 19 18:39 FreeSans.ttf

./share/doc:
total 12
drwxrwxr-x 3 greebo greebo 4096 Okt 12 07:20 .
drwxrwxr-x 6 greebo greebo 4096 Okt 12 07:20 ..
drwxrwxr-x 3 greebo greebo 4096 Okt 19 18:39 darkradiant

./share/doc/darkradiant:
total 188
drwxrwxr-x 3 greebo greebo   4096 Okt 19 18:39 .
drwxrwxr-x 3 greebo greebo   4096 Okt 12 07:20 ..
drwxrwxr-x 2 greebo greebo   4096 Okt 19 18:39 img
-rw-r--r-- 1 greebo greebo 179835 Okt 19 18:39 manual.html

./share/doc/darkradiant/img:
total 2248
drwxrwxr-x 2 greebo greebo   4096 Okt 19 18:39 .
drwxrwxr-x 3 greebo greebo   4096 Okt 19 18:39 ..
-rw-r--r-- 1 greebo greebo 134067 Okt 19 18:39 2DViewMarkedUp.png
...
-rw-r--r-- 1 greebo greebo   2832 Okt 19 18:39 warning.png
-rw-r--r-- 1 greebo greebo    269 Okt 19 18:39 wireframeMode16.png

./share/locale:
total 12
drwxrwxr-x 3 greebo greebo 4096 Okt 12 07:20 .
drwxrwxr-x 6 greebo greebo 4096 Okt 12 07:20 ..
drwxrwxr-x 3 greebo greebo 4096 Okt 12 07:20 de

./share/locale/de:
total 12
drwxrwxr-x 3 greebo greebo 4096 Okt 12 07:20 .
drwxrwxr-x 3 greebo greebo 4096 Okt 12 07:20 ..
drwxrwxr-x 2 greebo greebo 4096 Okt 19 18:39 LC_MESSAGES

./share/locale/de/LC_MESSAGES:
total 116
drwxrwxr-x 2 greebo greebo   4096 Okt 19 18:39 .
drwxrwxr-x 3 greebo greebo   4096 Okt 12 07:20 ..
-rw-r--r-- 1 greebo greebo 108262 Okt 19 18:39 darkradiant.mo

edit: I don't seem to be able to put a scrollbar around the quote above. I could swear the forum did that automatically before.

Edited October 19, 2020 by greebo
wth

MirceaKitsune · October 19, 2020

What do you recommend trying next? Like I said the issue isn't just the lib64 versus lib directory naming, which I can work around by symlinking lib64 to lib: I still get a crash afterward too, with a complaint that the ScriptingSystem module is missing. Why would that be?

**greebo** · October 19, 2020

DarkRadiant will try to load the modules from certain folders, not sure if the symlink alone will cut it.

Except for reading your log files, there's not much I can do at this point. If you can post your config.log and upload the output of make -n, then maybe I can spot something.

MirceaKitsune · October 19, 2020

13 minutes ago, greebo said:

DarkRadiant will try to load the modules from certain folders, not sure if the symlink alone will cut it.

Except for reading your log files, there's not much I can do at this point. If you can post your config.log and upload the output of make -n, then maybe I can spot something.

config.log: https://pastebin.com/XGJPgC6w

make -n: https://pastebin.com/aiGcMNm3

MirceaKitsune · October 19, 2020

Compiling with --enable-debug I can see a few extra messages which might explain the ScriptingSystem error (lib64 -> lib symlink present):

Gtk-Message: 00:01:30.237: Failed to load module "appmenu-gtk-module"
ModuleLoader: loading modules from /archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/modules/
ModuleLoader: Loading module '/archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/modules/sound.so'
ModuleLoader: Loading module '/archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/modules/script.so'
Error opening library: /archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/modules/script.so: undefined symbol: PyExc_ValueError
ModuleLoader: Loading module '/archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/modules/libradiantcore.so'
/archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/modules/libradiantcore.so: undefined symbol: RegisterModule
ModuleLoader: loading modules from /archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/plugins/
ModuleLoader: Loading module '/archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/plugins/dm_stimresponse.so'
ModuleLoader: Loading module '/archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/plugins/dm_difficulty.so'
ModuleLoader: Loading module '/archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/plugins/dm_gui.so'
ModuleLoader: Loading module '/archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/plugins/dm_editing.so'
ModuleLoader: Loading module '/archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/plugins/dm_gameconnection.so'
ModuleLoader: Loading module '/archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/plugins/dm_objectives.so'
ModuleLoader: Loading module '/archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../lib/darkradiant/plugins/dm_conversation.so'
XMLRegistry: looking for XML files in /archive/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install/bin/../share/darkradiant/
[filters] Loaded 16 filters from registry.
Exception initialising modules: ModuleRegistry: Module doesn't exist: ScriptingSystem
[skins] in tdm_epi_skins.skin: skin steam_engine_003_off previously defined in steam_engine_003.skin!
[skins] in tdm_epi_skins.skin: skin steam_engine_003_on previously defined in steam_engine_003.skin!
Aborted (core dumped)

The block appears to happen when it reaches a certain "undefined symbol: PyExc_ValueError" in modules/script.so. Then there seems to be a similar error about "undefined symbol: RegisterModule" in modules/libradiantcore.so. It seems to only be those two undefined symbols... afterward the ScriptingSystem module is most likely seen as non-existent because script.so never loaded over that error.

OrbWeaver · October 20, 2020

Forgive the possibly obvious question, but did you make sure to clear the install path before building and installing DarkRadiant, to ensure there aren't any stale libraries or modules?

None of this really makes sense, to be honest. As Greebo correctly points out, the DarkRadiant build scripts are not supposed to require or create a lib64 directory, and the use of relative paths (e.g. install/bin/../lib/darkradiant/modules/sound.so) should only happen if you enable the "relocatable build" configure option which is disabled by default.

What happens if you try a fresh, clean checkout in another location, perhaps installing to a completely different destination directory (e.g. /tmp/dr which is what I use for testing)?

MirceaKitsune · October 20, 2020

3 hours ago, OrbWeaver said:

Forgive the possibly obvious question, but did you make sure to clear the install path before building and installing DarkRadiant, to ensure there aren't any stale libraries or modules?

None of this really makes sense, to be honest. As Greebo correctly points out, the DarkRadiant build scripts are not supposed to require or create a lib64 directory, and the use of relative paths (e.g. install/bin/../lib/darkradiant/modules/sound.so) should only happen if you enable the "relocatable build" configure option which is disabled by default.

What happens if you try a fresh, clean checkout in another location, perhaps installing to a completely different destination directory (e.g. /tmp/dr which is what I use for testing)?

I use "git clean -dfx" before each "git pull" which should erase all files in the darkradiant directory that aren't part of the repository. I might try that experiment as well just to be extra sure. Can you recommend any options I can pass to the configure script to ensure no default or undesired options are accidentally modified and the proper values are forced?

Edit: Did a clean checkout with an install to /tmp/dr as suggested. Exact same issue and results.

./autogen.sh
./configure --prefix=/tmp/dr --enable-debug --enable-darkmod-plugins
make install

Without the lib64 to lib symlink:

mircea@linux-qz0r:/tmp/dr/bin> ./darkradiant
Gtk-Message: 17:44:07.735: Failed to load module "appmenu-gtk-module"
Cannot find the main module in any of the paths: /tmp/dr/bin/../lib/darkradiant/modules/; /tmp/dr/bin/../lib/darkradiant/plugins/
darkradiant: StaticModule.cpp:15: module::internal::StaticModuleList::~StaticModuleList(): Assertion `empty()' failed.
Aborted (core dumped)

With the symlink:

mircea@linux-qz0r:/tmp/dr/bin> ./darkradiant
Gtk-Message: 17:44:36.681: Failed to load module "appmenu-gtk-module"
ModuleLoader: loading modules from /tmp/dr/bin/../lib/darkradiant/modules/
ModuleLoader: Loading module '/tmp/dr/bin/../lib/darkradiant/modules/script.so'
Error opening library: /tmp/dr/bin/../lib/darkradiant/modules/script.so: undefined symbol: PyExc_ValueError
ModuleLoader: Loading module '/tmp/dr/bin/../lib/darkradiant/modules/sound.so'
ModuleLoader: Loading module '/tmp/dr/bin/../lib/darkradiant/modules/libradiantcore.so'
/tmp/dr/bin/../lib/darkradiant/modules/libradiantcore.so: undefined symbol: RegisterModule
ModuleLoader: loading modules from /tmp/dr/bin/../lib/darkradiant/plugins/
ModuleLoader: Loading module '/tmp/dr/bin/../lib/darkradiant/plugins/dm_gameconnection.so'
ModuleLoader: Loading module '/tmp/dr/bin/../lib/darkradiant/plugins/dm_editing.so'
ModuleLoader: Loading module '/tmp/dr/bin/../lib/darkradiant/plugins/dm_gui.so'
ModuleLoader: Loading module '/tmp/dr/bin/../lib/darkradiant/plugins/dm_conversation.so'
ModuleLoader: Loading module '/tmp/dr/bin/../lib/darkradiant/plugins/dm_difficulty.so'
ModuleLoader: Loading module '/tmp/dr/bin/../lib/darkradiant/plugins/dm_objectives.so'
ModuleLoader: Loading module '/tmp/dr/bin/../lib/darkradiant/plugins/dm_stimresponse.so'
XMLRegistry: looking for XML files in /tmp/dr/bin/../share/darkradiant/
[filters] Loaded 16 filters from registry.
Exception initialising modules: ModuleRegistry: Module doesn't exist: ScriptingSystem
[skins] in tdm_epi_skins.skin: skin steam_engine_003_off previously defined in steam_engine_003.skin!
[skins] in tdm_epi_skins.skin: skin steam_engine_003_on previously defined in steam_engine_003.skin!
Aborted (core dumped)

Edited October 20, 2020 by MirceaKitsune
Tested

**greebo** · October 20, 2020

The config.log gives some insight in the make install behaviour you see on your system:

Quote

...
configure:2441: loading site script /usr/share/site/x86_64-unknown-linux-gnu
...
| # If user did not specify libdir, guess the correct target:
| # Use lib64 for 64 bit bi-arch targets, keep the default for the rest.
...
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d --enable-offload-targets=nvptx-none=/usr/nvptx-none,amdgcn-amdhsa=/usr/amdgcn-amdhsa, --without-cuda-driver --enable-checking=release --disable-werror --with-gxx-include-dir=/usr/include/c++/10 --enable-ssp --disable-libssp --disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin --with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-libphobos --enable-version-specific-runtime-libs --with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex --enable-gnu-indirect-function --program-suffix=-10 --without-system-libunwind --enable-multilib --with-arch-32=x86-64 --with-tune=generic --with-build-config=bootstrap-lto-lean --enable-link-mutex --build=x86_64-suse-linux --host=x86_64-suse-linux

...
install_sh='${SHELL} /home/mircea/Games/Quake/TheDarkMod/DarkRadiant_GIT/install-sh'
libdir='${exec_prefix}/lib64'
libexecdir='${exec_prefix}/lib'

You might have some system-wide settings kicking in here, installing stuff in /lib64 by default. It might be due to the system set up as "x64 bi-arch" whatever that means.

Which distribution did you originally pick for setting up that system? Do you recall changing anything in terms of 64/32 bit support, or is this some kind of openSUSE default?

MirceaKitsune · October 20, 2020

1 hour ago, greebo said:

The config.log gives some insight in the make install behaviour you see on your system:

You might have some system-wide settings kicking in here, installing stuff in /lib64 by default. It might be due to the system set up as "x64 bi-arch" whatever that means.

Which distribution did you originally pick for setting up that system? Do you recall changing anything in terms of 64/32 bit support, or is this some kind of openSUSE default?

I only use openSUSE Tumbleweed x64 for years, freshly installed from original image roughly an year ago. Darkradiant compiled and ran just fine on it a few months ago, whatever happens must have been introduced relatively recently. Here are the contents of /usr/share/site/x86_64-unknown-linux-gnu too if it helps:

#!/bin/sh
# Site script for configure. It is resourced via $CONFIG_SITE environment varaible.

# If user did not specify libdir, guess the correct target:
# Use lib64 for 64 bit bi-arch targets, keep the default for the rest.
if test "$libdir" = '${exec_prefix}/lib' ; then

	ac_config_site_64bit_host=NONE

	case "$host" in
	"" )
		# User did not specify host target.
		# The native platform x86_64 is a bi-arch platform.
		# Try to detect cross-compilation to inferior architecture.

		# We are trying to guess 32-bit target compilation. It's not as easy as
		# it sounds, as there is possible several intermediate combinations.
		ac_config_site_cross_to_32bit_host=NONE

		# User defined -m32 in CFLAGS or CXXFLAGS or CC or CXX:
		# (It's sufficient for 32-bit, but alone may cause mis-behavior of some checks.)
		case "$CFLAGS $CXXFLAGS $CC $CXX" in
		*-m32*)
			ac_config_site_cross_to_32bit_host=YES
			;;
		esac

		# Running with linux32:
		# (Changes detected platform, but not the toolchain target.)
		case "`/bin/uname -i`" in
		x86_64 | ppc64 | s390x | aarch64 )
			;;
		* )
			ac_config_site_cross_to_32bit_host=YES
			;;
		esac

		if test "x$ac_config_site_cross_to_32bit_host" = xNONE; then
			ac_config_site_64bit_host=YES
		fi

		;;
	*x86_64* | *ppc64* | *s390x* | *aarch64* )
		ac_config_site_64bit_host=YES
		;;
	esac

	if test "x$ac_config_site_64bit_host" = xYES; then
		libdir='${exec_prefix}/lib64'
	fi
fi

# If user did not specify libexecdir, set the correct target:
# Nor FHS nor openSUSE allow prefix/libexec. Let's default to prefix/lib.

if test "$libexecdir" = '${exec_prefix}/libexec' ; then
	libexecdir='${exec_prefix}/lib'
fi

# Continue with the standard behavior of configure defined in AC_SITE_LOAD:
if test "x$prefix" != xNONE; then
	ac_site_file1=$prefix/share/config.site
	ac_site_file2=$prefix/etc/config.site
else
	ac_site_file1=$ac_default_prefix/share/config.site
	ac_site_file2=$ac_default_prefix/etc/config.site
fi
for ac_site_file in "$ac_site_file1" "$ac_site_file2"
do
	test "x$ac_site_file" = xNONE && continue
	if test /dev/null != "$ac_site_file" && test -r "$ac_site_file"; then
		{ $as_echo "/usr/share/site/x86_64-unknown-linux-gnu:${as_lineno-$LINENO}: loading site script $ac_site_file" >&5
$as_echo "/usr/share/site/x86_64-unknown-linux-gnu: loading site script $ac_site_file" >&6;}
		sed 's/^/| /' "$ac_site_file" >&5
		. "$ac_site_file" \
			|| { { $as_echo "/usr/share/site/x86_64-unknown-linux-gnu:${as_lineno-$LINENO}: error: in \`$ac_pwd':" >&5
$as_echo "/usr/share/site/x86_64-unknown-linux-gnu: error: in \`$ac_pwd':" >&2;}
as_fn_error $? "failed to load site script $ac_site_file
See \`config.log' for more details" "$LINENO" 5; }
	fi
done

Do you think the wrong target is being compiled? The biggest problem is the undefined symbol errors, I have no idea what may cause those.

Edited October 20, 2020 by MirceaKitsune

**greebo** · October 20, 2020

The script.so symbol issue is a linker problem. This might be related to the changes I made to better detect Python3 (committed on Oct 12th), but whatever it links to (Python2 or Python3), it should work nonetheless. The config.log reveals a problem related to the Python-detection:

Quote



configure:21970: checking for python3
configure:21988: found /usr/bin/python3
configure:22000: result: /usr/bin/python3
configure:22019: checking if Python >= '3.0.0'
configure:22056: chmod +x conftest.py && cp conftest.py conftest >&5
configure:22056: $? = 0
configure:22056: ./conftest
configure:22056: $? = 0
configure:22072: result: yes
configure:22130: checking for python3-config
configure:22163: result: no
configure:22130: checking for python-config
configure:22148: found /usr/bin/python-config
configure:22160: result: /usr/bin/python-config
configure:22203: checking if Python >= '3.8.0'
configure:22240: chmod +x conftest.py && cp conftest.py conftest >&5
configure:22240: $? = 0
configure:22240: ./conftest
configure:22240: $? = 0
configure:22256: result: yes
configure:22276: Checking for pybind11 headers...
configure:22282: checking pybind11/pybind11.h usability
configure:22282: g++ -std=c++11 -std=c++17 -c -g -O2 -I/boost/ -I/usr/include/python2.7 -I/usr/include/python2.7  conftest.cpp >&5

So it seems your system has a /usr/bin/python3 executable, but no python3-config. Instead it has a python-config, which obviously is configured for Python2, since it returns include folders /usr/include/python2.7. All that indicates that you have a python-dev package installed (for Python2), but no python3-dev package (which would be needed for linking against Python3). Can you try installing the python3 dev package?

I should maybe rethink the configure.ac checks. They are using the python.m4 macros, which are checking for /usr/bin/python3 first, but this in the end doesn't tell us anything about the presence of a python3-config or about any default python development package version. Not sure what to do here, but the logic needs improvement.

And as for the whole lib64 vs lib business - I clearly lack the knowledge of those libexec and lib defaults, and I don't have a clue how this is related to any of our configure scripts. If this is a default distro, I might be able to set one up myself in a VM to see what it's doing.

MirceaKitsune · October 20, 2020

33 minutes ago, greebo said:

The script.so symbol issue is a linker problem. This might be related to the changes I made to better detect Python3 (committed on Oct 12th), but whatever it links to (Python2 or Python3), it should work nonetheless. The config.log reveals a problem related to the Python-detection:

So it seems your system has a /usr/bin/python3 executable, but no python3-config. Instead it has a python-config, which obviously is configured for Python2, since it returns include folders /usr/include/python2.7. All that indicates that you have a python-dev package installed (for Python2), but no python3-dev package (which would be needed for linking against Python3). Can you try installing the python3 dev package?

I should maybe rethink the configure.ac checks. They are using the python.m4 macros, which are checking for /usr/bin/python3 first, but this in the end doesn't tell us anything about the presence of a python3-config or about any default python development package version. Not sure what to do here, but the logic needs improvement.

And as for the whole lib64 vs lib business - I clearly lack the knowledge of those libexec and lib defaults, and I don't have a clue how this is related to any of our configure scripts. If this is a default distro, I might be able to set one up myself in a VM to see what it's doing.

I suspected a Python issue may be involved as well. To test this I tried:

./configure --prefix=/home/mircea/Downloads/DarkRadiant/install/ --enable-debug --enable-relocation --disable-python --enable-darkmod-plugins

This removes the Python related symbol error, however the RegisterModule one remains. DR still fails to start with the same complaint about no ScriptingSystem module, whether due to that remaining missing symbol or some other reason not shown in the logs.

mircea@linux-qz0r:~/Downloads/DarkRadiant/install/bin> ./darkradiant
Gtk-Message: 22:39:25.363: Failed to load module "appmenu-gtk-module"
ModuleLoader: loading modules from /archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/modules/
ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/modules/sound.so'
ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/modules/libradiantcore.so'
/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/modules/libradiantcore.so: undefined symbol: RegisterModule
ModuleLoader: loading modules from /archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/
ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_stimresponse.so'
ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_difficulty.so'
ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_gui.so'
ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_editing.so'
ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_gameconnection.so'
ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_objectives.so'
ModuleLoader: Loading module '/archive/mircea/Downloads/DarkRadiant/install/bin/../lib/darkradiant/plugins/dm_conversation.so'
XMLRegistry: looking for XML files in /archive/mircea/Downloads/DarkRadiant/install/bin/../share/darkradiant/
[filters] Loaded 16 filters from registry.
Exception initialising modules: ModuleRegistry: Module doesn't exist: ScriptingSystem
[skins] in tdm_epi_skins.skin: skin steam_engine_003_off previously defined in steam_engine_003.skin!
[skins] in tdm_epi_skins.skin: skin steam_engine_003_on previously defined in steam_engine_003.skin!
Aborted (core dumped)

I have the python-devel package installed, however that refers to version 2.7... there should be a python3-devel but for some reason it's not showing up for me, I will investigate. As for openSUSE Tumbleweed it's easy to download and install the latest snapshot (x86_64 DVD image): https://software.opensuse.org/distributions/tumbleweed

Edited October 20, 2020 by MirceaKitsune

MirceaKitsune · October 20, 2020

Some good news: It seems I got DarkRadiant to work again! The issue was apparently Python related after all: I needed to install the package python38-devel which was missing from my packages. Upon doing so and reconfiguring / recompiling, DR will now start up successfully.

It does however still require symlinking lib64 to lib, everything is still placed in the lib64 directory incorrectly. I can live with this workaround in the meantime, but it would be nice if a solution can be found for this minor annoyance as well. Let me know if I can provide more info to help with this aspect.

**greebo** · October 21, 2020

Yes. I'm going to check it out sometime, I need to set up that distro first.

Glad you could work around it though. I might come back to this topic once I have something to test for you.

OrbWeaver · October 21, 2020

Do you have a CONFIG_SITE environment variable set? As far as I can see from the documentation, this is the only way that DarkRadiant's configure script should be reading the contents of /usr/share/site/x86_64-unknown-linux-gnu or any other site-specific script.

**greebo** · October 24, 2020

I committed a change to my master branch, which defines the PKGLIBDIR symbols when compiling the static module lib, something that likely caused the problems for you. Can you please try to check out that change, but be sure to call make clean before you run ./autogen.sh, configure and make.

MirceaKitsune · November 4, 2020

Now that I safely finished working on my FM I did a "git pull" and gave this another try. The latest master branch appears to fix this issue: The directory is still called lib64, which IMO is correct for a 64bit system so that's the expected outcome... DR no longer attempts to look in lib as well however, so everything seems to work fine and this issue is fixed.

**greebo** · November 7, 2020

Thanks for the confirmation, closing #5366

darkradiant Darkradiant Git master compiles but won't start, missing libraries and modules

Recommended Posts

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Link to comment

Share on other sites

Join the conversation

Recent Status Updates