Jump to content
The Dark Mod Forums

DarkRadiant 2.10.0 pre-release test


Recommended Posts

14 hours ago, HeresJonny said:

I've noticed that the python scripts are no longer found (on Linux at least, it might be fine on Windows):

I see the problem. This was actually working when I first switched to CMake because PKGLIBDIR wasn't defined, so it would default to the runtime data path (/usr/share/darkradiant) + scripts using the same logic as on Windows.

I've fixed this to always use ApplicationContext::getRuntimeDataPath which should work correctly on both Windows and Linux, and already takes into account whether it is a relocatable build or one using hard-coded absolute paths.

Link to post
Share on other sites
5 hours ago, IZaRTaX said:

Png 16 bits is no longer supported in 2.10.0 everytime you try to open it causes Radiant crash only 8 bits working 🙁.

Can you open an issue report and attach a small example file, please?

Link to post
Share on other sites

I successfully built DR (so fast now with cmake!), after a minor issue which I may have not fixed properly. But now I get a symbol lookup error when trying to launch DR.

DR had finished building 100%, but stated having two errors.

  •  When first building DR, I got an error at about 89% finished with /home/john/Desktop/DarkRadiant/FileOverwriteConfirmationHandler.h on line #34, complaining of an undeclared '_'
  • The second error was with another file which was referring to the file in the first error.

The original line #34 was as follows:

            msg.hasTitle() ? msg.getTitle() : _("Confirm overwrite"),

Not knowing WTF I am doing, but feeling adventurous, I deleted the underscore. DR then built with no errors.

I have no idea if this is related to my edit, but I get the following error when launching DR when it was built with wxgtk 3.0:

darkradiant: symbol lookup error: darkradiant: undefined symbol: _ZN6wxutil27EV_FSVIEW_SELECTION_CHANGEDE

And when having been built with wxgtk 3.1:

darkradiant: symbol lookup error: darkradiant: undefined symbol: _ZN12wxWindowBase19SetVirtualSizeHintsEiiii, version WXU_3.1

 

Edited by PranQster

System: Mageia Linux Cauldron, aka Mageia 8

Link to post
Share on other sites

I haven't checked the Linux build for a few days... I guess the CMakeLists need to be tweaked to include the latest changes. And the "i18n.h" needs to be included to fix the underscore error.

Link to post
Share on other sites

I added two commits fixing the compilation in Mageia. I built DR with

>> cmake . -DCMAKE_INSTALL_PREFIX=/home/greebo/dr
>> make
>> make install

With that DR still fails to startup with a linker error:

>> ./darkradiant: error while loading shared libraries: libwxutil.so: cannot open shared object file: No such file or directory

LDD shows me this:

ldd ~/dr/bin/darkradiant
        linux-vdso.so.1 (0x00007ffc233b1000)
        libwxutil.so => not found
        libxmlutil.so => not found
        libxml2.so.2 => /lib64/libxml2.so.2 (0x00007fd80d80d000)
        libscenegraph.so => not found
        libmath.so => not found

        libwx_baseu-3.0.so.0 => /lib64/libwx_baseu-3.0.so.0 (0x00007fd80d596000)
        libwx_gtk3u_core-3.0.so.0 => /lib64/libwx_gtk3u_core-3.0.so.0 (0x00007fd80cf53000)
        libwx_gtk3u_stc-3.0.so.0 => /lib64/libwx_gtk3u_stc-3.0.so.0 (0x00007fd80cd46000)

The files are present in the installation target, in the lib64 folder:

ls -l ~/dr/lib64/darkradiant/
        total 2156
        -rwxr-xr-x 1 greebo greebo   56240 Dec 20 06:00 libmath.so*
        -rwxr-xr-x 1 greebo greebo  287352 Dec 20 06:00 libscenegraph.so*
        -rwxr-xr-x 1 greebo greebo 1794056 Dec 20 06:03 libwxutil.so*
        -rwxr-xr-x 1 greebo greebo   52072 Dec 20 06:00 libxmlutil.so*
        drwxr-xr-x 2 greebo greebo    4096 Dec 20 06:33 modules/
        drwxr-xr-x 2 greebo greebo    4096 Dec 20 06:33 plugins/

I seem to have ENABLE_RELOCATION defined in my config.h. Should this be the default?

edit: recompiling with -DENABLE_RELOCATION=OFF

edit2: yes, that fixed it, DR is starting now.

Link to post
Share on other sites
14 hours ago, greebo said:

The files are present in the installation target, in the lib64 folder:

I think you've run into the same problem that MirceaKitsune had: CMake installing things into lib64 whereas the relative rpath baked into the binary expects lib. I'm hoping it's fixed in my latest master.

Quote

I seem to have ENABLE_RELOCATION defined in my config.h. Should this be the default?

I'm open to suggestions regarding which should be the default. Both options should work seamlessly in most situations (at least once the currently-reported problems are fixed) and the average user probably won't notice or care much about the difference, but there are edge cases where each one would be more appropriate.

ENABLE_RELOCATION=ON will build something more like the Windows build, which can be installed into a directory anywhere and moved around without problems. However, I suspect most Linux users don't generally move around software they have built from source, so this benefit isn't so important. Perhaps it is useful if somebody does a test build in /tmp/dr then decides they want to keep it and move the directory to /opt/darkradiant-2.10 or something.

ENABLE_RELOCATION=OFF will build the more usual legacy Linux software where paths are built into the binary: libraries in /usr/lib (or /usr/lib64 or /usr/lib/x86_64-linux-gnu depending on distro), resources in /usr/share, etc. Once built, these locations cannot be changed or the software won't work. I think the only specific advantage of this approach is that there is no assumed relationship between the binary and its resources: you could if you so wished have the binary in /usr/local/bin and the libraries in /weird/mystupidlibraries/darkradiant and it would all work fine, but I can't imagine there are many configurations in which this would be needed.

Link to post
Share on other sites

Success in Mageia after using -DENABLE_RELOCATION=OFF when using wxgtk 3.0.

Gonna see what happens with wxgtk 3.1... which gives the same error as before when launching DR. So back to 3.0 :)

Edited by PranQster

System: Mageia Linux Cauldron, aka Mageia 8

Link to post
Share on other sites
8 hours ago, OrbWeaver said:

I'm open to suggestions regarding which should be the default. Both options should work seamlessly in most situations (at least once the currently-reported problems are fixed) and the average user probably won't notice or care much about the difference, but there are edge cases where each one would be more appropriate.

I think I'm rather leaning towards leaving it ON then, sounds like it's more flexible. I'll check out if it work with the newest fixes.

edit: worked!

Link to post
Share on other sites
On 12/15/2020 at 6:12 PM, peter_spy said:

No love for this one, eh? https://bugs.thedarkmod.com/view.php?id=5364

I guess this one needs more votes ;)

This is now implemented in f7f1720bd3109909beea110ac0ed55e1d9d92bc6

  • Thanks 1
Link to post
Share on other sites
4 hours ago, OrbWeaver said:

This is now implemented in f7f1720bd3109909beea110ac0ed55e1d9d92bc6

That's great news, thank you! It should be very helpful to those mappers who prefer SuperMal color scheme (which is IMO the best of the dark ones).

  • Like 1
Link to post
Share on other sites

Yes, there are about 5 or 6 code parts making use of fonts, and I moved most of those sizes to the user.xml file. Only the orthoview settings are accessible through the preferences, the rest can only be modified through your user.xml file.

Unfortunately the measurement tool still uses the hardcoded default font size 14. If you like to modify it, please open a request on the tracker, I'll see what I can do.

Link to post
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.

×
×
  • Create New...