DarkRadiant 2.10.0 pre-release test

[OrbWeaver 639]

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.

[IZaRTaX 29]

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

[greebo 73]

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?

[IZaRTaX 29]

6 hours ago, greebo said:

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

Ok reported

[PranQster 457]

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 December 20, 2020 by PranQster

[greebo 73]

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.

[greebo 73]

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.

[OrbWeaver 639]

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.

[PranQster 457]

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 December 20, 2020 by PranQster

[greebo 73]

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!

[OrbWeaver 639]

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

[greebo 73]

Thanks, it's merged!

And a new pre-release build is available in the first post.

[peter_spy 1603]

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

[peter_spy 1603]

Lights work great now, same for font scaling in ortho view. It's much more comfortable to look at. One small thing, the Measure tool numbers don't scale:

[greebo 73]

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.

[peter_spy 1603]

I'll set it to the lowest priority though, not sure how many people use it. I do, but it's probably more for the sake of consistency (i.e. there's no need for separate option to adjust this).

[grayman 2974]

Thanks for making the "font" change.

It's been a big help. I can put away my magnifying glass now...

[greebo 73]

Next (and probably) final pre-release build is available in the first post. I will release this in the next few days, so any testing is appreciated!