the old darkradiant in the OpenTechEngine repo doesn't compile about discussions HOT 14 OPEN

I'll try to, but if I could get the 1.8 version to run then the error is generated in the commits inbetween october 2013 to july 2014, that is between 1.8 and two months before the next release (which is the one in OTE/Darkradiant)
--edit--
solved the error with a future commit form the past! great-scott Marty!

from discussions.

I was wondering what was the purpose of the fork of DarkRadiant in the first place, was it just the inactive development or something else? I was compiling/running Darkradiant 2.0.4 and it's definitly a improvement imho, maybe we can just pull the changes from the original repo or just drop our's alltogether and use the one from upstream again?

from discussions.

I can't get the new releases of DarkRadiant to work, I get asegfault error after selecting the engine and the base folder.
And Greebo/codereader told me he was not going to test my problem on a virtual machine, I understand that he is alone maintianing the repository, so he is very fed up with solving other people's problems.
So my only remaining option is to use the old DarkRadiant, that I know worked fine before, but now I can't compile due that error in the configure file.

I guess imGUI is being implemented in order to restore the original radiant from doom3, which is the best solution in the long run.
But if I want to test things with the engine I need to have access to some kind of mapping editor, can someone help me with that configure file?

from discussions.

Hm, that sounds like an awkward spot you are in at the moment, a quick shot in the dark would be to try updating the configure script by issueing ./autogen.sh before running ./configure, or you could try compiling with the static boost version by adding --enable-static-boost to ./configure. If those two dont help, we need some more info to investigate like your linux distribution, what boost version you have installed etc.

from discussions.

yes at the moment I can't map for the engine.

I already did the autogen.sh, but the configure, whether I do the autogen.sh or not, still fails at the same spot.

I just tested: ./configure --enable-static-boost and it still fails the same way

I have all libs necessary for the compilation, although libgtksourceviewmm-2.0-dev no longer appears in the repositories I have the current: libgtksourceviewmm-3.0-dev.
(how are those libs reference when compiling? maybe we should change that reference?)

besides this all necessary liboost libraries version is "1.58.0.1ubuntu1"

from discussions.

Checking the configure.sh of both versions, there seems to be a difference in handling the version string

For the old DarkRadiant it's:

if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
tr -d '\r' |
$SED -n -e "/^boost-lib-version = /{s///;s/"//g;p;q;}" >conftest.i 2>&1; then :
boost_cv_lib_version=cat conftest.i
fi

starting from line 18804

While for newer versions of DarkRadiant it's:

if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
grep -v '#' |
tr -d '\r' |
tr -s '\n' ' ' |
$SED -n -e "/^boost-lib-version = /{s///;s/[" ]//g;p;q;}" >conftest.i 2>&1; then :
boost_cv_lib_version=cat conftest.i
fi

Try replacing the old block with the new block.

from discussions.

thanks! now it finished ./configure without a hitch

github eliminated the accents needed for a part of the code (that's the reason it has some part of the code that has a different format) so this is the actual code:

#if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
#  tr -d '\r' |
#  $SED -n -e "/^boost-lib-version = /{s///;s/\"//g;p;q;}" >conftest.i 2>&1; then :
#  boost_cv_lib_version=`cat conftest.i`
#fi

if (eval "$ac_cpp conftest.$ac_ext") 2>&5 |
  grep -v '#' |
  tr -d '\r' |
  tr -s '\n' ' ' |
  $SED -n -e "/^boost-lib-version = /{s///;s/[\" ]//g;p;q;}" >conftest.i 2>&1; then :
  boost_cv_lib_version=`cat conftest.i`
fi

from discussions.

compiled fine, installed fine but I end up with an segfault at the same place of the new versions! that is after selecting the right engine it keeps loading stuff and when it's about to load the x/y/z screens for working it segfaults... now I can test this ./configure solution for all the versions I can get from greebo/codereader and see if I get a consistent place of the error, maybe it's when opening the screens. this has since Ubuntu 15.04, maybe the mesa drivers? I'll try to ask him again...

from discussions.

now I'm trying to compile the 1.8 release, the same ./configure solution applies, ./autogen.sh works, ./configure works but now the make fails to compile:

$ make
 cd . && automake-1.15 --foreign
automake-1.15: error: global options already processed
automake-1.15: Please contact <[email protected]>.
 at /usr/share/automake-1.15/Automake/Channels.pm line 662, <GEN0> line 91.
    Automake::Channels::msg("automake", "", "global options already processed") called at /usr/share/automake-1.15/Automake/ChannelDefs.pm line 212
    Automake::ChannelDefs::prog_error("global options already processed") called at /usr/share/automake-1.15/Automake/Options.pm line 421
    Automake::Options::process_global_option_list(HASH(0x2dddf30)) called at /usr/bin/automake-1.15 line 5337
    Automake::scan_autoconf_traces("configure.ac") called at /usr/bin/automake-1.15 line 5437
    Automake::scan_autoconf_files() called at /usr/bin/automake-1.15 line 8259
Makefile:429: recipe for target 'Makefile.in' failed
make: *** [Makefile.in] Error 1

--edit--

well not entirely true, autogen.sh also fails here (it didn't before):

$ ./autogen.sh 
libtoolize: putting auxiliary files in '.'.
libtoolize: copying file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
automake: error: global options already processed
automake: Please contact <[email protected]>.
 at /usr/share/automake-1.15/Automake/Channels.pm line 662, <GEN0> line 91.
    Automake::Channels::msg("automake", "", "global options already processed") called at /usr/share/automake-1.15/Automake/ChannelDefs.pm line 212
    Automake::ChannelDefs::prog_error("global options already processed") called at /usr/share/automake-1.15/Automake/Options.pm line 421
    Automake::Options::process_global_option_list(HASH(0x1795a78)) called at /usr/bin/automake line 5337
    Automake::scan_autoconf_traces("configure.ac") called at /usr/bin/automake line 5437
    Automake::scan_autoconf_files() called at /usr/bin/automake line 8259

--edit2--
no need to do autogen.sh first, now this old version of Darkradiant is compiling

from discussions.

damn it fails while compiling the plugins when it has already compiled the whole of the program! I'll try to fix this in order to see if I can make it work...

from discussions.

Would it be possible for you to try debug DarkRadiant when the segfault is happening and provide the backtrace to either here or Greebo?

from discussions.

what is the way to compile it with the debug profile (grebbo's current commits, not the one in OTE repository)

from discussions.

You should be able to compile it with ./configure --enable-debug.

from discussions.

Darkradiant 1.8 has the same error, I'm starting to hate Darkradiant with a passion!
It reminds me why I wanted to do a Blender editor for idTechX... and still makes it a sane idea despite the python implementation in Blender

@damiel thanks for the help! I'll try to compile the newest DR with the debug profile

from discussions.