Compiling with Code::Blocks

Trying to build your own version of Vega Strike and having problems? Unix users, paste your config.log here (stderr output alone is not helpful).
RedAdder
Bounty Hunter
Bounty Hunter
Posts: 149
Joined: Sat Jan 03, 2009 8:11 pm
Location: Germany, Munich
Contact:

Re: Compiling with Code::Blocks

Post by RedAdder »

I added setbuf(stdout,NULL) in first line of main(..) of main.cpp but there was no additional output.

Loading factions.xml completes.. The last png it tries to load and that i see is blackclear.png
shenle
Confed Special Operative
Confed Special Operative
Posts: 381
Joined: Thu Jan 31, 2008 3:25 am
Location: hiding in a dark corner

Re: Compiling with Code::Blocks

Post by shenle »

My build runs fine, completely playable FWIW.
make me a sandwich
make: *** No rule to make target 'me'. Stop.
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Re: Compiling with Code::Blocks

Post by ace123 »

Is there any way you can attach a debugger to it? I don't know how code blocks works, but even the express versions of VC++ come with a debugger.

Aside from that, you may be stuck adding printfs all over the code to try to find which line causes the crash. It may take a bit of work to trace down the exact location (but it's kind of like a binary search).

Unfortunately the output doesn't seem very helpful in tracing down the exact cause. Another thing you can try is to change the settings in Setup maybe to their lowest values (turn off sound and music, Windowed mode, turn off shaders, etc.)
RedAdder
Bounty Hunter
Bounty Hunter
Posts: 149
Joined: Sat Jan 03, 2009 8:11 pm
Location: Germany, Munich
Contact:

Re: Compiling with Code::Blocks

Post by RedAdder »

I started the visual c++ debugger with it. It appears it broke exactly where one would expect it to break - in the png handling code - because I changed the lib from libpng3 to libpng13

line is 340, file is gfx/vsimage.cpp

png_read_info(png_ptr, info_ptr); /* read all PNG info up to image data */

maybe it is a common migration error I'll look on google
RedAdder
Bounty Hunter
Bounty Hunter
Posts: 149
Joined: Sat Jan 03, 2009 8:11 pm
Location: Germany, Munich
Contact:

Re: Compiling with Code::Blocks

Post by RedAdder »

I replaced the libpng13.dll with a non-optimized debug compile of the dll, since there was a comment that the optimized version did not work on mac.

This leads me to an uncaught Audio::FileOpenException in void Mesh::initTechnique("fixed"), which is solved by checking out and installing the techniques folder.

Now I have reached an exception caused by PyRun_SimpleFile(inFile,pyfile); seeking main_menunightprivateer.py
Vegastrike isn't very talkative in its error output, is it?

Which folder under data is theone with main_menunightprivateer.py in ? I don't want to check out all of data at the moment.
loki1950
The Shepherd
Posts: 5841
Joined: Fri May 13, 2005 8:37 pm
Location: Ottawa
Contact:

Re: Compiling with Code::Blocks

Post by loki1950 »

That would be the mission folder RedAdder at least that is where main_mission.mission is.

Enjoy the Choice :)
my box::HP Envy i5-6400 @2Q70GHzx4 8 Gb ram/1 Tb(Win10 64)/3 Tb Mint 19.2/GTX745 4Gb acer S243HL K222HQL
Q8200/Asus P5QDLX/8 Gb ram/WD 2Tb 2-500 G HD/GF GT640 2Gb Mint 17.3 64 bit Win 10 32 bit acer and Lenovo ideapad 320-15ARB Win 10/Mint 19.2
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Re: Compiling with Code::Blocks

Post by ace123 »

All of these problems point to library incompatibilities--you are linking with libraries compiled using a different C library than you use for Vega Strike itself.

Answered your question here:
http://vegastrike.sourceforge.net/forum ... 20#p108220
Can you try replacing that specific instance of PyRun_SimpleFile with the series of function calls I had there?

I believe the DLLs in the "vega-vc7" folder are compatible with VC++ 2003 and the DLLs in "vega-vc8" are compatible with VC++ 2005. Which ones are you using?
I do know as a fact that I am able to compile Vega Strike with either vc7 or vc8 using the official compilers/IDE and neither one causes a crash despite using the same DLLs... however when I use vc9 (2008) I run into the exact problems you are noticing.
shenle
Confed Special Operative
Confed Special Operative
Posts: 381
Joined: Thu Jan 31, 2008 3:25 am
Location: hiding in a dark corner

Re: Compiling with Code::Blocks

Post by shenle »

That's probably why I haven't run into any of this trouble - everything on my machine is compiled with either VS .NET 2003 or the 2003 toolkit, which are essentially the same, and using the same header/library set.
make me a sandwich
make: *** No rule to make target 'me'. Stop.
RedAdder
Bounty Hunter
Bounty Hunter
Posts: 149
Joined: Sat Jan 03, 2009 8:11 pm
Location: Germany, Munich
Contact:

Re: Compiling with Code::Blocks

Post by RedAdder »

You are right on spot - I used the vc7 project file instead of the vc8.
I'll try to compile again with the vc8 project.

The python calling code you put into the other thread works well.
I now can use the menu to load saved games despite the wrong python library.
Here is the code I used, it only works with the new code not the old code that is #ifdef-ed out.

Code: Select all

#include "config.h"
#include <Python.h>
#include <vector>
#include <string>
#include <math.h>
#include "python/python_class.h"
#include "base.h"
#include "base_util.h"
#include "vsfilesystem.h"
#include <boost/version.hpp>
#if BOOST_VERSION != 102800
#include <boost/python/object.hpp>
#else
#include <boost/python/objects.hpp>
#endif

static string last_filename= "";

static FILE * withAndWithout (std::string filename, std::string time_of_day_hint) {
  string with (filename+"_"+time_of_day_hint+BASE_EXTENSION);
  last_filename= with;
  FILE * fp = VSFileSystem::vs_open (with.c_str(),"r");
  if (!fp) {
    string without (filename+BASE_EXTENSION);
    last_filename= without;
    fp = VSFileSystem::vs_open (without.c_str(),"r");
  }
  return fp;
}
static FILE * getFullFile (std::string filename, std::string time_of_day_hint,std::string faction) {
  FILE * fp = withAndWithout (filename+"_"+faction,time_of_day_hint);
  if (!fp) {
    fp = withAndWithout (filename,time_of_day_hint);
  }
  return fp;
}
void BaseInterface::Load(const char * filename,const char * time_of_day_hint, const char * faction) {
#if 0

  std::string full_filename = string("bases/") + filename;
  std::string daynight_filename = full_filename + "_"+string(time_of_day_hint);
  full_filename+=BASE_EXTENSION;
  daynight_filename+=BASE_EXTENSION;
  std::string newfile=daynight_filename;
  std::cout << "BaseInterface::LoadXML " << full_filename << std::endl;
  FILE * inFile = VSFileSystem::vs_open (daynight_filename.c_str(),"r");
  if (!inFile) {
    newfile=full_filename;
    inFile = VSFileSystem::vs_open (full_filename.c_str(), "r");
  }
  if(!inFile) {
    Unit *baseun=this->baseun.GetUnit();
    if (baseun) {
      if (baseun->isUnit()==PLANETPTR){
	daynight_filename = string("bases/planet_")+time_of_day_hint+string(BASE_EXTENSION);
	inFile = VSFileSystem::vs_open (daynight_filename.c_str(),"r");
	newfile=daynight_filename;
	if (!inFile) {
      newfile="bases/planet"BASE_EXTENSION;
	  inFile=VSFileSystem::vs_open(newfile.c_str(),"r");
	}
      }else{
	daynight_filename = string("bases/unit_")+time_of_day_hint+string(BASE_EXTENSION);
	inFile = VSFileSystem::vs_open (daynight_filename.c_str(),"r");
	newfile=daynight_filename;
	if (!inFile) {
	  newfile="bases/unit"BASE_EXTENSION;
	  inFile=VSFileSystem::vs_open(newfile.c_str(),"r");
	}
      }
    }
	if (!inFile)
      return;
  }
#else
  FILE * inFile = getFullFile (string("bases/")+filename,time_of_day_hint,faction);
  if (!inFile){
    bool planet=false;
    Unit *baseun=this->baseun.GetUnit();
    if (baseun) {
      planet = (baseun->isUnit()==PLANETPTR);
    }
    string basestring ("bases/unit");
    if (planet) {
      basestring = "bases/planet";
    }
    inFile = getFullFile (basestring,time_of_day_hint,faction);
    if (!inFile)
      return;
  }
#endif
  //now that we have a FILE * named inFile and a std::string named newfile we can finally begin the python
  string compilefile = string(filename)+time_of_day_hint+string(faction)+BASE_EXTENSION;
  char *pyfile=strdup(compilefile.c_str());
  Python::reseterrors();

    PyObject *fileobject = PyFile_FromString((char*)last_filename.c_str(), (char*)"rt");
    PyRun_SimpleFile(PyFile_AsFile(fileobject), compilefile.c_str());
    Py_DECREF(fileobject);

  //PyRun_SimpleFile(inFile,pyfile);
  Python::reseterrors();
  free (pyfile);
  VSFileSystem::vs_close(inFile);
}
I tried to load an old savegame, and got an exception related to python, so maybe I'll just compile again now and be back, as the exception also turns up when loading the campaign.

Code: Select all

 	KERNEL32.DLL!77e9bcb1() 	
 	[Frames might be incorrect no Symbols for KERNEL32.DLL]	
 	KERNEL32.DLL!77e9bcb1() 	
 	msvcr80d.dll!10243990() 	
 	vegastrikeDVC7.exe!boost::python::throw_error_already_set()  Zeile 58	C++
 	vegastrikeDVC7.exe!boost::python::expect_non_null<_object>(_object * x=0x00000000)  Zeile 46	C++
 	vegastrikeDVC7.exe!boost::python::converter::void_result_from_python(_object * o=0x00000000)  Zeile 270 + 0x1b Bytes	C++
 	vegastrikeDVC7.exe!boost::python::converter::return_from_python<void>::operator()(_object * x=0x00000000)  Zeile 101 + 0x9 Bytes	C++
 	vegastrikeDVC7.exe!boost::python::call_method<void>(_object * self=0x0e24ce48, const char * name=0x00ef2a94, boost::type<void> * __formal=0x00000000)  Zeile 74	C++
>	vegastrikeDVC7.exe!pythonMission::Execute()  Zeile 251 + 0x13 Bytes	C++
RedAdder
Bounty Hunter
Bounty Hunter
Posts: 149
Joined: Sat Jan 03, 2009 8:11 pm
Location: Germany, Munich
Contact:

Re: Compiling with Code::Blocks

Post by RedAdder »

The new build works fine with vega-vc8 plus VC++ 2005 toolchain :)
ace123
Lead Network Developer
Lead Network Developer
Posts: 2560
Joined: Sun Jan 12, 2003 9:13 am
Location: Palo Alto CA
Contact:

Re: Compiling with Code::Blocks

Post by ace123 »

Great to see you got it working!

Be sure to post the simplified version of all the steps on the Wiki now that you know what you have to do to get it to run, and make a link to this forum thread.
RedAdder wrote:The new build works fine with vega-vc8 plus VC++ 2005 toolchain :)
Thanks for all the debugging you did.

I'm going to try to implement at least the python fix... I suspect you may not have found all the places that use PyRun_SimpleFile, so saved games may still use broken code?
RedAdder
Bounty Hunter
Bounty Hunter
Posts: 149
Joined: Sat Jan 03, 2009 8:11 pm
Location: Germany, Munich
Contact:

Re: Compiling with Code::Blocks

Post by RedAdder »

I only came across that one call to python.

As you can see above, the next call having problems appears to be in boost::python::call_method.
So one would have to hack the boost libraries first to make progress. Or maybe one could leave a note at the boost site explaining that there is a safer way to call python although I guess it might be up to discussion whether it is a better(faster) way.

I'll check out the wiki.
shenle
Confed Special Operative
Confed Special Operative
Posts: 381
Joined: Thu Jan 31, 2008 3:25 am
Location: hiding in a dark corner

Re: Compiling with Code::Blocks

Post by shenle »

Latest SVN chechout (12530) stops building with:

ffmpeg_init.cpp
..\vegastrike\src\ffmpeg_init.cpp(91) : error C2146: syntax error : missing ';' before identifier '_url_seek'
..\vegastrike\src\ffmpeg_init.cpp(91) : error C2061: syntax error : identifier 'xoffset_t'
..\vegastrike\src\ffmpeg_init.cpp(93) : error C2065: 'whence' : undeclared identifier
..\vegastrike\src\ffmpeg_init.cpp(94) : error C2065: 'pos' : undeclared identifier
..\vegastrike\src\ffmpeg_init.cpp(107) : error C2440: 'initializing' : cannot convert from 'int (__cdecl *)(URLContext *)' to 'offset_t (__cdecl *)(URLContext *,offset_t,int)'
None of the functions with this name in scope match the target type
RedAdder
Bounty Hunter
Bounty Hunter
Posts: 149
Joined: Sat Jan 03, 2009 8:11 pm
Location: Germany, Munich
Contact:

Re: Compiling with Code::Blocks

Post by RedAdder »

You probably on windows? 32 bit or 64 bit?

The error might be in this section:

Code: Select all

/* FOLLOWING CODE IS ONLY INCLUDED IF YOU HAVE FFMPEG */
/* ******************************************** */
#ifdef HAVE_FFMPEG
#ifdef _WIN32
#define offset_t xoffset_t
#endif
Remove these lines as a hack not a solution

Code: Select all

#ifdef _WIN32
#define offset_t xoffset_t
#endif
I can't test whether it works right now.
shenle
Confed Special Operative
Confed Special Operative
Posts: 381
Joined: Thu Jan 31, 2008 3:25 am
Location: hiding in a dark corner

Re: Compiling with Code::Blocks

Post by shenle »

Works; same hack has to be applied to gfx/vid_file.cpp
make me a sandwich
make: *** No rule to make target 'me'. Stop.
shenle
Confed Special Operative
Confed Special Operative
Posts: 381
Joined: Thu Jan 31, 2008 3:25 am
Location: hiding in a dark corner

Re: Compiling with Code::Blocks

Post by shenle »

So I wanted to make sure that the information here is still valid and VC Toolkit 2003 + Code::Blocks are still a valid option for a free (beer) dev environment.

I installed everything from scratch according to my own posts, and compiled the latest svn checkout fine... except for a few things:

1. VC Toolkit doesn't come with a resource compiler. Either disable resources, find another resource compiler elsewhere, or copy it from a VC .NET installation (I may attach the resource compiler later)

2. Linker errors galore, which I hadn't seen before. At the linking stage, I get this:

Code: Select all

Linking executable: ..\win32\bin\vegastrikeRVC7.exe
   Creating library ..\win32\bin\vegastrikeRVC7.lib and object ..\win32\bin\vegastrikeRVC7.exp
libpng3.lib(pngrutil.obj) : error LNK2001: unresolved external symbol __fltused
libpng3.lib(pngset.obj) : error LNK2019: unresolved external symbol __fltused referenced in function _png_set_cHRM
libpng3.lib(pngrtran.obj) : error LNK2001: unresolved external symbol __fltused
libpng3.lib(pngget.obj) : error LNK2001: unresolved external symbol __fltused
libpng3.lib(pngwutil.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(floor1.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(floor0.obj) : error LNK2019: unresolved external symbol __fltused referenced in function _floor0_unpack
vorbisfile_static.lib(lsp.obj) : error LNK2001: unresolved external symbol __fltused
libpng3.lib(pngwrite.obj) : error LNK2019: unresolved external symbol __fltused referenced in function _png_write_info_before_PLTE
vorbisfile_static.lib(lpc.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(window.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(mapping0.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(res0.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(bitrate.obj) : error LNK2019: unresolved external symbol __fltused referenced in function _vorbis_bitrate_clear
vorbisfile_static.lib(envelope.obj) : error LNK2019: unresolved external symbol __fltused referenced in function __ve_envelope_init
vorbisfile_static.lib(smallft.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(mdct.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(analysis.obj) : error LNK2019: unresolved external symbol __fltused referenced in function __analysis_output_always
vorbisfile_static.lib(psy.obj) : error LNK2019: unresolved external symbol __fltused referenced in function __vp_global_free
vorbisfile_static.lib(sharedbook.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(codebook.obj) : error LNK2001: unresolved external symbol __fltused
xml_support.obj : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(vorbisfile.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(info.obj) : error LNK2019: unresolved external symbol __fltused referenced in function _vorbis_comment_add_tag
vorbisfile_static.lib(block.obj) : error LNK2019: unresolved external symbol __fltused referenced in function __vorbis_block_ripcord
universe_util.obj : error LNK2001: unresolved external symbol __fltused
universe_util_generic.obj : error LNK2001: unresolved external symbol __fltused
vsfilesystem.obj : error LNK2001: unresolved external symbol __fltused
xml_serializer.obj : error LNK2001: unresolved external symbol __fltused
star_system_xml.obj : error LNK2001: unresolved external symbol __fltused
stardate.obj : error LNK2001: unresolved external symbol __fltused
universe.obj : error LNK2001: unresolved external symbol __fltused
universe_generic.obj : error LNK2001: unresolved external symbol __fltused
ship_commands.obj : error LNK2001: unresolved external symbol __fltused
star_system.obj : error LNK2001: unresolved external symbol __fltused
star_system_generic.obj : error LNK2001: unresolved external symbol __fltused
star_system_jump.obj : error LNK2001: unresolved external symbol __fltused
unit_wrapper.obj : error LNK2001: unresolved external symbol __fltused
universe_util_export.obj : error LNK2001: unresolved external symbol __fltused
rendertext.obj : error LNK2001: unresolved external symbol __fltused
savegame.obj : error LNK2001: unresolved external symbol __fltused
unit_exports.obj : error LNK2001: unresolved external symbol __fltused
unit_exports1.obj : error LNK2001: unresolved external symbol __fltused
unit_exports2.obj : error LNK2001: unresolved external symbol __fltused
unit_exports3.obj : error LNK2001: unresolved external symbol __fltused
posh.obj : error LNK2001: unresolved external symbol __fltused
briefing_wrapper.obj : error LNK2001: unresolved external symbol __fltused
init.obj : error LNK2001: unresolved external symbol __fltused
python_compile.obj : error LNK2001: unresolved external symbol __fltused
savenet_util.obj : error LNK2001: unresolved external symbol __fltused
Aborting process 0 ... Be patient!
Process terminated with status 1120 (1 minutes, 32 seconds)
50 errors, 0 warnings
The linker is set with the following extra options:

Code: Select all

/NODEFAULTLIB:libc
/NODEFAULTLIB:libcd
/NODEFAULTLIB:msvcrtd
/NODEFAULTLIB:msvcrt
/NODEFAULTLIB:msvcprt
/debug
/INCREMENTAL:NO
If any of the above is taken out, the linker barfs much earlier complaining of missing libs.
make me a sandwich
make: *** No rule to make target 'me'. Stop.
shenle
Confed Special Operative
Confed Special Operative
Posts: 381
Joined: Thu Jan 31, 2008 3:25 am
Location: hiding in a dark corner

Re: Compiling with Code::Blocks

Post by shenle »

And here are the missing files. Unzip in your path, e.g. C:\Program Files\Microsoft Visual C++ Toolkit 2003\bin
You do not have the required permissions to view the files attached to this post.
make me a sandwich
make: *** No rule to make target 'me'. Stop.
shenle
Confed Special Operative
Confed Special Operative
Posts: 381
Joined: Thu Jan 31, 2008 3:25 am
Location: hiding in a dark corner

Re: Compiling with Code::Blocks

Post by shenle »

I still get the linking errors outlined in the post above. All out of ideas now.
RedAdder
Bounty Hunter
Bounty Hunter
Posts: 149
Joined: Sat Jan 03, 2009 8:11 pm
Location: Germany, Munich
Contact:

Re: Compiling with Code::Blocks

Post by RedAdder »

I think he meant you download the files, and then remove the matching linker removal instruction lines from the linker extra options list. You probably only need one of the libs ending in "d" because d often stands for the debug version of the lib not ending in "d".

Here are my current Code::Blocks linker options, not sure if they helpful:

Code: Select all

/NODEFAULTLIB:libc
/NODEFAULTLIB:libcd
/NODEFAULTLIB:libcmt
/INCREMENTAL:NO
shenle
Confed Special Operative
Confed Special Operative
Posts: 381
Joined: Thu Jan 31, 2008 3:25 am
Location: hiding in a dark corner

Re: Compiling with Code::Blocks

Post by shenle »

RedAdder wrote:I think he meant you download the files, and then remove the matching linker removal instruction lines from the linker extra options list. You probably only need one of the libs ending in "d" because d often stands for the debug version of the lib not ending in "d".

Here are my current Code::Blocks linker options, not sure if they helpful:

Code: Select all

/NODEFAULTLIB:libc
/NODEFAULTLIB:libcd
/NODEFAULTLIB:libcmt
/INCREMENTAL:NO
Well you see whan I remove lines like that it complains of not finding msvcrt.lib, then msvcrtd.lib, then msvcprt.lib. So I end up having to add them back. Which leads me to the above error:

Code: Select all

libpng3.lib(pngrutil.obj) : error LNK2001: unresolved external symbol __fltused
libpng3.lib(pngset.obj) : error LNK2019: unresolved external symbol __fltused referenced in function _png_set_cHRM
libpng3.lib(pngrtran.obj) : error LNK2001: unresolved external symbol __fltused
libpng3.lib(pngget.obj) : error LNK2001: unresolved external symbol __fltused
libpng3.lib(pngwutil.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(floor1.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(floor0.obj) : error LNK2019: unresolved external symbol __fltused referenced in function _floor0_unpack
vorbisfile_static.lib(lsp.obj) : error LNK2001: unresolved external symbol __fltused
libpng3.lib(pngwrite.obj) : error LNK2019: unresolved external symbol __fltused referenced in function _png_write_info_before_PLTE
vorbisfile_static.lib(lpc.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(window.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(mapping0.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(res0.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(bitrate.obj) : error LNK2019: unresolved external symbol __fltused referenced in function _vorbis_bitrate_clear
vorbisfile_static.lib(envelope.obj) : error LNK2019: unresolved external symbol __fltused referenced in function __ve_envelope_init
vorbisfile_static.lib(smallft.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(mdct.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(analysis.obj) : error LNK2019: unresolved external symbol __fltused referenced in function __analysis_output_always
vorbisfile_static.lib(psy.obj) : error LNK2019: unresolved external symbol __fltused referenced in function __vp_global_free
vorbisfile_static.lib(sharedbook.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(codebook.obj) : error LNK2001: unresolved external symbol __fltused
xml_support.obj : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(vorbisfile.obj) : error LNK2001: unresolved external symbol __fltused
vorbisfile_static.lib(info.obj) : error LNK2019: unresolved external symbol __fltused referenced in function _vorbis_comment_add_tag
vorbisfile_static.lib(block.obj) : error LNK2019: unresolved external symbol __fltused referenced in function __vorbis_block_ripcord
universe_util.obj : error LNK2001: unresolved external symbol __fltused
universe_util_generic.obj : error LNK2001: unresolved external symbol __fltused
vsfilesystem.obj : error LNK2001: unresolved external symbol __fltused
xml_serializer.obj : error LNK2001: unresolved external symbol __fltused
star_system_xml.obj : error LNK2001: unresolved external symbol __fltused
stardate.obj : error LNK2001: unresolved external symbol __fltused
universe.obj : error LNK2001: unresolved external symbol __fltused
universe_generic.obj : error LNK2001: unresolved external symbol __fltused
ship_commands.obj : error LNK2001: unresolved external symbol __fltused
star_system.obj : error LNK2001: unresolved external symbol __fltused
star_system_generic.obj : error LNK2001: unresolved external symbol __fltused
star_system_jump.obj : error LNK2001: unresolved external symbol __fltused
unit_wrapper.obj : error LNK2001: unresolved external symbol __fltused
universe_util_export.obj : error LNK2001: unresolved external symbol __fltused
rendertext.obj : error LNK2001: unresolved external symbol __fltused
savegame.obj : error LNK2001: unresolved external symbol __fltused
unit_exports.obj : error LNK2001: unresolved external symbol __fltused
unit_exports1.obj : error LNK2001: unresolved external symbol __fltused
unit_exports2.obj : error LNK2001: unresolved external symbol __fltused
unit_exports3.obj : error LNK2001: unresolved external symbol __fltused
posh.obj : error LNK2001: unresolved external symbol __fltused
briefing_wrapper.obj : error LNK2001: unresolved external symbol __fltused
init.obj : error LNK2001: unresolved external symbol __fltused
python_compile.obj : error LNK2001: unresolved external symbol __fltused
savenet_util.obj : error LNK2001: unresolved external symbol __fltused
make me a sandwich
make: *** No rule to make target 'me'. Stop.
RedAdder
Bounty Hunter
Bounty Hunter
Posts: 149
Joined: Sat Jan 03, 2009 8:11 pm
Location: Germany, Munich
Contact:

Re: Compiling with Code::Blocks

Post by RedAdder »

msvcrt.lib should be there inside the VC\lib directory of visual studio and should not give an error while compiling.

Maybe this helps:

In the Code::Blocks project wizard, did you create a console app? You should have created a Win32 Application in the project wizard, NOT a console app.
shenle
Confed Special Operative
Confed Special Operative
Posts: 381
Joined: Thu Jan 31, 2008 3:25 am
Location: hiding in a dark corner

Re: Compiling with Code::Blocks

Post by shenle »

I did not use the wizard. I imported into C:B the existing Visual Studio solution vega-vc7\vegastrike.sln

And actually msvcrt.lib is NOT part of the VC++ 2003 toolkit which I am trying to set C:B to compile with.

It's so frustrating because this exact system used to work perfectly a year ago. All these errors have cropped up since my last successful compile which was around january I think.
make me a sandwich
make: *** No rule to make target 'me'. Stop.
Post Reply