OrbWeaver 639 Posted December 17, 2020 Report Share Posted December 17, 2020 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. Quote DarkRadiant homepage β DarkRadiant user guide β OrbWeaver's Dark Ambients β Blender export scripts Link to post Share on other sites
IZaRTaX 29 Posted December 18, 2020 Report Share Posted December 18, 2020 Png 16 bits is no longer supported in 2.10.0 everytime you try to open it causes Radiant crash only 8 bits working . Quote Level Designer https://izartax.wixsite.com/zartax Link to post Share on other sites
greebo 73 Posted December 18, 2020 Author Report Share Posted December 18, 2020 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? Quote Link to post Share on other sites
IZaRTaX 29 Posted December 19, 2020 Report Share Posted December 19, 2020 6 hours ago, greebo said: Can you open an issue report and attach a small example file, please? Ok reported Quote Level Designer https://izartax.wixsite.com/zartax Link to post Share on other sites
PranQster 457 Posted December 20, 2020 Report Share Posted December 20, 2020 (edited) 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 Quote System: Mageia Linux Cauldron, aka Mageia 8 Link to post Share on other sites
greebo 73 Posted December 20, 2020 Author Report Share Posted December 20, 2020 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. Quote Link to post Share on other sites
greebo 73 Posted December 20, 2020 Author Report Share Posted December 20, 2020 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. Quote Link to post Share on other sites
OrbWeaver 639 Posted December 20, 2020 Report Share Posted December 20, 2020 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. Quote DarkRadiant homepage β DarkRadiant user guide β OrbWeaver's Dark Ambients β Blender export scripts Link to post Share on other sites
PranQster 457 Posted December 20, 2020 Report Share Posted December 20, 2020 (edited) 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 Quote System: Mageia Linux Cauldron, aka Mageia 8 Link to post Share on other sites
greebo 73 Posted December 21, 2020 Author Report Share Posted December 21, 2020 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! Quote Link to post Share on other sites
OrbWeaver 639 Posted December 22, 2020 Report Share Posted December 22, 2020 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 1 Quote DarkRadiant homepage β DarkRadiant user guide β OrbWeaver's Dark Ambients β Blender export scripts Link to post Share on other sites
greebo 73 Posted December 22, 2020 Author Report Share Posted December 22, 2020 Thanks, it's merged! And a new pre-release build is available in the first post. Quote Link to post Share on other sites
peter_spy 1603 Posted December 22, 2020 Report Share Posted December 22, 2020 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). 1 Quote Misc. assets for TDM Link to post Share on other sites
peter_spy 1603 Posted December 24, 2020 Report Share Posted December 24, 2020 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: Quote Misc. assets for TDM Link to post Share on other sites
greebo 73 Posted December 24, 2020 Author Report Share Posted December 24, 2020 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. Quote Link to post Share on other sites
peter_spy 1603 Posted December 24, 2020 Report Share Posted December 24, 2020 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). Quote Misc. assets for TDM Link to post Share on other sites
grayman 2974 Posted December 24, 2020 Report Share Posted December 24, 2020 Thanks for making the "font" change. It's been a big help. I can put away my magnifying glass now... Quote Link to post Share on other sites
greebo 73 Posted December 25, 2020 Author Report Share Posted December 25, 2020 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! Quote Link to post Share on other sites
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.