7318

congratulations!

here is the bug report: https://bugs.thedarkmod.com/view.php?id=5387 on Ubuntu 20.10 on last pull from branch 2.9.0 from github. now when creating the brush with a selected material it doesn't segfault any more, it's only when you apply a material the next time it segfaults: when applying a new material on a brush either from an existing brush with already a working material, or when the brush has the default material, the thing is that when you apply the new material it segfaults. that is either in the media tab, when selecting another material for a given selected brush, or, with a selected brush, and clicking on another material image in the textures tab. I've provided the two GDB traces, for the two cases, within the bug report, I hope it's useful.

man it works... and the issue is resolved. but I've found new ones also related to selecting and applying other textures, I'll do two more bug reports

after typing in the Darkradiant cloned repository folder: sudo make uninstall, and after a uninstall process, there is still the following folders left in the system:

couldn't finish the compile:

here: https://bugs.thedarkmod.com/view.php?id=5373

here it is: is this enough? the texture I'm selecting is the first one in Doom3: textures / alphalabs / a_enwall13c

I open DarkRadiant, select Doom3 as a edit platform, select the correct folder, the program runs fine, i can add entities, and create brushes with the default texture, but once i click on a material in the media/textures list i get a segfault. here is the GDB error trace: and here is the content of the log file: the log file doesn't update with any new error message: if you open the log file while the program works, when the program segfaults then log file doesn't update any more, but I post it for checking anyways. in the GDB trace the segfaults happen after all the GTK related messages that happen while the program works.

this did it!

no, i get the same error: here is the GDB trace: and here is the log file: it gives me the same Error: it seems that CameraWndManager is the first module to be registered, but then it gets registered again after VirtualFileSystem gets registered?

nope, I uninstalled it with sudo make uninstall Then I searched for all folders with "darkradiant" in my system and deleted them all manually. Then recompiled the code and Installed it again, but unfortunately I get the same error message.

built and installed, but I still get an error when running it I get the following Error window: here is the GDB trace:

what do you mean? you need my configure.ac script?

I've got this error while compiling:

once I start darkradiant I get a segfault: here is the darkradiant.log here is GDB:

now it builds correctly

isn't it failing at the end of the compile process? it says it "Leaving directory '/home/biel/code/DarkRadiant/radiant'" so by that time it has already compiled radiant isn't it? The config.log: my Ubuntu is Ubuntu 20.04.1 LTS, my python is the standard one.

right now I got an error but I guess it's unrelated to the last error: as per my Python version, as detected by .configure is: my python3 version is 3.8.5 actually and I have python2 too but I guess this is standard with Ubuntu.

nope, after "make clean" I get this: the error seems to happen close to the same spot, and afterwards if I "make" again I get the following: it seems the error is this "Error 127" in '/DarkRadiant/pluguin/script' ?

thanks! but I still get a compile error, here is the full report: autogen: configure: make: but now It doesn't give a location for the error! isn't it?

Is this of any help?

I got the following error when building in Ubuntu 19.10: make[3]: Entering directory '/home/biel/games/src/DarkRadiant/plugins/script' CXX ScriptingSystem.lo CXX ScriptCommand.lo CXX ScriptModule.lo CXX ScriptMenu.lo CXX ScriptWindow.lo CXX SceneNodeBuffer.lo CXX PythonModule.lo In file included from /usr/include/pybind11/pytypes.h:12, from /usr/include/pybind11/cast.h:13, from /usr/include/pybind11/attr.h:13, from /usr/include/pybind11/pybind11.h:49, from PythonModule.h:5, from PythonModule.cpp:1: PythonModule.cpp: In static member function ‘static void script::PythonModule::RegisterToPython(const ModuleRegistrationCallback&)’: PythonModule.cpp:30:13: error: ‘dev0’ was not declared in this scope 30 | PYBIND11_VERSION_PATCH << std::endl; | ^~~~~~~~~~~~~~~~~~~~~~ make[3]: *** [Makefile:674: PythonModule.lo] Error 1 make[3]: Leaving directory '/home/biel/games/src/DarkRadiant/plugins/script' make[2]: *** [Makefile:442: all-recursive] Error 1 make[2]: Leaving directory '/home/biel/games/src/DarkRadiant/plugins' make[1]: *** [Makefile:751: all-recursive] Error 1 make[1]: Leaving directory '/home/biel/games/src/DarkRadiant' make: *** [Makefile:492: all] Error 2

here this error is explained with great detail: https://wiki.gentoo.org/wiki/Upgrading_GCC

sudo update-alternatives --config gcc tells me there is no alternative to choose from after the update to Ubuntu 19.4 all I got is gcc-7 and gcc-8 installed, and only g++-8 installed. Both gcc --version and g++ --version report as (Ubuntu 8.3.0-6ubuntu1) 8.3.0 maybe I should install g++-7?

this is in the configure.ac file? I've tried the line directly on the Darkradiant base folder and got this: $ CXX="g++-7" ./configure --enable-darkmod-plugins && make -j3 && make install checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... /bin/mkdir -p checking for gawk... gawk checking whether make sets $(MAKE)... yes checking whether make supports nested variables... yes checking whether make supports nested variables... (cached) yes checking build system type... x86_64-unknown-linux-gnu checking host system type... x86_64-unknown-linux-gnu checking for a sed that does not truncate output... /bin/sed checking whether NLS is requested... yes checking for msgfmt... /usr/bin/msgfmt checking for gmsgfmt... /usr/bin/msgfmt checking for xgettext... /usr/bin/xgettext checking for msgmerge... /usr/bin/msgmerge checking whether make supports the include directive... yes (GNU style) checking for gcc... gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether gcc accepts -g... yes checking for gcc option to accept ISO C89... none needed checking whether gcc understands -c and -o together... yes checking dependency style of gcc... gcc3 checking for ld used by GCC... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for shared library run path origin... done checking how to run the C preprocessor... gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for CFPreferencesCopyAppValue... no checking for CFLocaleCopyCurrent... no checking for GNU gettext in libc... yes checking whether to use NLS... yes checking where the gettext function comes from... libc checking for msgfmt... yes checking for msgmerge... yes checking for xgettext... yes checking whether we are using the GNU C++ compiler... no checking whether g++-7 accepts -g... no checking dependency style of g++-7... none checking how to print strings... printf checking for a sed that does not truncate output... (cached) /bin/sed checking for fgrep... /bin/grep -F checking for ld used by gcc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm - interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... 1572864 checking how to convert x86_64-unknown-linux-gnu file names to x86_64-unknown-linux-gnu format... func_convert_file_noop checking how to convert x86_64-unknown-linux-gnu file names to toolchain format... func_convert_file_noop checking for /usr/bin/ld option to reload object files... -r checking for objdump... objdump checking how to recognize dependent libraries... pass_all checking for dlltool... no checking how to associate runtime and link libraries... printf %s\n checking for ar... ar checking for archiver @FILE support... no checking for strip... strip checking for ranlib... ranlib checking command to parse /usr/bin/nm -B output from gcc object... failed checking for sysroot... no checking for a working dd... /bin/dd checking how to truncate binary pipes... /bin/dd bs=4096 count=1 checking for mt... mt checking if mt is a manifest tool... no checking for ANSI C header files... no checking for sys/types.h... no checking for sys/stat.h... no checking for stdlib.h... no checking for string.h... no checking for memory.h... no checking for strings.h... no checking for inttypes.h... no checking for stdint.h... no checking for unistd.h... no checking for dlfcn.h... no checking for objdir... .libs checking if gcc supports -fno-rtti -fno-exceptions... no checking for gcc option to produce PIC... -fPIC -DPIC checking if gcc PIC flag -fPIC -DPIC works... yes checking if gcc static flag -static works... yes checking if gcc supports -c -o file.o... yes checking if gcc supports -c -o file.o... (cached) yes checking whether the gcc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... no checking how to run the C++ preprocessor... /lib/cpp checking whether the g++-7 linker (/usr/bin/ld) supports shared libraries... yes libtool.m4: error: problem compiling CXX test program checking for g++-7 option to produce PIC... -DPIC checking if g++-7 PIC flag -DPIC works... no checking if g++-7 static flag works... no checking if g++-7 supports -c -o file.o... no checking if g++-7 supports -c -o file.o... (cached) no checking whether the g++-7 linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... (cached) GNU/Linux ld.so checking how to hardcode library paths into programs... unsupported checking whether g++-7 supports C++11 features by default... no checking whether g++-7 supports C++11 features with -std=c++11... no checking whether g++-7 supports C++11 features with +std=c++11... no checking whether g++-7 supports C++11 features with -h std=c++11... no checking whether g++-7 supports C++11 features with -std=c++0x... no checking whether g++-7 supports C++11 features with +std=c++0x... no checking whether g++-7 supports C++11 features with -h std=c++0x... no configure: error: *** A compiler with support for C++11 language features is required.g++-7 should support c++11 features, isn't it?