Jump to content
The Dark Mod Forums

DarkRadiant doesn't compile on Ubuntu 9.04 64 bit


RobertBeckebans

Recommended Posts

Although it compiles fine on the 32 bit edition.

 

Compile log:

  1. g++ -DHAVE_CONFIG_H -I. -I.. -DPKGLIBDIR='"/usr/local/lib/darkradiant"' -DPKGDATADIR='"/usr/local/share/darkradiant"' -I../include -I../libs -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT -I/usr/include/gtkglext-1.0 -I/usr/lib/gtkglext-1.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 -DRADIANT_USE_GLSL -DPOSIX -g -O2 -Wall -Wno-unused-variable -MT darkradiant-AnglePropertyEditor.o -MD -MP -MF .deps/darkradiant-AnglePropertyEditor.Tpo -c -o darkradiant-AnglePropertyEditor.o `test -f 'ui/einspector/AnglePropertyEditor.cpp' || echo './'`ui/einspector/AnglePropertyEditor.cpp
  2. ui/einspector/AnglePropertyEditor.cpp: In static member function 'static void ui::AnglePropertyEditor::_onButtonClick(
    GtkButton*, ui::AnglePropertyEditor*)':
  3. ui/einspector/AnglePropertyEditor.cpp:79: error: cast from 'void*' to 'gint' loses precision
  4. make[2]: *** [darkradiant-AnglePropertyEditor.o] Error 1
  5. make[2]: Leaving directory `/home/me/0/software/darkradiant/svn/darkradiant/radiant'
  6. make[1]: *** [all-recursive] Error 1
  7. make[1]: Leaving directory `/home/me/0/software/darkradiant/svn/darkradiant'
  8. make: *** [all] Error 2

Link to comment
Share on other sites

These are a lot of linker errors you're getting. The offending symbols should be coming from ui/einspector/PropertyEditor.cpp and checking the Makefile.am file it seems this is properly included. If you weren't getting these linker errors before, I'm assuming something went wrong with the makefile generation.

 

But I see the compiler error went away, so it seems my fix did the trick.

 

Sorry. I don't have an IRC channel, nor have I ever been using one. :) I'm usually around these forums anyway.

Link to comment
Share on other sites

so it's compiling ok, but the linking stage isn't working?

Yes, according to this:

undefined reference to `ui::PropertyEditor::PropertyEditor(Entity*)'

collect2: ld returned 1 exit status

These are linker errors. It's trying to find the definition of the PropertyEditor constructor, which is most certainly there and the file it's defined in is indeed mentioned in the makefile.

 

i did make clean, re-ran ./configure and built it again with the same error. any idea what the problem might be?

I don't know what's going wrong. I don't have Linux available right now, so I cannot investigate this problem. Maybe OrbWeaver reads this and has some suggestions as he's much more familiar with Automake than I am.

 

A thought: have you tried running the autogen.sh shell script again?

Link to comment
Share on other sites

On Fedora, compiled darkradiant-trunk (from today).

I had to fix some things to compile, see the codebox below.

fixes to fix 'EOF not defined', and two to link with libboost_system.

 

After you apply these, run ./autogen.sh to have ui/einspector/PropertyEditor.cpp included in the makefile and also to propagate the fixes to the Makefile.in files. Then configure again to propagate them to the Makefiles and then make to use them.

 

With these adjustments, it compiles for me (32 bit).

 

========================================
===========================
--- radiant/log/LogStreamBuf.cpp    (revision 4849)
+++ radiant/log/LogStreamBuf.cpp    (working copy)
@@ -1,5 +1,6 @@
#include "LogStreamBuf.h"

+#include <stdio.h>
#include <stdexcept>
#include "LogWriter.h"

Index: include/itextstream.h
========================================
===========================
--- include/itextstream.h    (revision 4849)
+++ include/itextstream.h    (working copy)
@@ -27,6 +27,7 @@

#include <cstddef>
#include <string>
+#include <stdio.h>
#include <streambuf>
#include <istream>
#include <cassert>

Index: plugins/vfspk3/Makefile.am
========================================
===========================
--- plugins/vfspk3/Makefile.am    (revision 4849)
+++ plugins/vfspk3/Makefile.am    (working copy)
@@ -5,6 +5,6 @@
modules_LTLIBRARIES = vfspk3.la

vfspk3_la_LDFLAGS = -module -avoid-version \
-                    $(GLIB_LIBS) $(XML_LIBS) $(BOOST_FILESYSTEM_LIBS)
+                    $(GLIB_LIBS) $(XML_LIBS) -lboost_system $(BOOST_FILESYSTEM_LIBS)
vfspk3_la_SOURCES = vfspk3.cpp Doom3FileSystem.cpp DirectoryArchive.cpp

Index: plugins/script/Makefile.am
========================================
===========================
--- plugins/script/Makefile.am    (revision 4849)
+++ plugins/script/Makefile.am    (working copy)
@@ -6,7 +6,7 @@
modules_LTLIBRARIES = script.la

script_la_LDFLAGS = -module -avoid-version \
-                    $(BOOST_FILESYSTEM_LIBS) \
+                    -lboost_system $(BOOST_FILESYSTEM_LIBS) \
                    $(BOOST_PYTHON_LIBS) \
                    $(PYTHON_LIBS) \
                    $(GTK_LIBS)

Link to comment
Share on other sites

Thanks for the patch, I committed the changes to the include files. However, I'm not sure about the makefile changes - I suspect they should be done via $(BOOST_SYSTEM_LIBS) variables instead of setting the -lboost_system flags directly. OrbWeaver will know more about this.

Link to comment
Share on other sites

I've seen that assertion before, it seems some code is still wanting to access the scenegraph, even if the root is already null-ified. I'll have to investigate it sometime, it's mostly harmless - it just occurs at module shutdown.

 

As for the textures, your console might give some insight about where it is searching and what kind of errors occur.

Link to comment
Share on other sites

Yeah that would be neat, here is a patch with $(BOOST_SYSTEM_LIBS). It works for me.

You have to run autogen.sh again to rebuild configure after this patch.

 

Thanks for quickly replying to the other patch ^_^

 

Index: configure.ac
========================================
===========================
--- configure.ac    (revision 4850)
+++ configure.ac    (working copy)
@@ -101,6 +101,12 @@
             [AC_MSG_ERROR([boost.Filesystem not found])])
AC_SUBST([bOOST_FILESYSTEM_LIBS])

+# Boost.System
+AC_CHECK_LIB([boost_system], [main],
+             [bOOST_SYSTEM_LIBS='-lboost_system'],
+             [AC_MSG_ERROR([boost.System not found])])
+AC_SUBST([bOOST_SYSTEM_LIBS])
+
# Boost.Python if required
if test "$python_scripting" = 'yes'
then
Index: plugins/script/Makefile.am
========================================
===========================
--- plugins/script/Makefile.am    (revision 4850)
+++ plugins/script/Makefile.am    (working copy)
@@ -6,6 +6,7 @@
modules_LTLIBRARIES = script.la

script_la_LDFLAGS = -module -avoid-version \
+                    $(BOOST_SYSTEM_LIBS) \
                    $(BOOST_FILESYSTEM_LIBS) \
                    $(BOOST_PYTHON_LIBS) \
                    $(PYTHON_LIBS) \
Index: plugins/vfspk3/Makefile.am
========================================
===========================
--- plugins/vfspk3/Makefile.am    (revision 4850)
+++ plugins/vfspk3/Makefile.am    (working copy)
@@ -5,6 +5,6 @@
modules_LTLIBRARIES = vfspk3.la

vfspk3_la_LDFLAGS = -module -avoid-version \
-                    $(GLIB_LIBS) $(XML_LIBS) $(BOOST_FILESYSTEM_LIBS)
+                    $(GLIB_LIBS) $(XML_LIBS) $(BOOST_SYSTEM_LIBS) $(BOOST_FILESYSTEM_LIBS)
vfspk3_la_SOURCES = vfspk3.cpp Doom3FileSystem.cpp DirectoryArchive.cpp

Link to comment
Share on other sites

The compiler here generates some warnings that your compiler may not. I have collected the ones that I think may be bugs/oversights/possible signs of problems: http://pastebin.com/m2c3e7066 I left out signedness warnings, pointer-conversion warnings and breaking strict-aliasing rules (type punned pointers).

 

Well, except for that float pointer to double pointer warning, which looks like it is a real bug. Yay for gcc 4.4 :) .

Link to comment
Share on other sites

  • 2 weeks later...

The compiler here generates some warnings that your compiler may not. I have collected the ones that I think may be bugs/oversights/possible signs of problems: http://pastebin.com/m2c3e7066

I'm currently working through that list, and it seems many if not all of the "value computed is not used" warnings are false positives:

 

int sgetI1( unsigned char **bp )
{
  int i;

  if ( flen == FLEN_ERROR ) return 0;
  i = **bp;
  if ( i > 127 ) i -= 256;
  flen += 1;     // WARNING HERE: Value computed is not used
  *bp++;
  return i;
}

In fact, the variable flen is a static int, a global variable, so the compiler warning is not correct - it can be used by another method out of that local scope, so I'll just ignore these.

 

I'll see through the other ones, but for some of those I can only attempt to fix them but not check it as I'm not in Linux here.

Link to comment
Share on other sites

The compiler here generates some warnings that your compiler may not.

Ok, I think I'm through with that list. Could you try re-compiling and posting the new output somewhere? Most important warnings should be gone now.

Link to comment
Share on other sites

  • 4 weeks later...

I'm currently working through that list, and it seems many if not all of the "value computed is not used" warnings are false positives:

 

int sgetI1( unsigned char **bp )
{
int i;

if ( flen == FLEN_ERROR ) return 0;
i = **bp;
if ( i > 127 ) i -= 256;
flen += 1; // WARNING HERE: Value computed is not used
*bp++;
return i;
}

In fact, the variable flen is a static int, a global variable, so the compiler warning is not correct - it can be used by another method out of that local scope, so I'll just ignore these.

 

I'll see through the other ones, but for some of those I can only attempt to fix them but not check it as I'm not in Linux here.

 

No the warning is one line lower. On the *bp++; This is incrementing the handle (the function argument) which gets discarded at function exit. The * in there serves no purpose, hence the warning. The result of the increase is also never used ...

 

Now if it was (*bp)++; then the pass-by-reference pointer gets incremented. I do not understand your code well enough to know if this routine gets passed an array of pointers and it cycles to the next pointer in the array, if the (**bp)++ data value needs changing, or if (*bp)++ the pass-by-ref-ptr needs moving, or the statement simply needs to be discarded.

 

If this one was off one line, you might check at other 'nonsense'warnings if the next line has it. I'll see about recompiling.

Link to comment
Share on other sites

Recompiled, and the previous warnings are fixed :laugh:

 

I had to re-run autogen.sh to recreate radiant/Makefile.in otherwise you get missing symbol errors in linking, you patched the Makefile.am but autogen.sh needs to run after that. Hm I'm not allowed to attach .patch.gz files. http://rapidshare.com/files/295706778/trunk_oct20_autogen.patch.gz.html

 

Well, I have compiled again and included all the warnings I left out previously. Signed/unsigned trouble, and lots and lots of strict-aliasing errors. The most important are a couple unsolved 'result unused' warnings, like that *bp++ we discussed above.

 

http://pastebin.com/m58de8cf

Edited by shadow_ibix
Link to comment
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.

  • Recent Status Updates

    • OrbWeaver

      Does anyone actually use the Normalise button in the Surface inspector? Even after looking at the code I'm not quite sure what it's for.
      · 6 replies
    • Ansome

      Turns out my 15th anniversary mission idea has already been done once or twice before! I've been beaten to the punch once again, but I suppose that's to be expected when there's over 170 FMs out there, eh? I'm not complaining though, I love learning new tricks and taking inspiration from past FMs. Best of luck on your own fan missions!
      · 4 replies
    • The Black Arrow

      I wanna play Doom 3, but fhDoom has much better features than dhewm3, yet fhDoom is old, outdated and probably not supported. Damn!
      Makes me think that TDM engine for Doom 3 itself would actually be perfect.
      · 6 replies
    • Petike the Taffer

      Maybe a bit of advice ? In the FM series I'm preparing, the two main characters have the given names Toby and Agnes (it's the protagonist and deuteragonist, respectively), I've been toying with the idea of giving them family names as well, since many of the FM series have named protagonists who have surnames. Toby's from a family who were usually farriers, though he eventually wound up working as a cobbler (this serves as a daylight "front" for his night time thieving). Would it make sense if the man's popularly accepted family name was Farrier ? It's an existing, though less common English surname, and it directly refers to the profession practiced by his relatives. Your suggestions ?
      · 9 replies
    • nbohr1more

      Looks like the "Reverse April Fools" releases were too well hidden. Darkfate still hasn't acknowledge all the new releases. Did you play any of the new April Fools missions?
      · 5 replies
×
×
  • Create New...