Jump to content
The Dark Mod Forums

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


Recommended Posts

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

 

Link to comment
Share on other sites

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 by greebo
wth
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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)?

Link to comment
Share on other sites

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 by MirceaKitsune
Tested
Link to comment
Share on other sites

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?

Link to comment
Share on other sites

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 by MirceaKitsune
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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 by MirceaKitsune
Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

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.

Link to comment
Share on other sites

  • 2 weeks later...

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.

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recent Status Updates

    • Ansome

      Finally got my PC back from the shop after my SSD got corrupted a week ago and damaged my motherboard. Scary stuff, but thank goodness it happened right after two months of FM development instead of wiping all my work before I could release it. New SSD, repaired Motherboard and BIOS, and we're ready to start working on my second FM with some added version control in the cloud just to be safe!
      · 0 replies
    • Petike the Taffer  »  DeTeEff

      I've updated the articles for your FMs and your author category at the wiki. Your newer nickname (DeTeEff) now comes first, and the one in parentheses is your older nickname (Fieldmedic). Just to avoid confusing people who played your FMs years ago and remember your older nickname. I've added a wiki article for your latest FM, Who Watches the Watcher?, as part of my current updating efforts. Unless I overlooked something, you have five different FMs so far.
      · 0 replies
    • Petike the Taffer

      I've finally managed to log in to The Dark Mod Wiki. I'm back in the saddle and before the holidays start in full, I'll be adding a few new FM articles and doing other updates. Written in Stone is already done.
      · 4 replies
    • nbohr1more

      TDM 15th Anniversary Contest is now active! Please declare your participation: https://forums.thedarkmod.com/index.php?/topic/22413-the-dark-mod-15th-anniversary-contest-entry-thread/
       
      · 0 replies
    • JackFarmer

      @TheUnbeholden
      You cannot receive PMs. Could you please be so kind and check your mailbox if it is full (or maybe you switched off the function)?
      · 1 reply
×
×
  • Create New...