Jump to content
XCOMUFO & Xenocide

Compilation problems


DaiShiva

Recommended Posts

i have the same error as FooBar.

src/glyphkeeper/glyph_rend.c:510: error: dereferencing pointer to incomplete type

beginning with the error that shows that i cant include the freetype headers.

i also executet the freetype commands and got exactly the same output like FooBar.

 

compiling it without ttf support worked for me, is there any other way to go around compiling error and still having ttf enabled?

Link to comment
Share on other sites

  • 1 month later...
  • Replies 113
  • Created
  • Last Reply

Top Posters In This Topic

I've just downloaded the source from svn, and installed the necessary components to compile under Windows, but I get an error when linking:

/mingw/lib/libbfd.a(cache.o):cache.c:(.text+0x35d): undefined reference to `unlink_if_ordinary'
collect2: ld returned 1 exit status
make: *** [ufo2000.exe] Error 1

 

I think I followed the instructions on the website. I installed Mingw32, svn, msys, and the updated mingw32-libraries. (But, it's always possible I goofed somewhere)

 

If anybody knows where my missing library is, let me know.

 

Thanks,

PaulH

 

 

It's not a missing library but an incompatibility in libbfd (IIRC) which means that the unlink_if_ordinary function doesn't exist. Download the latest parts of MinGW - don't use the MinGW installer as this does not install an up to date version of gcc/g++/binutils etc. I'm using gcc 3.4.5, mingw runtime 3.13, w32api 3.10, binutils 2.17.50 and msys 1.0.10. The file in question is in the binutils so perhaps just getting the most recent tar of this will fix it.

 

Hope this helps

AndyS

Link to comment
Share on other sites

It's not a missing library but an incompatibility in libbfd (IIRC) which means that the unlink_if_ordinary function doesn't exist. Download the latest parts of MinGW - don't use the MinGW installer as this does not install an up to date version of gcc/g++/binutils etc. I'm using gcc 3.4.5, mingw runtime 3.13, w32api 3.10, binutils 2.17.50 and msys 1.0.10. The file in question is in the binutils so perhaps just getting the most recent tar of this will fix it.

 

Hope this helps

AndyS

 

I had same problem as PaulH - after reading your post I've replaced old files in migw/lib with those ones from binutils/lib/ (5 files) directory as you suggested and

I finally succesfully compiled the game :Pepper:

Thank you very much. :D I hope I will have time to do something with code now.

Edited by Intri
Link to comment
Share on other sites

  • 1 month later...

Hi, all!

 

Recently i've migrated to Linux. My distro is Mandriva Free 2007.0. I've downloaded the source code and tried to "make" and "make install" it. Well, it's kind of not working. I mean, 'make' did the work - there binary files in the directory and i can launch the game. But i thought it would be a good idea to install it properly. So, i've run the make install and it gave me this:

 

g++ -funsigned-char -Wall -Wno-deprecated-declarations -I src/lua -I src/luasqlite3 -DDEBUGMODE -DUFO_SVNVERSION=\"exported\" -O2 -pipe -I/usr/include/freetype2 -DHAVE_FREETYPE -DGLYPH_TARGET=GLYPH_TARGET_ALLEGRO -DGK_NO_LEGACY -DHAVE_DUMBOGG -DHAVE_PNG -DLINUX -I/usr/include -o ufo2000-srv obj-srv/server_config.o obj-srv/server_main.o obj-srv/server_protocol.o obj-srv/server_game.o obj-srv/md5.o obj-srv/server_transport.o obj-srv/lapi.o obj-srv/lauxlib.o obj-srv/lbaselib.o obj-srv/lcode.o obj-srv/ldblib.o obj-srv/ldebug.o obj-srv/ldo.o obj-srv/ldump.o obj-srv/lfunc.o obj-srv/lgc.o obj-srv/liolib.o obj-srv/llex.o obj-srv/lmathlib.o obj-srv/lmem.o obj-srv/loadlib.o obj-srv/lobject.o obj-srv/lopcodes.o obj-srv/lparser.o obj-srv/lstate.o obj-srv/lstring.o obj-srv/lstrlib.o obj-srv/ltable.o obj-srv/ltablib.o obj-srv/ltests.o obj-srv/ltm.o obj-srv/lundump.o obj-srv/lvm.o obj-srv/lzio.o obj-srv/sqlite3_command.o obj-srv/sqlite3_connection.o obj-srv/sqlite3_internal.o obj-srv/sqlite3_reader.o -lsqlite3 -lNL -pthread
# necessary in order to create a Debian/derivatives package with:
# dpkg-buildpackage -rfakeroot
# BEGIN copied from binary-gz target
svn delete --force ufo2000-0.7.exported
svn: '.' is not a working copy
make: *** [install] Ошибка 1

 

Is there any way out? I've also tried to make an RPM package, but i've failed, since it requires correct make install.

Link to comment
Share on other sites

  • 4 weeks later...

Well, i do have all those libraries. If i hadn't then i couldn't even 'make'. But the mentioned problem is about 'make install'. I have the right DUMB version. Though, i've found out that i'm able to run ufo2000 even with dumb 0.9.3. But only if the game itself was compiled with DUMB 0.9.2. Sounds weird, it works.

Back to the 'make install' problem. I suppose there's something here to do with SVN. I took the sources not from the SVN repository (if you have it). Do i need to run something like

svn checkout svn://some_ufo2k_svn_repository

or anything else?

Link to comment
Share on other sites

You don't need to have svn, or even a svn checkout version. As long as you have the source files, you can compile them. 'make install' isn't the same thing as 'make', although it still compiles, but into an installer form. 'make install' creates an installer for the game, which you do not need since you can just compile the sources to create executable right away. You are getting that error because you can't create an installer for your operating system. Ufo2000's 'make install' is meant for windows systems, which requires NSIS to create a win32 installer.

 

'make' works fine, that's all you have to worry about.

 

As for DUMB 0.9.3, ufo2000 isn't setup to compile with it, hence compilation problems.

 

But i thought it would be a good idea to install it properly.

There is no such thing as a "proper" install. This is just a misconception with Window's "friendly" interface. There is no installation difference between an automated installer vs. compiling into an executable.

Link to comment
Share on other sites

I'm not sure Mandriva (what Kraplax is using) is based on an Debain environment...thanks for those who do though. :)

 

That is another reason to not chose lousy distributives (Mandriva).

 

P.S. Memory leaks in ufo2k is not debian specific and still present in current svn version.

Link to comment
Share on other sites

  • 2 years later...

I'll dig this thread up. ?

 

Does someone debug the game in an IDE?

 

I've unsuccessfully tried Eclipse 3.5 under Windows. I've built the executable from inside the IDE using MinGW 3.1 toolchain. I've used precompiled mingw libraries from here.

 

Got "No source available". I've used the compiler with "-g" option, it gave debug info I'm sure. The question arise therefore: were the mingw libraries compiled with debug info?

 

Relevant discussion and a quote from it: "make sure the libs you're linking against were compiled with debug flags set too, it's not always enough to just make sure your own code has them set".

Link to comment
Share on other sites

The question arise therefore: were the mingw libraries compiled with debug info?

Probably not, but they are available mostly for convenience. It is possible to recompile all the libraries with debug info.

 

BTW, these libraries are much less likely to have bugs than the game itself :)

Link to comment
Share on other sites

  • 4 weeks later...

I've eventually made the game debuggable on my system. Just ran "make debug=0" :) That was so easy, no need in compiling mingw libraries with debug info :)

 

I've made a patch to issue 571 and have uploaded it to the bugtracker.

Link to comment
Share on other sites

I've eventually made the game debuggable on my system. Just ran "make debug=0" :) That was so easy, no need in compiling mingw libraries with debug info :)

"make debug=1" would work too, and it's also documented in the makefile

Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×
×
  • Create New...